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]>]

Matthew,

 

Could you please let me know why early media MUST exist in browser to
browser communication. Remote ringback (18x with SDP) is less used in
lot of existing SIP deployments as well. I'm talking about RFC 3261 User
Agent (UA) functionality in browser which helps browser to browser
real-time communication using RTCWeb1.0. SIP phone is very different
from SIP UA which is using HTTP as a configuration interface. 

 

Also, 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 whereas
RTCWeb client (browser) has to pass every event to webserver and
webserver has whole intelligence to make it work. In case it is local
exchange (same site like skype), there will be no need of signaling but
the identity is outside the single site, it is not defined and it is
outside the scope of RTCWEb.

 

Please read inline.

 

Thanks

Partha

 

From: Matthew Kaufman [mailto:[e-mail]] 
Sent: Thursday, September 08, 2011 3:53 AM
To: Ravindran Parthasarathi
Cc: [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 9/7/11 10:29 AM, Ravindran Parthasarathi wrote: 

Matthew,

 

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


As I pointed out earlier, this is the top of a very slippery slope.

Certainly you must have meant 3261 + early media + PRACK (for instance),
yes?




The basic reason for asking SIP is to make the basic call works between
browser to browser across web servers.


SIP is in no way required to make this happen.

[Partha] Please explain in more detail why so.

 






Without SIP in browser, it is not going happen. 


Totally disagree.



Innovative application is going to be proprietary whether it is HTTP or
SIP or any other protocol for that matter.


True. But having to reverse-engineer out the phone part is really
painful for the application developer who is trying to build something
else.

[Partha] I have worked in multiple SIP UA implementation which is not
restricted to telecom or unified communication as part of one of best
selling SIP UA stack company. I'm really wondering why phone to be
reverse Engineered. I'm wondering why browser is not possible to acts as
SIP UA. 

 






 

My reasoning are as follows:

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


SIP in the browser makes the browser less *flexible* than an API with
more direct control over the internal objects (camera, codec, network
connection) and yet no more intelligent, as the browser has a runtime
that can be programmed to do anything you want at the client side.

[Partha] I'm talking abt SIP UA framework which provides Javascript API.
There is no flexibility issue here because Javascript API will have all
the control which you are interested.






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 isn't going to happen, and is even closer to my fears about "IMAP
in the browser" expressed earlier.

[Partha] they are different.






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


So what? I hope people understand that RTCWEB could be about so much
more than enterprise and telecom providers doing two-party phone calls.

Among other things, you can build augmented reality systems out of it
(see how Flash streaming has been used similarly), multi-party
experiences that aren't calls (Google hangouts), and many other
applications we haven't even thought of yet... as long as we don't
cripple the APIs.



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.


It doesn't even work over that "one signaling protocol", so that doesn't
help. And again, there is no reason that a web site providing RTC
applications to/from a browser need necessarily be serving "SIP phones"
as clients as well. Maybe that just isn't the business they're in.



 

In RTCWEB does not standardize the signaling protocol interface between
browsers, the interop across webservers is next to impossible


Totally disagree. We need to standardize the *media transport* between
the browsers, and W3C needs to standardize the *API* by which we can
send Javascript to the browser that executes the same way on every
browser, but that doesn't mean the signaling protocol needs to be
specified any more than IETF needed to intervene to ensure that the XML
or JSON data that goes between your browser and Gmail is the same as the
data that goes between your browser and Yahoo mail when you're using
each to compose email messages.

[Partha] Please note that I'm talking about viewer about partha.com to
start the real-time communication with partha with his (Android) browser
if they are interested. To achieve this, partha.com webdeveloper has no
need to build call control in case SIP exists in both browsers. 






and it will be restricted to single webserver (company) only. 


Disagree. Just like Gmail and Yahoo mail can send messages to each
other's users over a standard protocol for federation, so can RTCWEB. In
fact, SIP is probably a great choice for inter-provider trunking. And
conveniently, we plan to support the same *media transport* that other
SIP devices use (RTP), so there'll be even more interoperability than
just browser-to-browser federated between providers.




Please let  me know in case I'm missing something here.


See above.

Matthew Kaufman