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

[<[e-mail]>]

Hi,

The "web servers" in different domains could implement SIP and gateway calls from one domain to another that way. I think it is a reasonable assumption that basic voice calls (and maybe video) could interoperate between domains in this way without requiring SIP in the browser.

I mostly agree with Matthew's statements in this thread. I believe it is possible for an application developer to implement "call setup" (the "signaling") already in today's browsers, and Websockets is going to make that even a bit more efficient regardless of RTCWeb. So the RTCWeb should not focus on that aspect, but the missing part, which is the real-time media transport between browsers.

It is not a totally crazy idea to have SIP in the browser, though. It could be useful in many scenarios, like interacting with existing PBX or IMS infra, while adding some cool web based stuff in the app on the side. But in the interest of making progress in the more critical parts, I would postpone that standardization effort into the second phase of RTCWeb. Or maybe a new WG like SIPWeb :) This is of course based on the naïve assumption that the first phase of RTCWeb will not do anything that would prevent browsers to support SIP later on.

Markus


From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Ravindran Parthasarathi
Sent: 07 September, 2011 20:29
To: Matthew Kaufman; [e-mail]
Cc: [e-mail]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]

Matthew,

When I asked for SIP, I have meant RFC 3261 only. The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter.

My reasoning are as follows:

1)      SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.

2)      The importance of basic call interop is that there is no need of many individual id like skype id, Google id  and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

3)      SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.

4)      There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol.


In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let  me know in case I'm missing something here.

Thanks
Partha

From: Matthew Kaufman [mailto:[e-mail]]
Sent: Wednesday, September 07, 2011 2:55 AM
To: [e-mail]
Cc: Ravindran Parthasarathi; [e-mail]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]

On 9/6/11 6:13 AM, Igor Faynberg wrote:
I find this reasoning hard to understand.  First, the SIP standard has been around for a decade. What new standardization is needed?

The issue is whenever you wish to innovate and add functionality.

See the long, long list of RFCs that extend SIP. For some examples:
RFC3515 - Refer method
RFC3842 - Message waiting
RFC3891 - Replaces header
RFC3911 - Join header
RFC3960 - Early media
RFC4411 - Reason header for preemption

Never mind all the things that aren't even finished...

draft-ietf-bliss-shared-appearances
draft-ietf-bliss-call-park-extension

true bridged line appearances

etc

etc

If all you want is a basic point-to-point phone, there's a short list of RFCs you implement and you're done. But that isn't a platform for innovation... it is just a phone.

Matthew Kaufman