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,

 

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