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

[Jozsef Vass <[e-mail]>]

Neither the website nor the documents mention the use of Flash, which is evident if you try the app. They also make use of the acoustic echo cancellation capability available in Flash.

Jozsef

-----Original Message-----
From: Silvia Pfeiffer [mailto:[e-mail]] 
Sent: Wednesday, September 07, 2011 6:16 PM
To: Matthew Kaufman
Cc: [e-mail]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]

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.

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
>