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

Hi Roman,

 

IIUC, SIP 2.0 (RFC 3261) and its extensions are not flexible for public
internet two-party communication and HTTP (websocket) + Javascript is a
better known solution for this communication but less efficient. I tend
to agree with you in case my understanding about your mail is correct. 

 

My way of looking at this problem solving using websocket with no other
its extension is that the time of market delivery of RTCWeb1.0 without
looking for the future. I'm worried because these sort of deliverables
creates chaos during RTCWeb2.0 wherein RTCweb2.0 will be restricted to
RTCWeb 1.0 to meet backward compatibility. Very good example is not that
folks are not interested in SIP 2.0 with its extensions or SIP 3.0 as
you mentioned below J

 

Please read inline.

 

Thanks

Partha

 

 

From: Roman Shpount [mailto:[e-mail]] 
Sent: Thursday, September 08, 2011 9:06 PM
To: Ravindran Parthasarathi
Cc: Harald Alvestrand; [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]

 

Partha,

What I am failing to understand is what you plan to use SIP for. 

[Partha] SIP for real-time communication using IETF standard.

SIP would be useful to call a SIP end point on the public IP or behind
the same NAT. If you want to call another SIP end point behind NAT,
especially if you need to use TCP to send ICE offers or security with
TLS, you will need an assistance of some type of server on the public
IP. In order for this to work both server and the client will need to
implement something like RFC 5626. This will require building something
fairly tricky to essentially proxy all the SIP requests from the client
to all the other SIP points. Building this is no easier then
implementing the same thing using an HTTP server application which works
with a client JavaScript library. If our primary goal were
implementation of Intranet SIP phones, that would be an acceptable
solution. For consumer oriented RTC service this is completely useless.

[Partha]. You are comparing RFC 5626 with
websocket(draft-ietf-hybi-thewebsocketprotocol ). Please correct me here

On the other hand extending SIP based infrastructure to implement new
functionality is a lot more complex. Adding new features will require
standardization or navigating a large number of conflicting SIP related
specifications which are currently in force. 

[Partha] I hope that you are talking about backward-compatibility issue
which I mentioned earlier. Any new protocol looks green for the basic
call and the mentioned supplementary services. While keep adding more
service, HTTP will land in the same place. So, I'm not fully convinced
here. I really don't know why do you think SIP based infrastructure is
complex but I agree with you that SIP API design matters.

Also, keep in mind that compliance to a lot of more advanced SIP
specifications does not necessarily imply easy interoperability with
existing devices. Compliance to a lot of those standards require a
custom SIP server or SBC which implements them using a much smaller
subset supported by each different SIP device. Bottom line, adding new
features in SIP based environment typically requires a lot of server
development, which is pretty much what will be required for doing
signaling via an HTTP connection.

[Partha] I agree with you that SIP interop is not straight forward
because legacy implementation issues but HTTP connection calls new
gateway with new mapping of the protocol. Please note that SIP
normalization in SBC is well established compare to creating new HTTP +
XML metadata to SIP gateways.



I will concur that using HTTP with JavaScript is a lot less efficient
then using SIP for both the client and the server, since client will
need to implement more functionality using JavaScript and the server
will need to maintain large number of connections and proxy all the
requests, but this is a drawback of any AJAX based solution. This is
something that seems to be acceptable to the industry and should not be
a decisive factor.

[Partha] The industry tries to re-use  existing infrastructure for easy
interop but does not mean that it is the best solution and IETF has to
be adopt the same. IETF shall provide the better protocol. The industry
adopts if the right protocol is designed or selected.


_____________
Roman Shpount



On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi
<[e-mail]> wrote:

Harald,

 

I'm proposing for "SIP UA framework for RTCWeb browser", the framework
provides Javascript API. In case you mean the same as "SIP lite". I'm
fine with it. SIP UA framework helps to support two-party communication
from RTCWeb browser and uses HTTP as presence or configuration
interface. 

 

As I mentioned in the another mail, I'm talking about INVITE subset of
RFC 3261 in browser.  

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:[e-mail]] 
Sent: Thursday, September 08, 2011 12:23 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/08/2011 07:09 AM, Ravindran Parthasarathi wrote: 

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.

So you're advocating for creating a "SIP lite" subset that RTCWEB
browsers implement.
I think we have been down this road before, and it's not a happy one.
But sure - if you want us to implement some part of SIP, *please start
stating what part* rather than making wooly statements.

Subsets are Real Hard Work.

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.

Don't forget that the RTCWEB client (the browser) contains an open,
fully programmable application platform - the Javascript engine. That's
a HUGE difference to the POTS phone.

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.

If by saying "the Google real time user in Internet", you mean a Google
Talk user, you have that already. It's called Google Voice. It uses SIP,
but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we
don't intend to support.

 

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.

 


_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb