I'm considering using PJSIP to create a B2BUA. There are a number of different layers/wrappers in the PJSIP project and I'm wondering what the right layer to use is.
While PJSIPUA2 makes call management simpler as an endpoint, it appears that I lose the level of control needed of the SIP dialog needed to coordinate the 2 legs of the call.
What is the right PJSIP library level to use for a B2BUA?
Related
How can i modify the routing modules on ONE simulator like epidemic ,prophet, spray and wait to send a response when the destination node receives a message?
That kind of behavior is not part of the routing modules but part of applications. The routing modules only deal with trying to move messages toward the right destinations. The typical one-way messages you can create with the Message Generators but for more complex behavior (e.g., request/reply) you need an application module.
There is already a PingApplication that is usually sufficient for simple request/reply scenarios. If you need more complex application behaviour, making a new application based on the PingApplication is probably the best way forward.
I found this article:
www.codeproject.com/Articles/1077937/Possible-ways-to-organize-interaction-between-co,
and I know that there exist a code for the flash player.
Can I use only code for managing connections (as in the articles examples) and free flash player code and therefore get rid from integration software?
You need to be more specific but in reality the idea of the integration software is the following:
Session management
Multi-codec/format support
Interface Resource
Scheduling
Normally IP PBX supports SIP only, hence you need the transcoding between the SIP world (Audio + Video) and the Webcast world (Web browser/client/camera). Integration software as the one defined do a pretty good job and some of them are open Source (Wooza), If you want to replace them, I would do it with an MCU which support RMTP/Flash. Take a look at McuWeb project. Otherwise you need to write SIP Client code as well to integrate it with the SIP world
I'm working on a project in which I want to display biosensor EEG/ECG data measured by a portable device (e.g., a micro controller with wireless data transmission via Wifi or Bluetooth). For this purpose, I need to interface with the portable device/microcontroller, for which the many or some of the device seem to use RESTful interfaces, but offer also probably sockets.
One example of microcontroller with wifi is the "spark.io", which is based on a cortex m3 and CC3000 wireless controller for WiFi access on-board. The data to be transferred are around 500 to 1000 float values per second, which should arrive at the REST client with as little delay as possible. Probably an non-REST approach like sockets would fit better, but I would still like to test an approach based on a RESTFul interface (a tiny argument for this would be that transferring data via RESFul interface seems very common and has good library support).
Q: The question is, what is the best approach for a performant (in the sense of near-realtime) implementation that interfaces with this via REST interface?
I am sure this problem has been solved before, but I could not quickly find a paper via google scholar or technical/scientific blog post that explains this. The only link I found is on "rest hooks", but I am not sure if this is a good approach. Searching on SE didn't reveal a past question on this.
Side note: My approach would be to implement the interface in haskell first to test the design and performance of the RESFull interface. Later the working approach should be ported or implemented with Java/Android/spark.io/some other microcontroller.
(Please note this question is entirely about the architecture and not at all about haskell libraries or anything. If using REST is the stupiest thing, I will accept that as an answer if it is argumented. Also then the question is then whether in general microcontroller web-interfaces and specically their APIs, like that of "spark.io", are in general a stupid idea, if they are implemented via REST. Is this the case? If not, what definition of "near real time" justifies that a REST interface is a bad idea and thus other means of communcation are better. Like: one sensor read per minute? Or, one per second, by 1/10 second, by 1/100 second, by 1/1000 second?)
Okay, let's go through this.
REST is not necessarily a bad idea but it has a lot of features which you may not need. For example, there are REST verbs not just for retrieval, but also updating, deleting, and creating resources. If those functions are important (e.g. you need to send certain control data to the EEG controller) then REST will be nice. If you just want fast access to the stream of data, consider raw TCP instead.
Similarly, REST will package messages into "requests" and their "responses" which come with a bunch of "headers" indicating things like whether the request could be fulfilled, whether it's compressed, etc. These can be great features but may be bloat. You'll probably want to emit enough data on each request so that the ~1kB of headers are a small fraction of it. But given 8-byte floats (doubles), that requires transmitting 500-1000 data points, which you've said will take about one second. Is that our fate -- to always have 1s of latency?
REST will allow you to avoid some of that bloat by declaring a Transfer-Encoding: chunked so that the client can operate on individual chunks as they become available. So that's an architectural decision that I think will need to be made.
I would definitely get Keep-Alive working as soon as possible, and it would be my chief feature when looking for what library to use on the server. Keep-Alive is a standard extension to HTTP which avoids tearing down and rebuilding the TCP stack for each HTTP request. If you don't do this then you have some heavy protocol negotiations each time you send a request.
A crucial decision you'll have to make involves whether you want to do HTTP pipelining or not. You can combine HTTP pipelining with longer-lived requests (ones where you don't expect an immediate response) to essentially "send the data when it becomes available" (i.e. send the headers first and let the server push out the data when it's good and ready). This is an alternative to chunked transfers.
If you can work those out, then HTTP is regularly used to send megabytes per second, so your use case fits well within what REST is capable of. In terms of REST/HTTP libraries for Haskell, if you have to somehow program the controller yourself, the big options are wai, yesod, snap, and rest. If you just need an HTTP client there are a few of those too.
I am looking over csipsimple app - uses sip calls, registers. I also found samplecsipsimple that registers a sip client to the a sip server using the csipsimple as a library. I would like how to create an outbound call and imbound call on wifi using csipsimple as a library?
Need some help.
Appreciate
Since CSipSimple uses a wrapper for pjsua, you should take a look at simple-pjsua program. And since there is no callback mechanism in Java, you wont be able to use the callbacks (such as on_call_state). so what you need to do is to extend the Callback class and override all of it's methods. Look in the code how it is done.
IVR Systems are so expensive and proprietary.
The vendor systems I've used are all pretty weak... What is a good alternative to Genesys, Intervoice, etc.?
Asterisk is open source and it includes the capability of defining and running IVR interactions.
They have proprietary hardware for interaction with the PSTN or you can build services on top of VoiceOverIP protocols such as SIP (i.e. IP only).
See the Asterisk Gateway Interface wiki page - this describes the primitives you would use in the IVR script.
I use Asterisk for IVR implementations. I don't think the learning curve was too steep, especially considering I'm not really into telecoms, and it's worked pretty well for what I've used it. I currently have an IVR with 8 E1 links (240 channels) with Asterisk and a Sangoma card, works pretty well. And it's easy to test new features, since I can run it in my machine with just VoIP, setting up SIP in Asterisk and using the X-Lite softphone.
I connect Asterisk with my Java application using FastAGI and JAGIServer/OrderlyCalls on the Java side.
I would recommend Katalina 'VoiceGuide' - a windows-based CTI, IVR and dialler system at a reasonable price, supporting both tradtional POTS/ISDN telephony cards and VoIP. see: www.voiceguide.com