Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 13 Sep 2011 19:13:12 +0200

Hi all,

A draft describing a mechanism for usage of WebSocket protocol as the
transport between SIP entities has been submitted and can be found at:

  HTML:  http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00
  TXT:     http://www.ietf.org/id/draft-ibc-rtcweb-sip-websocket-00.txt

Abstract

   This document specifies a WebSocket subprotocol for a new transport
   in SIP (Session Initiation Protocol).  The WebSocket protocol enables
   two-way realtime communication between clients (typically web-based
   applications) and servers.  The main goal of this specification is to
   integrate the SIP protocol within web applications.

We produced this initial version after implementing a working prototype.

Your feedback is always welcome,
The Authors

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 13 Sep 2011 23:12:54 +0530

Hi Inaki,

I like the idea of using SIP between browser & server. 

I really don't know the strong reason for tunneling SIP message within websocket. In fact, we are discussing SIP vs websocket in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html mail thread as signaling protocol for RTCweb. Could you please mention the technical advantage in going in the path of SIP over websocket rather than having plain SIP connection over TCP or TLS or (UDP or DTLS).

Thanks
Partha
 
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Iñaki Baz Castillo
>Sent: Tuesday, September 13, 2011 10:43 PM
>To: [email-masked]
>Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport
>for Session Initiation Protocol (SIP)
>
>Hi all,
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Sep 2011 14:00:27 -0400

Partha,

I am not sure if you understood this from my emails before, but the main
advantage is that SIP does not work from behind NAT if TCP or TLS is used.
SIP is not intended for this and does not support this. You can try to build
something which is somewhat standard to implement SIP over TCP (TLS) from
behind NAT, but I do not think this is widely implemented at all.
_____________
Roman Shpount

On Tue, Sep 13, 2011 at 1:42 PM, Ravindran Parthasarathi <
[email-masked]> wrote:

> I really don't know the strong reason for tunneling SIP message within
> websocket. In fact, we are discussing SIP vs websocket in
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html mail
> thread as signaling protocol for RTCweb. Could you please mention the
> technical advantage in going in the path of SIP over websocket rather than
> having plain SIP connection over TCP or TLS or (UDP or DTLS).
>
> Thanks
> Partha
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 13 Sep 2011 20:22:47 +0200

> I really don't know the strong reason for tunneling SIP message within websocket. In fact, we are discussing SIP vs websocket in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html ma…

Hi Ravindran,

SIP is a complex protocol and there are numerous extensions and
features in many RFC's extending the SIP protocol. Having to rely on
the features implemented in a native SIP stack within the web-browser
seems not enough flexible IMHO. I also expect many limitations and
lack-of-features in the different SIP implementations of each browser
(and each version of the browser).

In the other side, if the SIP stack is coded within a JavaScript
library and makes usage of the WebSocket protocol, innovation depends
on the developer and not on the browser native capabilities. A web
page could offer a minimal SIP stack just implementing basic outgoing
calls (i.e. "Click2Call" buttons in the web), while another web page
could prefer to provide a powerful SIP stack implementing
blink/attended transfer, subscription to presence and dialogs/calls,
conference features, call-pickup, SIP messaging and so on (imagine
such phone integrated within an enterprise intranet). I don't expect
that the SIP stack integrated within *every* existing web-browsers
would implement all those SIP features in a correct way (because that
does not happen neither when using expensive SIP desktop phones or
softphones).

Also, the specification defined in the draft solves NAT issues (at
signaling level) without requiring server side solutions for fixing
NAT in clients.

WebSocket protocol is becoming a new "transport" protocol.
Implementing SIP protocol on top of it can only bring advantages and
new possibilities. The specification in the draft is an adaptation of
SIP to make use of WebSocket, as it already does with UDP, TCP and
SCTP transports.

BTW, as said in the first mail, we have published the draft after
having a working prototype making usage of the specification described
in the document. After that, we see no real advantage on having a
native SIP stack within a web browser. The prototype will be shown
soon.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 13 Sep 2011 14:29:07 -0400

