Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-01.txt

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 15 Jan 2012 20:43:56 +0100

A new version of I-D draft-ibc-sipcore-sip-websocket-01.txt has been
successfully submitted by Iñaki Baz Castillo and posted to the IETF
repository.

Filename:        draft-ibc-sipcore-sip-websocket
Revision:        01
Title:           The WebSocket Protocol as a Transport for the Session
Initiation Protocol (SIP)
Creation date:   2012-01-15
WG ID:           Individual Submission
Number of pages: 28

Abstract:
  This document specifies a WebSocket Sub-Protocol for a new transport
  in SIP (Session Initiation Protocol).  The WebSocket protocol enables
  two-way realtime communication between clients and servers.

The draft can be found at:

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

Changes in revision 01:

- draft-ietf-hybi-thewebsocketprotocol reference updated to RFC 6455
(The WebSocket Protocol).

- Suggested the usage of .invalid domain for clients not aware of
their local address (i.e. web browsers).

- A section describing the SIPS usage with WebSocket transport.

- Explained why this transport is mostly useful for client-server
rather than server-server.

As usual, your comments are most appreciated.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 15 Jan 2012 20:46:54 +0100

>  http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00

Sorry, the links pointed to the previous revision 00. Those are the new ones:

 http://www.ietf.org/id/draft-ibc-sipcore-sip-websocket-01.txt
 http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01

Regards.

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

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Mon, 16 Jan 2012 13:08:18 +0800

Hi Inaki

Some comments on -01 version

1. It would good if you can include a Change log to the draft document (like what changed from -00 version to -01 version - e.g. what are added, modified.). This will help in going through and reviewing the doc easier.
2. the websocket connection that gets established, needs some keep alive mechanism.  This can be achieved by sending SIP REGISTER message periodically to keep the websocket connection active.

Thanks

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: Monday, January 16, 2012 1:17 AM
To: SIPCORE WG
Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-01.txt

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 16 Jan 2012 08:21:36 +0100

> 2. the websocket connection that gets established, needs some keep alive mechanism.  This can be achieved by sending SIP REGISTER message periodically to keep the websocket connection active.

I don't thinkn it's a good idea. Copy the ping-pong from SIP outbound instead, it's a standardized keep-alive method for SIP.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 08:31:14 +0100

> I don't thinkn it's a good idea. Copy the ping-pong from SIP outbound instead, it's a standardized keep-alive method for SIP.

Right, and it's already documented in the draft in section 10:

http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00#section-10

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Jan 2012 08:42:28 +0100

Hi,

If you only want to refer to the keep-alive part, I would suggest to refer to RFC 6223 instead.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 08:56:23 +0100

> If you only want to refer to the keep-alive part, I would suggest to refer to RFC 6223 instead.

Hi Christer. Due to WebSocket protocol nature the SIP WS client MUST
implement full Outbound (RFC 5626):

http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00#section-6

So IMHO there is no need to just mention RFC 6223.

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 08:57:05 +0100

> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00#section-6

Sorry, the link to the current revision 01:

http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01#section-6

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Jan 2012 09:14:40 +0100

Hi, 

> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01#section-6

I am not sure I understand. What other parts of Outbound are you using?

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 09:25:39 +0100

> I am not sure I understand. What other parts of Outbound are you using?

Hi, I was to explain it here, but IMHO the section 6 of the draft describes it:

6.  Outbound and GRUU Usage

   WebSocket requires the client to open a TCP connection with the
   server and perform the WebSocket handshake.  A WebSocket client does
   not listen for incoming connections so it can only receive SIP
   requests from the WebSocket server it is connected to.  WebSocket
   clients may use either public or private addressing but it is
   expected that many of them will run the latter.  Unfortunately, some
   implementations may not have the ability to discover the local
   transport address which the WebSocket connection is originated from
   (e.g. a JavaScript stack within a web browser).  Those
   implementations are encouraged to create a domain consisting of a
   random token followed by .invalid top domain name, as stated in
   [RFC2606], and use it within the Via and Contact header.

   Therefore clients and servers implementing SIP over the WebSocket
   transport MUST implement the Outbound mechanism [RFC5626], being this
   the most suitable solution for SIP clients behind Network Address
   Translation (NAT) using reliable transports for contacting SIP
   servers.

