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

[Tim Panton <[e-mail]>]

Phono does not always use Flash and when it does, it uses flash _only_ to access the media.

Phono is structured as a XMPP implementation in Javascript that handles all the signalling to remote XMPP servers.
It then has what you might think of as an Javascript ServiceProviderInterface layer that provides  the streaming of audio from the microphone/speaker to/from an rtp endpoint. (and nothing else)

Currently there are 3 (or 4) implementations of the SPI, one uses flash, a second uses a java applet. It also has 
plugins for phonegap on iOS and android. All except the flash implementation speak native RTP. 

The important point is that the SPI is the same across all these implementations, so the XMPP layer is independent of the implementation details of the media access . 


I hope that clarifies things.

Tim.
On 12 Sep 2011, at 22:10, Jozsef Vass wrote:

> 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
>> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb