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

["Olle E. Johansson" <[e-mail]>]

8 sep 2011 kl. 08:19 skrev Silvia Pfeiffer:

> I'm arguing for leaving it out, since obviously it's already possible
> to support it in the browser through web sockets. We wouldn't put
> SMPTE support into browsers either just to be able to read email in
> browsers.
> 
> I wonder: if you are arguing for it, what is it that is not possible
> with such a JS implementation that would require introduction of a
> totally new technology into the browser (with all associated security
> risks)?
Oh, if you mean me I apologize for not being clear. I don't want SIP in rtcweb at all. Your examples are good examples on my way of thinking about rtcweb as a media layer for separate apps. That I want SIP to power those apps is a another issue :-)

/O
> 
> Silvia.
> 
> 
> On Thu, Sep 8, 2011 at 3:51 PM, Olle E. Johansson <[e-mail]> wrote:
>> 
>> 8 sep 2011 kl. 03:15 skrev Silvia Pfeiffer:
>> 
>> If implementations count for anything, check out:
>> 
>> http://phono.com/
>> and
>> https://docs.google.com/present/view?id=0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3BrOXNjZA&hl=en&pli=1
>> 
>> They use SIP with web sockets.
>> 
>> Nice. That will make it easy to hook in the rtcweb/webrtc media layer.
>> Now, I don't see clearly if you want to argue for or against SIP as part of
>> rtcweb standards with these examples, but that may be my biased eyes
>> reading... ;-)
>> /O
>> 
>> Cheers,
>> Silvia.
>> 
>> 
>> On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman
>> <[e-mail]> wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> 
>> rtcweb mailing list
>> 
>> [e-mail]
>> 
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> ---
>> * Olle E Johansson - [e-mail]
>> * Cell phone [phone], Office [phone], Sweden
>> 
>> 
>> 

---
* Olle E Johansson - [e-mail]
* Cell phone [phone], Office [phone], Sweden