Is there something not clear in this section? Basically the SIP WS
client MUST announce and require Outbound support to the proxy, MUST
use the ;reg-id and ;+sip.instance params in the Contact URI, MUST be
ready to receive incoming requests from the WS connection the client
has opened, and so on.

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

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Mon, 16 Jan 2012 16:27:55 +0800

In section 10, the following text is present:  "It is recommended that the WebSocket client or server keeps the WebSocket connection open by sending periodic WebSocket Ping frames as described in [I-D.ietf-hybi-thewebsocketprotocol] section 5.5.2.  The decision for a WebSocket endpoint to maintain, or not, the connection over time is out of scope of this document".

I feel it is mandatory to keep the websocket connection active until the duration of the session and hence should be within the scope of the document. 

Regards
Ranjit

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 09:32:24 +0100

> I feel it is mandatory to keep the websocket connection active until the duration of the session and hence should be within the scope of the document.

Ranjit, the connection keepalive is just needed in case of NAT since
those routers typically close the connection after some minutes of
inactivity. But a SIP WS client could have public IP and *still* it
requires Outbound RFC 5626 usage. In this case connection keepalive is
not a need (either WebSocket Ping frames or RFC 5626 techniques) so
that cannot be a "MUST" in the document.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 09:37:57 +0100

2012/1/16 Avasarala, Ranjit <[email-masked]>:
> Yes I agree it's not a must, but it would not be out of scope. right?

Whyis it out of the scope? It's clearly mentioned in the draft:

http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01#section-10

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Jan 2012 09:40:44 +0100

Hi, 

> Is there something not clear in this section? Basically the SIP WS client MUST announce and require 
> Outbound support to the proxy, MUST use the ;reg-id and ;+sip.instance params in the Contact URI, MUST
> be ready to receive incoming requests from the WS connection the client has opened, and so on.

What is unclear for what you need Outbound. You can use sip.instance without Outbound, and you can receive incoming requests on established connections without Outbound.

For reg-id would DO need Outbound. But, reg-id is used for the multiple registration flow feature of Outbound. Are you going to use that? If so, how?

Regards,

Christer

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 09:46:45 +0100

> What is unclear for what you need Outbound. You can use sip.instance without Outbound, and you can receive incoming requests on established connections without Outbound.

Hi Christer, I don't understand. ;sip.instance is defined in RFC 5626
(Outbound RFC), so if a client uses ;sip.instance it is using
Outbound.

> For reg-id would DO need Outbound. But, reg-id is used for the multiple registration flow feature of Outbound. Are you going to use that? If so, how?

Why not? a SIP WS client is not different from other SIP clients using
any other transport. They can use multiple registration using the
sip.instance and reg-id mechanism exposed in RFC 5626. They can also
use GRUU.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 16 Jan 2012 10:30:42 +0100

> (Outbound RFC), so if a client uses ;sip.instance it is using

No. A client might be using just GRUU, which uses the sip.instance parameter, but doesn't require the use of outbound.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 10:35:25 +0100

> No. A client might be using just GRUU, which uses the sip.instance parameter, but doesn't require the use of outbound.

Right, but when a client wants to reuse the connection to receive
incoming requests it MUST add a ;sip.instance Contact parameter in the
request.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 16 Jan 2012 10:39:17 +0100

> incoming requests it MUST add a ;sip.instance Contact parameter in the

Correct, I was just pointing out that sip.instance can be used without outbound :-)

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Jan 2012 11:09:29 +0100

Hi, 

>>> use the ;reg-id and ;+sip.instance params in the Contact URI, MUST be ready to receive incoming requests from the WS connection the client has opened, and so on.
>>
> Hi Christer, I don't understand. ;sip.instance is defined in RFC 5626 (Outbound RFC), so if a client uses ;sip.instance it is using Outbound.
>
> Why not? a SIP WS client is not different from other SIP clients using any other transport. They can use multiple registration using 
> the sip.instance and reg-id mechanism exposed in RFC 5626. They can also use GRUU.

