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

[Roman Shpount <[e-mail]>]

Neither do they websockets (they use BOSH
http://xmpp.org/about-xmpp/technology-overview/bosh/) or SIP (at least not
for client to server communications).
_____________
Roman Shpount


On Mon, Sep 12, 2011 at 5:10 PM, Jozsef Vass <[e-mail]> 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
>