Last year, we already achieved sip vs webrtc audio and video calls and announced it, but we didn’t stopped there and have completed internal features to better support RTCP feedback (NACK, PLI, SLI) and by adding the mandatory DTLS-SRTP encryption support.
DTLS-SRTP is a nice replacement for the basic SDES encryption negociation: With SDES, even when using TLS for signaling, all proxies (and their administrators…) were able to read the encryption keys. DTLS-SRTP use an encrypted DTLS connection to negociate the key in the media stream: if you don’t trust your admin… that’s for you!
Beside DTLS-SRTP, support for RTCP-feedback is the most interesting step for amsip sdk. This is mandatory today to achieve the best video quality users can expect. This standard feature introduces technics to reduce the bandwidth when no loss is detected (by extending the interval choosen to send complete image – keyframe) and help to recover as fast as possible when a loss is detected (by sending as soon as possible a complete image -keyframe-)
Webrtc is great because it mandates the implementation of such features: from the beginning, they requires good security (usage of DTLS-SRTP) and strong quality requirements (RTCP feedback).
A SIP + media application can clearly implement the same level of quality: RTP/SAVPF profile, with DTLS-SRTP, with RTCP-feedback, with ICE, muxing all RTPs and RTCPs into one connection, etc… However, the history is different and ends up this way: amsip supports DTLS-SRTP, but 99% of calls require SDES negociation…
Anyway, today, webrtc is providing the full list of what should be mandatory in a SIP application. We have added them all in amsip sdk and even for SIP to SIP calls, we can reach the same level of quality and security.
There is no doubt that SIP applications from various vendors are also looking at webrtc and getting to the same point and this is a new chance for SIP to interoperate at a higher level, ie, with RTP/SAVPF profile!
I have no doubt that SIP will play its role around webrtc! The exact same media technology needs to be used for both.
In order to test:
- Visit sip.antisip.com and create 2 antisip accounts!
- Visit Voip By Antisip and install it on your android device!
- Start your Voip By Antisip and configure it with your first antisip account:
- domain = sip.antisip.com
- username = user1
- password = youruser1password
- Visit jsSIP (prefer Google Chrome?) and fill the form to register with your second antisip account:
- display name = Aymeric Moizard
- sip uri = sip:firstname.lastname@example.org
- password = youruser2password
- ws uri = wss://sip.antisip.com:4443
- And type “Enter”
- Then, call “user1” from your web navigator, accept the camera and microphone usage and your android phone should ring!
Note: If you wish to make calls from Voip By Antisip to the browser, then you need to select RTP/SAVPF option in the settings. This setting will most probably prevent you to be able to call other SIP applications… As they may not support the RTP/SAVPF profile required for webrtc. But one day, they may all support it –as Voip By Antisip–! 😉