Is SIP a bad fit for WebRTC?

[Oivvio Polite]

I'm just getting started with VoIP and I've been doing a lot of reading
about protocols and their implementations in this space.

After spending a couple of weeks reading up on SIP I've gathered form
numerous places that a lot of people in the know feel that SIP is not a
good fit for the browser and mobile.

For instance here's a link to a tweet[1] by one of the authors of SIP
stating that "SIP does not work well with mobile push notifications".

I spent a couple of weeks fooling around with FreeSwitch. They've built
a homegrown signalling solution between WebRTC and FreeSwitch that they
call Verto. Now I'm looking at Janus and they too have a homegrown
signaling solution.

It's pretty clear that people with a lot of experience in this field
feel that SIP is not a great fit for signaling in the browser.

What I don't understand yet is why? Why is SIP a bad fit for the browser
and for mobile?

kind regards, Oivvio


[1] https://twitter.com/jdrosen2/status/710637191874134016

[itay bia]

From a short look at FreeSwitch's Verto, correct me if I'm wrong, it's a client not a protocol. Janus seems to be a gateway between different protocols.

So, SIP by itself is fine, and I'm guessing what the above 2 are doing is convert JINGLE (XMPP) messages from WebRTC to SIP or other signaling protocols. AFAIK, the reason SIP won't be good by itself for browsers would be interoperability. mostly, if a browser says it supports WebRTC, it means WebRTC's signaling protocol (JINGLE), which is of course not SIP. The WebRTC clients don't know SIP. So what FreeSwitch and Janus did was create a gateway between SIP and JINGLE so that normal SIP clients would be able to talk to WebRTC supporting browsers.

[Lorenzo Miniero]

I don't know about FreeSwitch, but we (Janus) don't use Jingle. We do indeed have a custom JSON based protocol between users and Janus to handle WebRTC signalling and negotiation. For the SIP plugin (which acts as a webrtc-to-sip gateway) we still use our JSON based protocol on the WebRTC side, and map requests there to SIP transactions on the other side.

L.

[Oivvio Polite]

On ons, apr 20, 2016 at 09:28:10 -0700, itay bia wrote:
> From a short look at FreeSwitch's Verto, correct me if I'm wrong, it's a
> client not a protocol. Janus seems to be a gateway between different
> protocols.

The authors actually describe Verto as protocol. But since there's only
one implementation of that protocol (mod_verto + verto.js) it might not
be that clear.

> So, SIP by itself is fine, and I'm guessing what the above 2 are doing is
> convert JINGLE (XMPP) messages from WebRTC to SIP or other signaling
> protocols.

> AFAIK, the reason SIP won't be good by itself for browsers would
> be interoperability. mostly, if a browser says it supports WebRTC,

But there are at least a couple js implementations of SIP. So any modern
browser can do SIP.

> it means
> WebRTC's signaling protocol (JINGLE), which is of course not SIP.

I'm very new to all of this but my understanding is that there is no
standard signaling protocol designated for WebRTC in the specification.
Are you saying that Jingle has emerged as a de facto-standard, that
Jingle is what most people use for signaling when doing WebRTC?

oivvio

[Oivvio Polite]

On ons, apr 20, 2016 at 11:57:40 -0700, Lorenzo Miniero wrote:
> I don't know about FreeSwitch, but we (Janus) don't use Jingle. We do
> indeed have a custom JSON based protocol between users and Janus to handle
> WebRTC signalling and negotiation. For the SIP plugin (which acts as a
> webrtc-to-sip gateway) we still use our JSON based protocol on the WebRTC
> side, and map requests there to SIP transactions on the other side.
>

As I understand it from your presentation av VUC[1] you had been deeply
involved in real time communication long before embarking on the Janus
project. Given this a assume that you must have considered SIP as on
option for singling in Janus and for some reasons decided to discard it.
As a newcomer to this field I'm curious to know what those reasons were?

Oivvio

[1] https://www.vuc.me/2016/vuc584-janus-webrtc-gateway/

[Alexandre GOUAILLARD]

"WebRTC's signaling protocol (JINGLE)"

There is no signaling protocol (ex: SIP, XMPP, ...) or signaling transport protocol (ex: UDP, TCP, ....) mandated by WebRTC specs. Web applications are free to use whatever they want as long as it is supported by the browsers. SDP, offer/Answer, Encryption, and a few other things are mandatory though, and those part is described in the JSEP specification. 

Practically, this is only a restriction for the signaling transport protocol mainly since browser do not let web app create UDP, TCP sockets. You are free to use SIP, XMPP, or JINGLe, or whatever you want as a signaling protocol in your web app, you just need to have JS code that implements the signaling part. There are many JS SIP libraries available today (jssip, sip,js, ....), and using SIP over WebSocket seems to be the most common approach for those who want to interoperation with the VOIP world. Most recent VoiP servers (kamailo, freeswitch, asterisk) will handle both SIP/WS and SIP/UDP-TCP and translate between each.

Some also use REST apis instead of WS for the signaling transport protocol. It makes repurposing an existing gateway for the web easier (e.g. Genband's SpiDR).

Finally, some other, who likes federation and presence, and/or want to interoperate with jabber, use XMPP or variations of XMPP (JINGLE, Matrix.org), which provides those two features out of the box.

There is no one-fit-all signaling. For some specific orthogonal use cases (see above) SIP and XMPP are great choices, for generic use case with no interoperability in mind (I dare say most of the web), some proprietary is always more flexible. JSON-formated content sent over WebSocket seems quite popular in that last case. The content itself would be application specific.

HTH

alex.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/20160421034342.GB3900%40blomma.liberationtech.net.

For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

Principal Architect - Citrix, San Francisco

President - CoSMo Software Consulting, Singapore

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[itay bia]

Alex, i stand corrected. i guess i mixed webrtc with chromium. i wonder what are the statistics of different webrtc applications and the signaling protocol they use.

Oivvio , about "SIP does not work well with mobile push notifications", one thing you should take into account that on iOS for instance, you may have problems getting CPU in the background. so your SIP registration may time-out after a while. push gets around that, but you will have to re-register as your app starts up from the push, which means some delay until you can actually process the INVITE. if you try and do some hacks and workarounds in iOS or android, you may as a side effect eat away too much of the battery. so these are 2 points to consider.

[Alexandre GOUAILLARD]

no worries, it is super confusing.

the fact that libwebrtc use parts of lib jingle (network stack) but not others (signaling, xmpp) does not help. The fact that chromium has yet other dependencies on jingle, also makes it difficult to remove the dependency.

The google guys are trying to disentangle this but it's not easy. If you're curious, you can follow the effort here:

https://bugs.chromium.org/p/webrtc/issues/detail?id=4256

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/803a04db-5ce1-469d-8782-12901c2519f4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.