SIP through WebRTC on production. How we went to this and what problems solved
Good day to all!
I already wrote about my experience with WebRTC here , but considering that recently more and more articles on this topic appear on Habré and what I have long wanted to write about how we achieved SIP telephony stable work on WebRTC on production I decided to write through what we went through.
And we went through a lot: pain, panic, tantrums, a bunch of mats and wishes of good to the maintainers.
Now it's all in the past. We got rid of all the crutches that we did, and made it so that the operators called and everything worked stably.
In the article, I described in as much detail as possible all the problems we encountered, using as little code and configs as possible.
')
Who cares, I ask under the cat.
We wrote software for our call center and we had the opportunity to do it in such a way that we don’t bother about cross-browser compatibility.
At the initial stage, we chose:
Over the whole way we used:
The beginning of the way. We had to achieve a working scheme and call from the browser to our mobile.
Asterisk patches and compiled on this manual
After we achieved this, we started testing.
During testing, we found:
1. "White noise" was corrected using this patch.
2. The problem with dropping a call was solved by setting up a user on Asterisk. A limit of 1 call per user has been set.
3. We decided to fix the problem with a 10 second silence by updating Asterisk to version 1.6.
And here we are at 1.6 asterisk. After a quick test, it became clear:
But the following problems appeared:
The problem with silence was solved by the fact that we abandoned STUN in SIPml5. The situation has become better, but not completely disappeared.
We decided to try WebRTC2SIP, as recommended by the SIPml5 maintainers.
At this stage we have the following situation:
BUT! The problem is that WebRTC2SIP is not ready for production. He constantly fell at different intervals.
Judging by the bug tracker in the tracker, the problem has been known for half a year, when we began to use it. Realizing that nothing could be achieved from the maintainers, they began to solve the problem themselves.
// Meanwhile, the project is already in production.
After spending a week without solving the problem, we restarted webrtc2sip and began to look towards Freeswitch.
I was looking in the direction of Freeswitch back when Beta version 1.4 was released with WebRTC support.
At this stage, it became clear that neither from Asterisk, nor from Doubango Telecom should we expect any help, and we need to somehow solve the problem ourselves.
At the initial stages of working with Freeswitch, the xml brain is very tolerated by configs, but when you get used to them, you cannot live without them.
After we achieved work from him in conditions close to production, we tested it, and realizing that there were no bugs, we began to test further on production, while retaining the opportunity to switch back to Asterisk + WebRTC2SIP
After migration, the problems with the softswitch have disappeared. There were problems from SIPml:
We made a few crutches to prevent these problems from interfering with us and decided to switch to JSSIP. About JSSIP known for about a month. And there was a lot of hatred for Doubango and their products and a great desire to get rid of their products.
After checking everything on tryit.jssip.net and realizing that there are no problems, three days later, after migrating to JSSIP, our SIP began to work stably and without bugs.
That's the story turned out. And now my personal opinion on each software.
Pros:
Minuses:
Pros:
Minuses:
Pros:
Minuses:
As I understand it, the craftsmen are repairing one release, another break.
On version 1.7, SIP through WebRTC stopped working for me.
Habrayuzer Ovoshlook perfectly and in detail described the problem:
In the end, all this got tired and we chose Freeswitch as soft-switch
Pros:
Minuses:
SIP began to work stably. The operators are happy. The current bundle of Freeswitch + JSSIP processes ~ 10k calls per day and up to 15k during peak hours.
Anyone interested can write about how we set up Freeswitch with integration with MySQL, call center, call recording and made it fault tolerant.
I already wrote about my experience with WebRTC here , but considering that recently more and more articles on this topic appear on Habré and what I have long wanted to write about how we achieved SIP telephony stable work on WebRTC on production I decided to write through what we went through.
And we went through a lot: pain, panic, tantrums, a bunch of mats and wishes of good to the maintainers.
Now it's all in the past. We got rid of all the crutches that we did, and made it so that the operators called and everything worked stably.
In the article, I described in as much detail as possible all the problems we encountered, using as little code and configs as possible.
')
Who cares, I ask under the cat.
Background:
We wrote software for our call center and we had the opportunity to do it in such a way that we don’t bother about cross-browser compatibility.
At the initial stage, we chose:
- SIPml5 - as frontend lib
- Asterisk - as backend
- Google Chrome is like a browser. where all this should work.
Over the whole way we used:
- Asterisk and SIPml
- Asterisk + Webrtc2sip and SIPml
- Freeswitch + SIPml
- Freeswitch + JSSIP
Not much about software:
- Asterisk is a well-known soft-switch. Made by Digium craftsmen
- Freeswitch - Soft-switch. One of Asterisk's competitors
- SIPml5 - position themselves as the first HTML5 SIP client. Javascript lib to work with SIP.
- JSSIP is lightweight JavaScript for working with SIP.
- WebRTC2SIP - SIP and Media Gateway
asterisk + sipml
The beginning of the way. We had to achieve a working scheme and call from the browser to our mobile.
Asterisk patches and compiled on this manual
After we achieved this, we started testing.
During testing, we found:
- "White noise" when calling
- Silence up to 10 seconds with an incoming call.
- An incoming call dropped an outgoing call.
1. "White noise" was corrected using this patch.
2. The problem with dropping a call was solved by setting up a user on Asterisk. A limit of 1 call per user has been set.
3. We decided to fix the problem with a 10 second silence by updating Asterisk to version 1.6.
And here we are at 1.6 asterisk. After a quick test, it became clear:
- "White noise" no
- Native support for web socket
But the following problems appeared:
- Asterisk crashes on incoming call on RTP definition
- Silence up to 10 seconds left.
The problem with silence was solved by the fact that we abandoned STUN in SIPml5. The situation has become better, but not completely disappeared.
We decided to try WebRTC2SIP, as recommended by the SIPml5 maintainers.
asterisk + webrtc2sip + sipml
At this stage we have the following situation:
- No old bugs
- Asterisk does not fall
- Silence disappeared.
BUT! The problem is that WebRTC2SIP is not ready for production. He constantly fell at different intervals.
Judging by the bug tracker in the tracker, the problem has been known for half a year, when we began to use it. Realizing that nothing could be achieved from the maintainers, they began to solve the problem themselves.
// Meanwhile, the project is already in production.
After spending a week without solving the problem, we restarted webrtc2sip and began to look towards Freeswitch.
freeswitch + sipml
I was looking in the direction of Freeswitch back when Beta version 1.4 was released with WebRTC support.
At this stage, it became clear that neither from Asterisk, nor from Doubango Telecom should we expect any help, and we need to somehow solve the problem ourselves.
At the initial stages of working with Freeswitch, the xml brain is very tolerated by configs, but when you get used to them, you cannot live without them.
After we achieved work from him in conditions close to production, we tested it, and realizing that there were no bugs, we began to test further on production, while retaining the opportunity to switch back to Asterisk + WebRTC2SIP
After migration, the problems with the softswitch have disappeared. There were problems from SIPml:
- If you call and hang up, then sipml will think that they also call it and will try to take a dead call.
- The call did not last more than 2 minutes.
We made a few crutches to prevent these problems from interfering with us and decided to switch to JSSIP. About JSSIP known for about a month. And there was a lot of hatred for Doubango and their products and a great desire to get rid of their products.
After checking everything on tryit.jssip.net and realizing that there are no problems, three days later, after migrating to JSSIP, our SIP began to work stably and without bugs.
Summary
That's the story turned out. And now my personal opinion on each software.
Sipml
Pros:
- Supports transfer
Minuses:
- Very awesome. Minified js file weighs> 1 Mb
- No full documentation. A lot of things had to look for on the Internet.
- More sharpened by WebRTC2sip
- Lot of code
An example of connecting to the server
// SIPml.init( function(e){ var stack = new SIPml.Stack({realm: 'example.org', impi: 'bob', impu: 'sip:bob@example.org', password: 'mysecret', events_listener: { events: 'started', listener: function(e){ var callSession = stack.newSession('call-audiovideo', { video_local: document.getElementById('video-local'), video_remote: document.getElementById('video-remote'), audio_remote: document.getElementById('audio-remote') }); callSession.call('alice'); } } }); stack.start(); } ); Call example
// var callSession; var eventsListener = function(e){ console.info('session event = ' + e.type); } var makeCall = function(){ callSession = sipStack.newSession('call-audiovideo', { video_local: document.getElementById('video-local'), video_remote: document.getElementById('video-remote'), audio_remote: document.getElementById('audio-remote'), events_listener: { events: '*', listener: eventsListener } // optional: '*' means all events }); callSession.call('johndoe'); } Jssip
Pros:
- Lightweight (~ 130kb)
- Excellent documentation on the developer's site
- Works great with Freeswitch (in theory with Asterisk and others, but I haven’t checked it here)
- Great API
Minuses:
- Do not know how to make a transfer call
Example of connecting to the server:
// var configuration = { 'ws_servers': 'ws://sip-ws.example.com', 'uri': 'sip:alice@example.com', 'password': 'superpassword' }; var coolPhone = new JsSIP.UA(configuration); Call example
// var selfView = document.getElementById('my-video'); var remoteView = document.getElementById('peer-video'); // Register callbacks to desired call events var eventHandlers = { 'progress': function(e){ /* Your code here */ }, 'failed': function(e){ /* Your code here */ }, 'started': function(e){ var rtcSession = e.sender; // Attach local stream to selfView if (rtcSession.getLocalStreams().length > 0) { selfView.src = window.URL.createObjectURL(rtcSession.getLocalStreams()[0]); } // Attach remote stream to remoteView if (rtcSession.getRemoteStreams().length > 0) { remoteView.src = window.URL.createObjectURL(rtcSession.getRemoteStreams()[0]); } }, 'ended': function(e){ /* Your code here */ } }; var options = { 'eventHandlers': eventHandlers, 'extraHeaders': [ 'X-Foo: foo', 'X-Bar: bar' ], 'mediaConstraints': {'audio': true, 'video': true} }; coolPhone.call('sip:bob@example.com', options); Webrtc2sip
Pros:
- Helped solve a problem with Asterisk
Minuses:
- Not stable
- Stability was adjusted a year later.
Asterisk
As I understand it, the craftsmen are repairing one release, another break.
On version 1.7, SIP through WebRTC stopped working for me.
Habrayuzer Ovoshlook perfectly and in detail described the problem:
The craftsmen are already patching. Now the universal and all-consuming problem is different - when an asterisk does bridging it sends an invite to the AVP transport, and if the called subscriber is sitting on the webphone, he accordingly expects AVPF transport and encryption. As a result, when called, the callee will respond 603 with an error with the comment failed to get local sdp.
In general - when outgoing, the asterisk does not monitor the device from which the client is sitting on it. Alternatively, you can proxy and convert via openSIPS or Kamailio, but this is a completely different topic.
In the end, all this got tired and we chose Freeswitch as soft-switch
Freeswitch
Pros:
- Works
- Actively developed
- Nothing breaks in new releases
Minuses:
- There is no possibility to make a similar call center, as in asterisk with a robot robot by timeout
Total
SIP began to work stably. The operators are happy. The current bundle of Freeswitch + JSSIP processes ~ 10k calls per day and up to 15k during peak hours.
PS
Anyone interested can write about how we set up Freeswitch with integration with MySQL, call center, call recording and made it fault tolerant.
Source: https://habr.com/ru/post/225239/
All Articles