SIP (unlike HTTP) is symmetric in that a SIP client can get, 
asynchronously, messages from another client (e.g., INVITE) or a server 
(e.g., NOTIFY).  Websocket provides a capapility to recieve messages out 
of the blue.

On 9/13/2011 1:42 PM, Ravindran Parthasarathi wrote:
> ...
>
> I really don't know the strong reason for tunneling SIP message within websocket.
...

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 19:07:56 +0000

Hi,

>having plain SIP connection over TCP or TLS or (UDP or DTLS).

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

I could see a path here that the SIP server vendors should add SIP over WebSockets in their arsenal of transport options, and this way those servers could become easily usable by WebRTC providers. As a counterpart we would need a good open source Javascript SIP library, with the WebSocket support. And then, wouldn't we have achieved what everyone wants? We have managed to keep SIP out of the browser, as some people like. Yet we have enabled WebRTC providers and app developers to use SIP, as some other people prefer. And finally, SIP infra vendors can continue selling their gear, WebRTC compliant :-) 

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

Markus

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 19:25:03 +0000

Hi Inaki,

Fully agree about everything you say below. 

It would be interesting to understand the performance differences of the native vs. Javascript SIP stack, if there is anything we should be worried about. This is my only concern when (perhaps one day) applying RTCWeb in devices like smartphones. If the JS stack works in (any of) today's high end smartphones without problems, we should be fine.

Markus

>Of ext Iñaki Baz Castillo
>Sent: 13 September, 2011 21:23
>To: Ravindran Parthasarathi
>Cc: [email-masked]
>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport
>SIP is a complex protocol and there are numerous extensions and features in
>many RFC's extending the SIP protocol. Having to rely on the features
>implemented in a native SIP stack within the web-browser seems not enough
>flexible IMHO. I also expect many limitations and lack-of-features in the
>different SIP implementations of each browser (and each version of the
>browser).
>
>In the other side, if the SIP stack is coded within a JavaScript library and makes
>usage of the WebSocket protocol, innovation depends on the developer and
>not on the browser native capabilities. A web page could offer a minimal SIP
>stack just implementing basic outgoing calls (i.e. "Click2Call" buttons in the
>web), while another web page could prefer to provide a powerful SIP stack
>implementing blink/attended transfer, subscription to presence and
>dialogs/calls, conference features, call-pickup, SIP messaging and so on
>(imagine such phone integrated within an enterprise intranet). I don't expect
>that the SIP stack integrated within *every* existing web-browsers would
>implement all those SIP features in a correct way (because that does not
>happen neither when using expensive SIP desktop phones or softphones).
>
>Also, the specification defined in the draft solves NAT issues (at signaling
>level) without requiring server side solutions for fixing NAT in clients.
>
>Implementing SIP protocol on top of it can only bring advantages and new
>possibilities. The specification in the draft is an adaptation of SIP to make use
>of WebSocket, as it already does with UDP, TCP and SCTP transports.
>
>
>BTW, as said in the first mail, we have published the draft after having a
>working prototype making usage of the specification described in the
>document. After that, we see no real advantage on having a native SIP stack
>within a web browser. The prototype will be shown soon.
>
>Best regards.
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Thomas <[email-masked]>
Date: Tue, 13 Sep 2011 23:02:44 +0200

Hi Iñaki, 

Thanks for the proposal. This is an approach that we had also in mind and have just started to prototype a WS transport layer in cipango (which is an open source SIP Servlets AS based on Jetty). 
As a result, if you are willing to share the Javascript SIP/WS UA, we'll be very glad to contribute and provide interoperability feedback. 

Regards, 

Thomas

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 13 Sep 2011 15:04:50 -0700

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

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 13 Sep 2011 15:42:05 -0700

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

Right.

Notice here in "EAP multiplexing model" (for smartcards):

