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

["Ravindran Parthasarathi" <[e-mail]>]

Harald,

 

For browser as a SIP UA application, browser has to no need to compliant
with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also
agree with you that browser-to-browser communication, I could not see
the strong reason for supporting S/MIME. As part of the RTCWeb
architecture & solution, we will able to explore the SIP UA requirement
for making browser SIP compliant. Say for example, forking does not make
sense in case of browser as SIP UA application, forked response will be
rejected with CANCEL in browser without Javascript intervention. The
main requirement is to build the right SIP UA framework in browser by
which Javascript developer will be able to use to the maximum extent
without impacting the basic 2 two party communication in the internet.  

 

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel
a modern exchange in web world (Plain Old Telephony System phone with
exchange architecture). I think so because POTS phones are dumb which
does not know its identity and every event like offhook, onhook has to
passed to exchange (webserver) whereas RTCWeb client (browser) has to
pass every event to webserver and webserver has whole intelligence to
make it work. I got this feel more when someone is talking about MEGACO
or MGCP between RTCWEB client & webserver. My understanding is that SIP
does not fit well to legacy telephone-based paradigm by any means but
MEGACO or MGCP are the better choice which maps to SS7 architecture
well. I'm interested in seeing RTCWeb client perform the basic routing
rather than webserver does the routing on behalf of RTCWEb client.

 

I agree with you that in case it is local exchange (same site like skype
or Google hangout) communication, there will be no need of signaling but
I'm interested in communication with one of the Google real-time user in
internet without having any Google id.  I believe that SIP will make it
work.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:[e-mail]] 
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; [e-mail]; [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 09/07/11 19:29, Ravindran Parthasarathi wrote: 

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative dependencies including S/MIME.
It's not a small dependency.





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:

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

Why does that "intelligence" need to be in the browser, rather than in
the Javascript?



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. 

This only makes sense for applications that fit the "call an identified
party" paradigm.



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

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.

One protocol can be achieved by multiple applications choosing to
implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the
browser.



 

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.


I think the main thing you are missing is that there are many
applications that people want to build on top of RTCWEB that are not
telephones, and will not fit with telephone-based paradigms.