Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket

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

Hi all,

 

I agree with Markus for the performance concern of SIP stack in  JS and
it is based on  SIP Stack implementation comparison  between Java &
C/C++ implementation.  Also, I understand the concern by Roman that RFC
3261 does not consider NAT issue into its protocol design and it
requires RFC 5626 implementation. 

 

I have explained my point of view between websocket & SIP in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. SIP
with websocket is a overkill instead SIP with RFC 5626 or websocket with
XML (like Jingle) shall be used.  I'm saying SIP with websocket as
overkill because of the following reason:

 

1)      Websocket helps for creating two communication between browser &
server.  

2)      Server has all the intelligence required for routing between
peer browsers or peer server.

        There is no need of one layer (SIP) above to create the dialog
but lightweight XML signaling mechanism works.

 

Only limitation, I'm seeing with websocket + XML is that it calls for
gateway in case of federation. I wish to hear the comments from Inaki &
other author on this.

 

Apart from this, I don't know believe in providing the platform for
signaling in IETF but IETF has to standardize anyone of the protocol as
a standard rather than developer choice. It may be  common practice for
generalized products to provide platform for developing any signaling
protocol (SIP, Jingle, H.323, MEGACO) but IETF should not follow path
for any protocol which breaks the spirit of standardization. Let us
compare any number protocols and at least recommend one signaling
protocol as a choice for IETF RTCWeb client which has to be present
natively for web developers.

 

Thanks

Partha

 

 

 

From: Bernard Aboba [mailto:[e-mail]] 
Sent: Wednesday, September 14, 2011 3:35 AM
To: [e-mail]; Ravindran Parthasarathi; [e-mail];
[e-mail]
Subject: RE: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket

 

> I really don't know the strong reason for tunneling SIP message within
websocket. 


[BA] Are you questioning the use of Websockets as opposed to other
potential mechanisms for tunneling SIP messages over HTTP transport?

If the question is why you'd tunnel {SIP, XMPP} over HTTP/Websockets at
all,  this enables the implementation of {SIP, XMPP} in Javascript.  

> If SIP is implemented in Javascript, as opposed to "natively"
supported in the browser, Websocket is the best transport for it.

[BA] That may be your opinion.  Others may choose to transport SIP over
HTTP or HTTPS, or choose some other signaling protocol entirely (e.g.
XMPP).  The beauty of RTCWEB is to enable the choice to be made by
application developers according to their needs. 

> I could see a path here that the SIP server vendors should add SIP
over WebSockets in their arsenal of transport options

[BA] They might do that, or they could choose to have a "Connection
Manager" (e.g. something that speaks SIP over Websockets on one side,
and SIP over TCP on the other) do the encapsulation/decapsulation.  

> So maybe this draft is something that should be taken to Standards
Track within the RAI area, ASAP.

[BA] The main point is that this work need not be done in RTCWEB.