http://tools.ietf.org/html/draft-urien-eap-smartcard-21#section-2.1

In cars, that would be PPPoE instead of PPP if we map from SIP. The 
developer curve is.... not stateless.

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 14 Sep 2011 06:03:59 +0530

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:[email-masked]] 
Sent: Wednesday, September 14, 2011 3:35 AM
To: [email-masked]; Ravindran Parthasarathi; [email-masked];
[email-masked]
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.

---

From: Binod PG <[email-masked]>
Date: Wed, 14 Sep 2011 10:08:31 +0530

On 14-Sep-11, at 3:34 AM, Bernard Aboba wrote:

> If the question is why you'd tunnel {SIP, XMPP} over HTTP/Websockets  
> at all,  this enables the implementation of {SIP, XMPP} in Javascript.
>
> [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.

How do you see a media gateway library in the (web) server handle all  
such signaling protocols/transport? Would RTCWeb provide/have a  
mechanism
to indicate the protocol/signal chosen by the application?

thanks,
Binod.
[As an Individual]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Sep 2011 05:23:04 +0000

On Sep 14, 2011, at 12:38 AM, Binod PG wrote:

> How do you see a media gateway library in the (web) server handle all such signaling protocols/transport? Would RTCWeb provide/have a mechanism

No.  The server is deployed by the same people who deploy the javascript, since by definition the javascript is provided by that server.  It's not a mystery to the web server what the "signaling protocol" used between the javascript and the server is - its whatever the developer of the javascript and server-side code decides it to be.  It doesn't have to be any standard whatsoever, because there is no interoperability problem to solve between them.  It could be XMPP, or it could be SIP, or it could be MGCP, or it could be Skinny/SCCP, or it could be create-your-own.  There may well be pre-packaged js libraries available which do it all for you, but they can do it however they like. 

-hadriel

---

From: Binod PG <[email-masked]>
Date: Wed, 14 Sep 2011 11:23:50 +0530

On 14-Sep-11, at 10:53 AM, Hadriel Kaplan wrote:

>>> 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.
>>
>> How do you see a media gateway library in the (web) server handle  
>> all such signaling protocols/transport? Would RTCWeb provide/have a  
>> mechanism
> No.  The server is deployed by the same people who deploy the  
> javascript, since by definition the javascript is provided by that  
> server.  It's not a mystery to the web server what the "signaling  
> protocol" used between the javascript and the server is - its  
> whatever the developer of the javascript and server-side code  
> decides it to be.  It doesn't have to be any standard whatsoever,  
> because there is no interoperability problem to solve between them.   
> It could be XMPP, or it could be SIP, or it could be MGCP, or it  
> could be Skinny/SCCP, or it could be create-your-own.  There may  
> well be pre-packaged js libraries available which do it all for you,  
> but they can do it however they like.

A webserver can host multiple web applications (potentially from  
multiple vendors altogether). If some web applications need to gateway  
between browser and another legacy protocol (eg: SIP, XMPP....), then
a good number of applications would like to use a generic media  
gateway component or library.  For someone to develop such a media  
gateway library, doesn't it need to know, what protocol it is brokering?

Or you do not consider that to be an important aspect?

- Binod.

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Wed, 14 Sep 2011 14:23:34 +0800

Hi Inaki

I have few initial comments on your draft

1) in Section 3, its mentioned that there is no real benefit of using SIP over Websockets. If this is the case, why are you proposing integrating SIP with Websockets?
2) Also just integrating SIP for signaling case is really no use, as there are several other ways of achieving signaling in web - E.g. using libjingle of WebRTC, etc
3) In Section 4, you mentioned that since Websocket is a reliable transport protocol, the websocket sub-protocol defined for SIP also becomes reliable. I don't agree with this - The websocket connection is actually initiated by the web browser client towards the web server and this connection needs to be kept alive through some keep alive mechanism. Otherwise the connection may close. I am not sure of reliability.
4) In Section 4.1,I am not clear of the Via transport parameter having the value of "WS". Why do you need this when the whole SIP message is going as part of WebSocket payload [Using websocket API]?