If you are going to do multiple registrations with websockets, I think you in more detail need to describe how it maps into the websocket scenario. For example, assuming a web server is acting as an Outbound edge proxy, would you establish multiple websocket connections, with multiple web servers? Etc...

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 11:13:06 +0100

> If you are going to do multiple registrations with websockets, I think you in more detail need to describe how it maps into the websocket scenario. For example, assuming a web server is acting as a…

Right. By I would prefer to avoid the term "web server". It would be,
in fact, a SIP proxy/server implementing the WebSocket transport.

However I'm not sure why this should be documented in the draft. For
example in the RFC about SIP over SCTP there is no mention at all to
Outbound, why should draft-ibc-sipcore-sip-websocket repeat all the
stuff in RFC 5626? WebSocket is just a new SIP transport, and a SIP
proxy implementing WebSocket transport is still a SIP proxy. IMHO
there is no need of repeating all the SIP features in this draft. Am I
wrong?

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Jan 2012 11:36:50 +0100

Hi, 

>> If you are going to do multiple registrations with websockets, I think you in more detail need 
>> to describe how it maps into the websocket scenario. For example, assuming a web server is 
>> acting as an Outbound edge proxy, would you establish multiple websocket connections, with multiple web servers? Etc...
>
> Right. By I would prefer to avoid the term "web server". It would be, in fact, a SIP proxy/server implementing the WebSocket transport.
>
> However I'm not sure why this should be documented in the draft. For example in the RFC about SIP over SCTP there is no 
> mention at all to Outbound, why should draft-ibc-sipcore-sip-websocket repeat all the stuff in RFC 5626? WebSocket is 
> just a new SIP transport, and a SIP proxy implementing WebSocket transport is still a SIP proxy.

If WS is "just a new SIP transport", I don't think you should mandate Outbound, keep-alives etc - because the RFCs about SIP and SCTP don't do it either :)

I think you are, at least partly, also making assumptions about the environment where it will be used, assuming there will be NATs etc.

> IMHO there is no need of repeating all the SIP features in this draft. Am I wrong?

For example, IF the edge proxy is the web server (I think that will be the normal case), from where you've downloaded a JS SIP client app, you could establish a WS connection with that wenb server.

But, I don't think you by default can establish WS connections with OTHER web servers, due to same origin policies etc. 

So, I think it would be good to have some text about that, and possible limitations.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 11:39:15 +0100

> So, I think it would be good to have some text about that, and possible limitations.

Ok, I'll consider addind such a section in nex revision. However,
WebSocket does not mandate that the WebSocket connection needs to be
done against the same web server from which the JavaScript code is
retrieved. There is origin policy and so on, but it's up to the server
whether accept or reject a WS connection.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 12:14:38 +0100

> whether accept or reject a WS connection.

What about the following text within the Outbound and Gruu section in
the draft?:

   The SIP client MAY connect to varios outbound proxies using different
   WebSocket connections and register against them for redundancy
   purposes as stated in [RFC2606] section 3.  In this case, the SIP
   client should be provided with multiple WebSocket URIs and optionally
   with different registrar URIs.

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

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 Jan 2012 08:51:15 -0800

Wow, I'm having a flashback... Seriously, it seems we are rehashing the same
arguments from 3 years ago...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Monday, January 16, 2012 12:15 AM
To: 'Iñaki Baz Castillo'
Cc: SIPCORE (Session Initiation Protocol Core) WG ([email-masked]); Olle
E. Johansson; Avasarala, Ranjit
Subject: Re: [sipcore] New Version Notification for
draft-ibc-sipcore-sip-websocket-01.txt

Hi, 

>> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00#section
>> -
>> 6
>

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 18:10:06 +0100

> arguments from 3 years ago...

Hi Francois, is there any error in the draft about Outbound usage? I
know the spec very well (I've implemented it in both client and proxy
side) and AFAIK the Outbound stuff in our draft is correct.

Thanks a lot for any comment about it.

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Jan 2012 19:04:56 +0100

>   with different registrar URIs.

Sorry, obviously it must be RFC 5626 rather than 2606.

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