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

[Matthew Kaufman <[e-mail]>]

On 9/7/11 12:20 PM, Randell Jesup wrote:
>
> 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.

I agree with this. While I am also opposed to SDP O/A, these are two 
unrelated arguments to have... and not baking a SIP phone into the 
browser is *more* important than avoiding a repeat of the offer/answer 
problems.

>
> 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.

And for numerous types of apps (think: server-based augmented reality 
systems), "federation" doesn't even make sense.

>
> 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.

I agree that it would simplify some interop cases, but at an unfortunate 
cost in lack of flexibility and functionality. Still not nearly as bad 
as if we put a full SIP stack in there though.

>
> 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.

I would be open to looking at this again, *after* RTC is already in 
browsers and successful, to see if it actually solves a real use case.

Matthew Kaufman