Thans

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: Tuesday, September 13, 2011 10:43 PM
To: [email-masked]
Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)

Hi all,

Abstract

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 06:58:43 +0000

Hi,

>[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…

People can continue using HTTP ("COMET") for this type of purposes as long as they like. I think Websockes is just a more optimal way due to smaller overhead and cleaner connection management. But it is upto the service provider, and of course availability of Websockets in browsers is an important factor too.

>[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/decapsul…

Right. I suppose there are these type of things for XMPP already, i.e. speaking XMPP over BOSH/HTTP one way and XMPP over TCP the other. The same could be useful for SIP, if Javascript SIP stacks gain popularity. (They are certainly popular on this list, but I'm not sure if that is a good measure of the "real world" :-). People could make their deployments without a formal standardization of SIP over HTTP or SIP over Websockets too, at least as long as the Javascript stack and the "connection manager" came from the same provider. Hmm, perhaps that is good enough. 

Markus

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 14 Sep 2011 09:02:29 +0200

Hi,

> 1) in Section 3, its mentioned that there is no real benefit of using SIP over Websockets. If this is the case, why are you proposing integrating SIP with Websockets?

That's not exactly what it says. It says that there is no real benefit in using SIP over WbSocket *IF* not using it within a browser. And we are talking browsers here :-)

> 2) Also just integrating SIP for signaling case is really no use, as there are several other ways of achieving signaling in web - E.g. using libjingle of WebRTC, etc

Then if you'd want to interoperate with SIP you'd have to build a gateway, whereas if we already use SIP, no gateway is needed, just a new transport.

> 3) In Section 4, you mentioned that since Websocket is a reliable transport protocol, the websocket sub-protocol defined for SIP also becomes reliable. I don't agree with this - The websocket conne…

Have a look at section 8. Since the WebSocket keepalive is not yet standardized a TCP style (CRLFCRLF) keepalive could be used. I would consider WebSocket reliable, do you see it as UDP?

> 4) In Section 4.1,I am not clear of the Via transport parameter having the value of "WS". Why do you need this when the whole SIP message is going as part of WebSocket payload [Using websocket API]?

The packet may traverse numerous proxies, someone might be interested in knowing it. Its also consistent, since the packet did originate in a WS transport.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 10:43:30 +0200

> 1) in Section 3, its mentioned that there is no real benefit of using SIP over Websockets. If this is the case, why are you proposing integrating SIP with Websockets?

As Saul pointed out, the text says:

   There is no benefit on using SIP over WebSocket  transport between
   two SIP nodes when none of them runs within a web browser.

JavaScript can open a WebSocket connection from a web browser to a
server, but not an arbitrary TCP or UDP connection.

> 2) Also just integrating SIP for signaling case is really no use, as there are several other ways of achieving signaling in web - E.g. using libjingle of WebRTC, etc

The fact that there are other alternatives for signaling in the web
does not mean that using SIP is invalid.
If I want to build a SIP phone in a web, why should I use libjingle
rather than SIP protocol? Why should I code a complex server behaving
as a gateway between Jingle and SIP protocols?

Any protocol conversion (i.e. from Jingle to SIP) means loss of
features. Our draft proposes the contrary: no protocol conversion
(just SIP), and just transport protocol conversion (as already exists
in SIP when bridging UDP/TCP/TLS-TCP/SCTP...).

> 3) In Section 4, you mentioned that since Websocket is a reliable transport protocol, the websocket sub-protocol defined for SIP also becomes reliable. I don't agree with this - The websocket conne…

"Reliability" does not mean that. "Reliability" means data delivery
acknowledgment in the transport. This is true in TCP (so also in
WebSocket which works on top of TCP) and false in UDP (which is not a
reliable transport protocol).

