Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]

[Randell Jesup <[e-mail]>]

On 9/7/2011 3:07 AM, Olle E. Johansson wrote:
> 6 sep 2011 kl. 21:24 skrev Asveren, Tolga:
>
>> What about semantics (adding just a X-header won't help there) or how much SIP would be left anyhow if all semantical control is exposed through the API?
>>
>> I think bridged line appearance is a good test to run against different models.
>>
> Well, I tried to stay neutral but examples likes this makes me not want SIP in the browser. DTMF, Early Media, bridge line apperances and other PSTN legacy will make the implementation too focused on classical telephony and we'll spend too much time implementing features that are application specific and we can implement in controlling applications, client or server-side.
>
> Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but it will be hard to protect that from the myriad of extensions that add PSTN functionality that's not really needed to set up multimedia calls between two browser users. It may be needed for gatewaying to legacy systems, but if we don't "stop Olle in the gate" - verbatim translation of a Swedish saying that propably doesn't mean much to most people on the list - I think we will never be done.
>
> Of course, being a SIP developer, I started off with thinking that SIP in the browser was the default route. I am beginning to understand that the browser is the user interface part we all need, the media handler. We all have different requirements on how to control that media GUI and to get anywhere I am beginning to think the logic for signalling to set up rendevouz points and manage sessions has to move "somewhere else" where we can implement SIP, XMPP or some other protocol that fulfills the need of our respective application.

I also started from the same point - assume SIP.  SIP gives you all the 
things that the zillions of hours and emails to define it and define 
extensions and secure it provides, without having to reinvent all those 
wheels (or ask app developers to reinvent them).  Why go through the 
horrible pain of choosing something else, or why throw the app 
developers to the wolves to fend for themselves?

However...

Two things have swayed me.  The primary one is the suggestion of 
Offer/Answer in the browser.  This breaks out the important negotiation 
piece that almost any application would need, and while not perfect, SDP 
O/A is a zillion times simpler than SIP with all the extensions one 
could use.

The other thing that swayed me was thinking about federation and the 
apps that will be built with this.  A webrtc app talks to its 
(web)server, other webrtc clients running the app that talk to the 
server, and to other webrtc applications/networks that federate with it 
(and their clients).

Federation is in the same hands as the person who provides/wrote the 
app.  If they have no interest in federation you can't force it, and 
they may have no use for all the fancy SIP standards.

On the other hand, if they *want* to either provide access to the wider 
communication net that is the PSTN network, now or in the future, or 
they want easy federation with other networks, it behooves them to use 
SIP or something very close to it or equivalent/convertible (at a basic 
level at least) to it.

So what conclusions do I draw from this?

1) O/A via SDP in the browser simplifies a lot of things (including 
handling new codecs, etc).  It doesn't extremely limit an application, 
though we should think about how an application can interact with the 
fmtp/etc parameters used.

2) SIP as a *separate* item that can be cleanly and easily *added* to a 
webrtc app to handle the call setup/etc is a good idea.

This means a webrtc app could use something else, or roll its own.  Many 
would use SIP.

This would require (limited) SIP to be available as part of webrtc in 
the browser - but as an option, not as a mandate.  An application could 
use an extended SIP client via JS or other mechanism.  Basic SIP would 
need to be in all webrtc implementations so the apps could rely on 
having the option.

This would make building apps & services that can (optionally) call PSTN 
phones easy (very easy perhaps), while not limiting the ability of app 
developers to innovate.  It also makes it easier to build servers to 
handle webrtc apps.

-- 
Randell Jesup
[e-mail]