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

[Roman Shpount <[e-mail]>]

Just to adding my two cents on why SIP must not be used: SIP was designed
for a very different use case then rtcWeb. SIP was designed to run over UDP
on a network with no NAT. It was intended as a light weight protocol to
implement IP phones on the corporate networks. It was designed for devices
with limited resources and limited and fixed functionality. There was a
significant amount of effort to add support for SIP over NAT, but this is
far from being complete. Getting SIP over TCP to work from NAT environments
is still a challenge. Unfortunately you do need SIP over TCP to support ICE
due to the increased offer size. In fact, I am not aware of any system that
implements SIP over TCP over NAT (RFC 5626) in combination with ICE.

On the other hand, rtcWeb is designed for large number of clients running
behind NAT. We do not have the same limitations on the end user device
performance. There is no real reason to use UDP as primary signaling
protocol. Unlike on IP phones, HTTP client and JavaScript are already
available and will not create an additional implementation burden. Thus, I
think we should keep the offer/answer and use HTTP and JavaScript to
implement the signaling.
_____________
Roman Shpount


On Wed, Sep 7, 2011 at 3:07 AM, Olle E. Johansson <[e-mail]> wrote:

>
> 6 sep 2011 kl. 21:24 skrev Asveren, Tolga:
>
> > What about semantics (adding just a X-header won't help there) or how
> much SIP would be left anyhow if all semantical control is exposed through
> the API?
> >
> > I think bridged line appearance is a good test to run against different
> models.
> >
> Well, I tried to stay neutral but examples likes this makes me not want SIP
> in the browser. DTMF, Early Media, bridge line apperances and other PSTN
> legacy will make the implementation too focused on classical telephony and
> we'll spend too much time implementing features that are application
> specific and we can implement in controlling applications, client or
> server-side.
>
> Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but it
> will be hard to protect that from the myriad of extensions that add PSTN
> functionality that's not really needed to set up multimedia calls between
> two browser users. It may be needed for gatewaying to legacy systems, but if
> we don't "stop Olle in the gate" - verbatim translation of a Swedish saying
> that propably doesn't mean much to most people on the list - I think we will
> never be done.
>
> Of course, being a SIP developer, I started off with thinking that SIP in
> the browser was the default route. I am beginning to understand that the
> browser is the user interface part we all need, the media handler. We all
> have different requirements on how to control that media GUI and to get
> anywhere I am beginning to think the logic for signalling to set up
> rendevouz points and manage sessions has to move "somewhere else" where we
> can implement SIP, XMPP or some other protocol that fulfills the need of our
> respective application.
>
> To fearlessly  jump into another can of worms, I still think we should have
> confidentiality - SRTP - by default. We know that these applications will
> run on a myriad of devices on a myriad of networks and it will not work to
> let users have to decided whether or not they want confidentiality. If Skype
> did not have confidentiality by default, there would be articles every
> summer and xmas in the evening taboloids about how easy it is to listen in
> to your neighbours calls and that would have hurted Skype badly.
>
> /O
>
>
> > Thanks,
> > Tolga
> >
> >
> > -----Original Message-----
> > From: [e-mail] on behalf of Olle E. Johansson
> > Sent: Tue 9/6/2011 2:47 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]
> >
> >
> > 6 sep 2011 kl. 20:40 skrev Matthew Kaufman:
> >
> >> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote:
> >>> Matthew,
> >>>
> >>> Even in case of SIP, there is no need of standardization in case it is
> within single webserver(skype). SIP supports x-header or proprietary header
> to extend the way you want it for providing innovative functionality.
> >>
> >> Not if SIP is baked in to the browser it doesn't. If the browser
> implements a SIP phone in native code, I have no way of adding "x-header" or
> anything else. I live with the functionality provided by the browser.
> > That's an implementation detail. One can easily add an API call to add
> headers on the outbound INVITE.
> >
> >>
> >> If on the other hand, you want SIP implemented in Javascript then sure,
> if a developer wants to use it, great. If they want to extend it, that's
> fine too. And if they'd rather use another model, they are free to do that.
> Just as you would expect from a *platform*.
> >>
> >>> There is no extension barrier from SIP perspective but it ensure that
> basic call works across web servers. For example, skype browser user will
> able to talk to gmail real-time user even though all skype functionality are
> not supported.
> >> See above.
> >>>
> >>> In case you have the points why HTTP allows innovation but SIP will
> not, let us discuss in detail.
> >>
> >> See above. I want you to be free to use SIP, but not *required* to use
> SIP.
> >>
> >> And there's some security reasons that I'd rather you tunnel it over
> HTTP rather than opening up your ability to send UDP packets to port 5060.
> > SIP runs on TCP and TLS ports too.
> >
> > I am not arguing for either side, just correcting some details...
> >
> > /O
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> ---
> * Olle E Johansson - [e-mail]
> * Cell phone [phone], Office [phone], Sweden
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>