The keep-alive mechanism is needed for cases in which there is a NAT
router in the path. Those routers usually close a TCP connection after
some minutes of inactivity. This happens in any TCP connection from
client to server through a NAT box.

> 4) In Section 4.1,I am not clear of the Via transport parameter having the value of "WS". Why do you need this when the whole SIP message is going as part of WebSocket payload [Using websocket API]?

This is how SIP protocol works and this is explained in RFC 3261. You
can also check a similar example for SIP over SCTP transport at:

  http://tools.ietf.org/html/rfc4168#section-4

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 11:23:32 +0200

2011/9/14 Ravindran Parthasarathi <[email-masked]>:

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

Hi Ravindran, I've replied to a similar question in this mail (point 2):
  http://www.ietf.org/mail-archive/web/rtcweb/current/msg01120.html

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Sep 2011 11:45:58 +0200

Hi,

Thanks for putting the draft together.

I agree with Markus, and others, that WebSocket is a feasible solution in the case of using a JS SIP app.

>> 1) in Section 3, its mentioned that there is no real 
>> benefit of using SIP over Websockets. If this is the case, 
>> why are you proposing integrating SIP with Websockets?
> 
> JavaScript can open a WebSocket connection from a web browser 
> to a server, but not an arbitrary TCP or UDP connection.

I have a comment, related to this.

The text says:

   "Even more, the WebSocket protocol is not symmetric since
   just a WebSocket client can open a connection to a WebSocket server
   (a WebSocket client does not listen for incoming connections)."

But, this is of course also true when you DO use a browser, but it's not really addressed in the draft. You need to describe that it is assumed that the WebSocket connection has been established at the point when the browser is supposed to be able to receive incoming SIP calls.

For example, the WebSocket could be established once the JS app is downloaded, or when the JS SIP client registers (similar to how SIP Outbound works).

>> 3) In Section 4, you mentioned that since Websocket is a 
>> reliable transport protocol, the websocket sub-protocol 
>> defined for SIP also becomes reliable. I don't agree with 
>> this - The websocket connection is actually initiated by the 
>> web browser client towards the web server and this connection 
>> needs to be kept alive through some keep alive mechanism. 
>> Otherwise the connection may close. I am not sure of reliability.
>> 
> "Reliability" does not mean that. "Reliability" means data 
> delivery acknowledgment in the transport. This is true in TCP 
> (so also in WebSocket which works on top of TCP) and false in 
> UDP (which is not a reliable transport protocol).
> 
> The keep-alive mechanism is needed for cases in which there 
> is a NAT router in the path. Those routers usually close a 
> TCP connection after some minutes of inactivity. This happens 
> in any TCP connection from client to server through a NAT box.

Since WebSocket provides a keep-alive function, you can of course use that. I guess it could still be mentioned that a SIP level mechanism exists.

Regards,

Christer

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 14 Sep 2011 15:33:14 +0530

Hi Inaki,

<snip> 

The fact that there are other alternatives for signaling in the web does not mean that using SIP is invalid.
If I want to build a SIP phone in a web, why should I use libjingle rather than SIP protocol? Why should I code a complex server behaving as a gateway between Jingle and SIP protocols?

Any protocol conversion (i.e. from Jingle to SIP) means loss of features. Our draft proposes the contrary: no protocol conversion (just SIP), and just transport protocol conversion (as already exists in SIP when bridging UDP/TCP/TLS-TCP/SCTP...).
</snip> 

I agree with your problem statement. I have raised the same concern in http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. IMO, your solution is a workaround and we will end-up with your solution in case signaling protocol is not standardized as part of RTCWeb.

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Wednesday, September 14, 2011 2:54 PM
>Cc: Bernard Aboba; [email-masked]; [email-masked]; Roman
>Shpount
>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket
>
>but

---

From: José Luis Millán <[email-masked]>
Date: Wed, 14 Sep 2011 12:42:26 +0200

Hi,

