We are working on a legacy project in which we are connecting to Asterisk PBX using data sent over DTMF. We are exploring using alternatives to DTMF and have zeroed in on SMS and web sockets. What will be the best approach to implement this?
Asterisk v11 is being used.
If you use analog, you can use tone-based modems like iaxmodem or alarm reciver in asterisk.
if you are using sip, most logical will be use of sip messages.
Related
Sip (session initiation protocol) does not understand websocket so we need sip proxy which is basically a translator between sip and websocket.
i am following this architecture for sip handshaking with web socket. I have few questions
which sip proxy must be used to make audio and video call. and in the Gateway to SIP module i am using ASTERISK. how asterisk can be used for video call is there any codec available for video call? Please share some useful links.
Your kind answers will be highly appreciated.
Check out http://jssip.net. They provide a javascript API which uses SIP over WebSocket for client-side and they also have a SIP proxy and server (also works with Asterisk,Kamailio). They are the authors of RFC7118 "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)".
that s only one way to do it. There are many ways.
you have to distinguish between the signaling path and the media path
on the signaling path, you have to choose a signalling protocol and corresponding transport protocol. A browser can use web socket for transport and sip for the protocol as far as signaling is concerned. On the legacy SIP side, you need SID over UDP, there is a need to change the transport of the signaling, not the protocol of the signaling.
On the media path, you have two problems, the encryption and the codec. The encryption is mandatory in webrtc and not in SIP. You need a B2BUA to make the transition between both words.
on the codec side, you either choose an overlapping codec between both words, or you have to transcode. The use of a media server seems mandatory here. If you have multiple parties in a conference, you will need to mix the audio and compose the video to send it to legacy SIP, in which case your media server should be an MCU.
Eventually, you also have a discovery and identity problem. During the original handshake, SIP is expecting a user ID and a domain (which is either a DNS entry or a fixed IP) while webRTC is using ICE. Here again, it is very likely that you need to use a B2BUA to bridge both world.
Asterisk/kamailio/freeswitch are likely to handle most of the above for the simple cases (1 to 1, audio). For anything complicated, you're on your own. You might want to look at respoke.io that was made by digium, the company behind asterisk.
I would like to make a call from webbrowser using websockets along with sip5ml.js to an extension registered on asterisk. However, there is a limitation. The version of asterisk I am currently using has no native support for websockets, thus I need to come up with a workaround. Is there a way to forward all requests made from browser to asterisk?
You need a SIP - WebRTC gateway. For example, this one: http://webrtc2sip.org/
Is there an application-agnostic signaling protocol?
The use case is this. We have an open-source library for a multi-agent system that supports several protocols of the application layer of the OSI model. On the moment HTTP, XMPP, and ZeroMQ are supported for example. We would like to add high-bandwidth real-time streaming possibilities. It is logical to use RTP for that.
So, to recapitulate, we already have a connection to the other party that we can use for signalling. We want to negotiate only a new channel for data communication.
However, regarding the current standards, with respect to signaling all of them seem to be tied to their application. These current "standards" seem to be SIP, RTSP, and Jingle. They all seem to use RTP or SRTP on the application layer, and UDP on the transport layer. See e.g. XEP-0167.
The only thing we want to negotiate is another connection to that party that can be used for data transmission. In the Session Description Protocol all kind of stuff about media shows up, optional phone numbers, etc. If someone can point at a signaling protocol that is meant to be application-agnostic, that would be great!
I'm a big fan of XMPP and I think you'll get what you need with it. However since you already have HTTP as well, I want to mention that PubSubHubbub can also be used for that!
The current version of the protocol applies to any mime type that can be transported with HTTP so that would work.
In practice it's just a webhooks API which makes it easy to use and scale via load balancing.
Is there an application-agnostic signaling protocol?
Yes there are lots and you already mention a number of them such as XMPP, SIP and RTSP. You could also add the brand new WebRTC protocol to the list.
We would like to add high-bandwidth real-time streaming possibilities. It is logical to use RTP for that.
Yes. RTP is lightweight and as its name suggest was designed for carrying real-time traffic. It's also popular so you will be able to find numerous existing implementations.
The only thing we want to negotiate is another connection to that
party that can be used for data transmission. In the Session
Description Protocol all kind of stuff about media shows up, optional
phone numbers, etc. If someone can point at a signaling protocol that
is meant to be application-agnostic, that would be great!
I'm not sure what you mean here. Session Description Protocol (SDP) is a standard way to describe the media capabilities of a device. It's commonly used in SIP and RTSP (and XMPP has something equivalent) however it's separate from those protocols and if you don't want to use it you are free to come up with your own way of describing media.
You may be getting overwhelmed by some of the SDP examples, and they can indeed get very complicated when there are multiple streams and codecs offered. However an SDP payload can also be very simple; below is an SDP example for an RTSP server offering a single MJPEG video stream.
v=0
o=- - 0 IN IP4 0.0.0.0
s=-
t=0 0
m=video 0 RTP/AVP 26
If you just need a signalling protocol that is system and application agnostic, XMPP is the way to go.
I'm trying to implements a simple NMS with snmp++ V3.2 api.
The objective is receive SNMP informs over TCP.
The problem is that I only receive Informs over UDP... I implement an Agent in java with SNMP4J API, but only works when i send via UDP.
I have searched for examples but I only find examples With Agent sending traps/informs via UDP to snmp++ manager....
I also find this: http://lists.agentpp.org/pipermail/agentpp/2005-October/003196.html, it is possible TCP communications is not yet implemented in SNMP++?
The big question is, can snmp++ managers receive alerts via TCP ? If yes, does someone have an example/tutorial to show me ?
SNMP over TCP is defined in RFC3430 as an experimental standard. It is not widely adopted, and based on its FAQ SNMP++ does not support it at all,
http://oosnmp.net/confluence/pages/viewpage.action?pageId=7766018
I am curious to know if interoperability exists between those three protocols. Like if a call originated from a SIP protocol can go through a H.323 protocol? An article or book link about this topic will be much appreciated.Thanks.
SIP, H.323 and IAX2 are all different protocols and are not directly interoperable. That is, you cannot connect a SIP phone to an H.323 device and make a call.
The problems these protocols solve are all similar (e.g. Make a voice or video call). Protocol converters and other devices (like gateways) are available and can do the conversion.
You may also have to transcode the audio and video data from one codec to another, but you may also have to do that on a SIP-SIP or H.323-H.323 call.
Many PBXes and SoftSwitches support both SIP and H.323: asterisk supports all 3 (SIP, H.323 and IAX2).