Let's clarify that the submitted draft states a way to adopt WebSocket as a
transport protocol for SIP.  This makes feasible the SIP communication
between WebSocket capable nodes and nodes using other transports defined in
SIP, which facilitates the inter-operation within nowadays implementations
and implementations to be defined in this group.

We are not proposing this specification as the unique/only signaling
protocol within WebRTC. That's another subject out of the scope of the
draft.

Regards.

2011/9/14 Ravindran Parthasarathi <[email-masked]>

> If I want to build a SIP phone in a web, why should I use libjingle rather
> than SIP protocol? Why should I code a complex server behaving as a gateway
> between Jingle and SIP protocols?
>
> Any protocol conversion (i.e. from Jingle to SIP) means loss of features.
> Our draft proposes the contrary: no protocol conversion (just SIP), and just
> transport protocol conversion (as already exists in SIP when bridging
> UDP/TCP/TLS-TCP/SCTP...).
> </snip>
>
> I agree with your problem statement. I have raised the same concern in
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. IMO,
> your solution is a workaround and we will end-up with your solution in case
> signaling protocol is not standardized as part of RTCWeb.
>
> Thanks
> Partha
>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 12:43:43 +0200

> But, this is of course also true when you DO use a browser, but it's not really addressed in the draft. You need to describe that it is assumed that the WebSocket connection has been established at…

Hi Christer. IMHO that is already addressed in the draft:

----------------------------------------------------
6.  WebSocket Client Usage

   As stated in [I-D.ietf-hybi-thewebsocketprotocol], a WebSocket URI
   [RFC3986] is given to the WebSocket client (typically within a web-
   based application) who resolves the URI destination and establishes a
   WebSocket connection with the corresponding server (by performing the
   handshake and negotiation procedures described in
   [I-D.ietf-hybi-thewebsocketprotocol]).
-----------------------------------------------------

> For example, the WebSocket could be established once the JS app is downloaded,

But that is obvious given the WebSocket protocol nature. The client
MUST establish a WebSocket connection with the server before
attempting to send or receive WebSocket messages.

Could you please point to the exact section in the draft in which you
miss such explanation? We'll be very glad to improve it.

> or when the JS SIP client registers (similar to how SIP Outbound works).

In normal scenarios the client must register in order to receive
incoming SIP calls, but that is not a MUST. For example a WebSocket
server could route INVITE requests to connected WebSocket clients
without previous SIP registration made by the clients. It would be up
to the provider local policy. I don't think the draft should mandate
SIP registration in order to receive calls (neither RFC 3261 mandates
it), as registration is just one of the existing ways for receiving
incoming calls, but not the unique. Am I wrong?

> Since WebSocket provides a keep-alive function, you can of course use that.

Current limitation exists in WebSocket API since it does not provide a
way for the client to send Ping frames to the server. Please check the
open request in the W3C tracker about this topic:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13104#c3

> I guess it could still be mentioned that a SIP level mechanism exists.

I assume you mean the CRLF+CRLF mechanism defined in RFC 5626
"Managing Client-Initiated Connections in SIP" which is a technique
for SIP clients to keep the connection open by sending CRLF+CRLF and
receiving CRLF reply from the proxy/server.

RFC 5626 says:

---------------------------------
3.5.1.  CRLF Keep-Alive Technique

   This approach can only be used with connection-oriented transports
   such as TCP or SCTP.  The client periodically sends a double-CRLF
   (the "ping") then waits to receive a single CRLF (the "pong").  If
   the client does not receive a "pong" within an appropriate amount of
   time, it considers the flow failed.
-------------------------------

Since SIP WebSocket transport (as defined in the draft) is also a
reliable transport, we could mention the usage of this keepalive
technique in the draft, is it ok?

Thanks a lot for your input.
Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Sep 2011 13:11:18 +0200

Hi, 

>>   just a WebSocket client can open a connection to a 
>>   WebSocket server (a WebSocket client does not listen for incoming 
>>   connections)."
>>
>> But, this is of course also true when you DO use a browser, 
>> but it's not really addressed in the draft. You need to 
>> describe that it is assumed that the WebSocket connection has 
>> been established at the point when the browser is supposed to 
>> be able to receive incoming SIP calls.
> 
>    based application) who resolves the URI destination and 
>    establishes a WebSocket connection with the corresponding server (by 
>    performing the handshake and negotiation procedures described in

Well, that describes HOW the WebSocket is established.

--------

>But that is obvious given the WebSocket protocol nature. The 
>client MUST establish a WebSocket connection with the server 
>before attempting to send or receive WebSocket messages.

Of course. But, as you describe the WebSocket usage for SIP, I think it needs to be stated WHEN that can occur for SIP.

--------

>Could you please point to the exact section in the draft in 
>which you miss such explanation? We'll be very glad to improve it.

I would like something like:

	"When the WebSocket is used to transport SIP traffic, the WebSocket MUST be established at the point where
	the browser SIP application shall be able to place and receive SIP calls. Based on local policy, this might
	e.g. occur once the JavaScript SIP application has been downloaded from the web server, or when the
	SIP user using the browser application registers itself to a SIP registrar (assuming that calls cannot be
	placed or received before that)."

I guess text text could fit either in section 4.x, or in section 6. 

--------

>In normal scenarios the client must register in order to 
>receive incoming SIP calls, but that is not a MUST. For 
>example a WebSocket server could route INVITE requests to 
>connected WebSocket clients without previous SIP registration 
>made by the clients. It would be up to the provider local 
>policy. I don't think the draft should mandate SIP 
>registration in order to receive calls (neither RFC 3261 
>mandates it), as registration is just one of the existing 
>ways for receiving incoming calls, but not the unique. Am I wrong?

I was not suggesting that we mandate registration. It was just an example of when one could choose to establish the WebSocket, IF the browser shall be able to receive incoming calls after registration. If it shall be able to receive incoming calls before the registration (or, if there is no registration in the first place), the WebSocket needs to be established at some other point.

--------

>>> The keep-alive mechanism is needed for cases in which 
>>> there is a NAT router in the path. Those routers usually close a TCP connection 
>>> after some minutes of inactivity. This happens in any TCP 
>>> connection from client to server through a NAT box.
>>
> Current limitation exists in WebSocket API since it does not 
> provide a way for the client to send Ping frames to the 
> server. Please check the open request in the W3C tracker 
> about this topic:
> 
> "Managing Client-Initiated Connections in SIP" which is a 
> technique for SIP clients to keep the connection open by 
> sending CRLF+CRLF and receiving CRLF reply from the proxy/server.
> 
> RFC 5626 says:
> 
> Since SIP WebSocket transport (as defined in the draft) is 
> also a reliable transport, we could mention the usage of this 
> keepalive technique in the draft, is it ok?

I think it's better to refer to RFC 6223, which only covers the keep-alive part of RFC 5626.

(RFC 5626 contains also contains other stuff that most likely doesn't apply for the browser case).

--------

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 14:18:13 +0200

> I guess text text could fit either in section 4.x, or in section 6.

Thanks a lot. I've added a very similar text in section 6 (second paragraph):

------------------------------
6.  WebSocket Client Usage

   As stated in [I-D.ietf-hybi-thewebsocketprotocol], a WebSocket URI
   [RFC3986] is given to the WebSocket client who resolves the URI
   destination and establishes a WebSocket connection with the
   corresponding server (by performing the handshake and negotiation
   procedures described in [I-D.ietf-hybi-thewebsocketprotocol]).

   The WebSocket connection MUST be established at the point where the
   client application (typically a web-based application) shall be able
   to place and receive SIP calls.  Based on local policy, this might
   e.g. occur once the JavaScript SIP application has been downloaded
   from the web server, or when the SIP user using the web-browser
   application registers itself to a SIP registrar (assuming that calls
   cannot be placed or received before that).

   The client application is supposed to be provided with SIP account
   configuration values (as an AoR, outbound proxy and so on).  Such
   values are used by the client application when generating SIP
   messages.
-----------------------------

> I was not suggesting that we mandate registration. It was just an example of when one could choose to establish the WebSocket, IF the browser shall be able to receive incoming calls after registrat…

It's clear now :)

> (RFC 5626 contains also contains other stuff that most likely doesn't apply for the browser case).

Good point. It will be mentioned in version -01 of the draft (along
with the above text addition suggested by you).

Thanks a lot for your input. Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 18:39:05 +0200

> with the above text addition suggested by you).

Hi Christer, I've added the following text at the end of section 8:

-------------------------------------------------------
8.  WebSocket Connection Keep Alive

   [...]

   The client application MAY also use Network Address Translation (NAT)
   keep-alive mechanisms defined for the SIP protocol, such as the
   mechanism described in [RFC6223].
----------------------------------------------------------

It will be submitted in revision -01 of the draft.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 14 Sep 2011 22:11:46 +0530

Hi Jose/Inaki,

IIUC, this draft is not directly related to RTCWeb but RTCWeb developer may use it as an one of the option. ISTM, this draft has to be tracked in sipcore or dispatch for adding the new transport layer to SIP protocol.

Thanks

Partha

From: José Luis Millán [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2011 4:12 PM
To: Ravindran Parthasarathi
Cc: Iñaki Baz Castillo; [email-masked]
Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket

Hi,

Let's clarify that the submitted draft states a way to adopt WebSocket as a transport protocol for SIP.  This makes feasible the SIP communication between WebSocket capable nodes and nodes using other transports defined in SIP, which facilitates the inter-operation within nowadays implementations and implementations to be defined in this group.    

We are not proposing this specification as the unique/only signaling protocol within WebRTC. That's another subject out of the scope of the draft.

Regards.

Hi Inaki,

<snip>

Thanks
Partha

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 14 Sep 2011 19:37:52 +0200

> IIUC, this draft is not directly related to RTCWeb but RTCWeb developer may use it as an one of the option. ISTM, this draft has to be tracked in sipcore or dispatch for adding the new transport la…
I agree with you, it's out of scope for this group. Having said that, it's a very good example of how SIP can be implemented to work with rtcweb.

/O

---

From: Tim Panton <[email-masked]>
Date: Thu, 15 Sep 2011 10:48:33 +0100

It is worth pointing out that even with a signalling  protocol agnostic webRTC you 
wouldn't _have_ to implement your signalling protocol in javascript.

Browsers support other plugin languages - specifically it would be possible to implement
a classic full UDP SIP stack as a java applet and delegate the media handling to the webRTC layer.

Chrome is moving towards support for native plugins, but it isn't clear that they
would be suitable for this use.

Tim. (speaking for himself)

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 16 Sep 2011 05:08:25 +0530

Hi Tim,

I agree with you that it is possible to implement using plugins and it is highlighted in RTCWeb charter (http://tools.ietf.org/wg/rtcweb/charters) as "These are not interoperable, as they require non-standard extensions or plugins to  work.". And also, the aim of this WG is to "There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers". Now, I don't the reason for implementing signaling in JavaScript or plugin or applet.

Also, I don't know about native plugin but I guess that those plugin are installed as part of the browser installation. Please correct me if I'm wrong.

Thanks
Partha

>From: Tim Panton [mailto:[email-masked]]
>Sent: Thursday, September 15, 2011 3:19 PM
>rather than SIP protocol? Why should I code a complex server behaving as
>a gateway between Jingle and SIP protocols?
>>
>features. Our draft proposes the contrary: no protocol conversion (just
>SIP), and just transport protocol conversion (as already exists in SIP
>when bridging UDP/TCP/TLS-TCP/SCTP...).
>> </snip>
>>
>your solution is a workaround and we will end-up with your solution in
>case signaling protocol is not standardized as part of RTCWeb.
>>
>> Thanks
>> Partha
>>