Subject: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B)

From: "Nataraju A.B" <[email-masked]>
Date: Tue, 17 Apr 2012 22:16:24 +0530

Hi Authros,

Please find some comments on the draft
"draft-ibc-sipcore-sip-websocket-02.txt"

For simplicity, I have mentioned both the current text and proposed text.

The comments / corrective text can be found with prefix and suffix  --- **

-----------------------------------------------------
Section :  8.1.  Registration
CurrentText:
   Alice    (SIP WSS)    proxy.atlanta.com
   |                             |
   |REGISTER F1                  |
   |---------------------------->|
   |200 OK F2                    |
   |<----------------------------|
   |                             |

ReplacementText / Comment:

   Alice    (SIP WSS)    proxy.atlanta.com
   |                             |
   |                             |
   |WebSocket Con Req F1         |
   |---------------------------->|
   |WebSocket Con Reply F2       |
   |<----------------------------|
   |                             |
   |                             |
   |REGISTER F3                  |
   |---------------------------->|
   |200 OK F4                    |
   |<----------------------------|
   |                             |

   Prefixed the WebSocket connection request followed by SIP registrations.
   F1, F2 will be same messages mentioned in sec 4.1

-----------------------------------------------------
Section :  8.1.  Registration
CurrentText:
   F1 REGISTER  Alice -> proxy.atlanta.com (transport WSS)

   REGISTER sip:proxy.atlanta.com SIP/2.0
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf

   F2 200 OK  proxy.atlanta.com -> Alice (transport WSS)

   SIP/2.0 200 OK
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf

ReplacementText / Comment:

If I understand right,
          Websocket connection is mapped on to SIP URI  --> HTTP
   Secure Websocket connection is mapped on to SIPS URI --> HTTPS

HTTP --> WS --> SIP URI --> port 80

HTTPS --> WSS --> SIPS URI --> port 443

Hence in the following messages "WSS" shall be replaced with "WS"

   F1 REGISTER  Alice -> proxy.atlanta.com (transport WSS)

   REGISTER sip:proxy.atlanta.com SIP/2.0
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf

WSS --> WS

   F2 200 OK  proxy.atlanta.com -> Alice (transport WSS)

   SIP/2.0 200 OK
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf

WSS --> WS

Probably in the appendix A.2, we can list out the call flows for *""SECURE
WEB SOCKET"" (WSS)*

For example, REGISTER request looks like this (with WSS)...

   REGISTER sips:proxy.atlanta.com SIP/2.0
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf
   From: sips:[email-masked];tag=65bnmj.34asd
   To: sips:[email-masked]
   Call-ID: aiuy7k9njasd
   CSeq: 1 REGISTER
   Max-Forwards: 70
   Supported: path, outbound, gruu
   Contact: <sips:[email-masked];transport=ws>
     ;reg-id=1
     ;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>"

   changes:
   sip --> sips in RURI, From, TO, contact headers

-----------------------------------------------------
Section : 8.2.  INVITE dialog through a proxy
CurrentText:

   F1 INVITE  Alice -> proxy.atlanta.com (transport WSS)

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
   From: sip:[email-masked];tag=asdyka899
   To: sip:[email-masked]
   Call-ID: asidkj3ss
   CSeq: 1 INVITE
   Max-Forwards: 70
   Supported: path, outbound, gruu
   Route: <sip:proxy.atlanta.com:443;transport=ws;lr>
   Contact: <sip:[email-masked]
    ;gr=urn:uuid:f81-7dec-14a06cf1;ob>"
   Content-Type: application/sdp

ReplacementText / Comment:

   Extra closing double quote in contact header.

      Contact: <sip:[email-masked]
          ;gr=urn:uuid:f81-7dec-14a06cf1;ob>

   Route: <sip:proxy.atlanta.com:80;transport=ws;lr>

   change :
        443-->80              assuming HTTP <-- WS <-- SIP URI
        This comment is applicable for messages F1, F3, F4, F5, F6, F8, F9,
F10,

   Changes
WSS --> WS            assuming HTTP <-- WS <-- SIP URI
        This comment is applicable for messages F1, F2, F3, F4, F5, F6, F7,

-----------------------------------------------------
Section : 1.  Introduction

CurrentText:
Media transport is out of the scope of this document

ReplacementText / Comment:
   Any other draft / rfc which addresses this issue. it would improve the
   readability of the document if we can is suggest reference for
completeness.

-----------------------------------------------------

Section : 5.1.  General
CurrentText:
      (typically web-based applications with an strict and simple API
      for receiving WebSocket messages).  There is no need to establish

ReplacementText / Comment:
      (typically web-based applications with **a** strict and simple API
      for receiving WebSocket messages).  There is no need to establish

-----------------------------------------------------
Section :
CurrentText:
   In the absence of an explicit port and DNS SRV resource records, the
   default port for a SIP URI with "ws" transport parameter is 80 in
   case of SIP scheme and 443 in case of SIPS scheme.

ReplacementText / Comment:
   In the absence of an explicit port and DNS SRV resource records, the
   default port for a SIP URI with "ws" transport parameter is 80 in
   case of SIP scheme and 443 in case of SIPS scheme **, which is same as
   that used for http and https protocols respectively**

These ports have been used for the sake of backward compatibility with
servers
which does not support WS/WSS.

-----------------------------------------------------
Section :
CurrentText:

 _This section is non-normative._

ReplacementText / Comment:
 Some sections have been explicitly mentioned with this text. Does that mean
 other sections are normative text. Not clear though.

-----------------------------------------------------

Thanks,
Nataraju A.B.
[email-masked] / [email-masked]
+91-98455-95744

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 17 Apr 2012 19:25:17 +0200

> "draft-ibc-sipcore-sip-websocket-02.txt"

Hi Nataraju, thanks for your comments. We will address them. Some

Usage of a secure transport (like TLS-TCP or WSS) does not mandate
usage of SIPS schema. This is clearly explained in:

  http://tools.ietf.org/html/rfc5630#section-3.1.3

>    sip --> sips in RURI, From, TO, contact headers

As stated above this is not needed. WSS (or TLS-TCP) can be used
without using SIPS schema in SIP requests. That is a "best-effort TLS
/ WSS". Also using Outbound RFC 5626 helps here since the Outbound
proxy (or the server the UA is connected to via TLS / WSS) can reuse
the existing connection for incoming requests. This is also explained
in http://tools.ietf.org/html/rfc5630#section-3.1.3.

In summary: using a secure connection does not require using SIPS
schema in the requests sent over it.

Typo, thanks :)

>         This comment is applicable for messages F1, F3, F4, F5, F6, F8, F9,

Same comments as above :)

The example uses a secure WS connection (on top of TLS) but does not
use SIPS schema.

>         This comment is applicable for messages F1, F2, F3, F4, F5, F6, F7,

Idem.

We would not like to cover it. In case of web browsers, WebRTC
specification is defining RTP/SRTP/ICE/TURN for web applications. But
a SIP client using a WebSocket stack running in, i.e, a smartphone,
could use usual RTP for media transport.

We don't want to focus the draft on "web browsers" use case.

>       for receiving WebSocket messages).  There is no need to establish

Typo :)

> which does not support WS/WSS.

Basically yes. The style is the same as in RFC 6455
(http://tools.ietf.org/html/rfc6455) in which non normative sections
include the above line. Any suggestion to make it better is of course
welcome.

Thanks a lot for your review, we will address all the topics covered in it.

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

---

From: "Nataraju A.B" <[email-masked]>
Date: Wed, 18 Apr 2012 12:15:58 +0530

Hi Inaki,

Please find some more comments inline...

Please let me know, the reasoning behind single transport parameter and two
sent-protocol values.
sent-protocol : WS and WSS
transport = ws (only one new value)

This might be confusing in future...

To make the draft more readable, it may be a good idea to add transport
parameter for WSS as well.

transport         =  "UDP" / "TCP" / "TLS" / "SCTP" / "WS" */ "WSS"*
                     / other-transport

On Tue, Apr 17, 2012 at 10:55 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> <rfc5630> sec 3.1.3 <http://tools.ietf.org/html/rfc5630#section-3.1.3>.

   If one wants to use "best-effort TLS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS.

</rfc5630>

if we want to use SIP URI with any other secure communication mechanism
like WSS, might require
update to RFC5630. like
<rfc5630> sec 3.1.3 <http://tools.ietf.org/html/rfc5630#section-3.1.3>.

   If one wants to use "best-effort TLS/WSS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS ** or any other secure
transport mechanism like WSS**

</rfc5630>

for these changes, you can add a new section "5.4 Updates to RFC 5630"

Also add a normative reference for rfc5630 in sec "12.2. Informative
References"

   [RFC5630]  Audet, F., "The Use of the SIPS URI Scheme in the Session
              Initiation Protocol (SIP)", RFC 5630, October 2009.

> [ABN] similar typo mistake in message F3 as well.

> The example uses a secure WS connection (on top of TLS) but does not
[ABN] Probably for the sake of clarity, we can give call flow for Secure
Web Socket (WSS)
and non-secure Web Socket (WS). this content is already covered in
different sections (this doc and rfc6455 as well). But putting it together
with a call flow would make the concept more clearer.

for all the messages WS, port 80 shall be used and port 443 for WSS. This
is to make WS to be backward compatible with default HTTP and HTTPS ports.

> > which does not support WS/WSS.
???

-- 
Thanks,
Nataraju A.B.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 19:51:57 +0200

> This might be confusing in future...

Not really. In the same way that using SIP over TLS-TCP means
;transport=tcp with sips schema, or sending SIP over TLS-SCTP means
;transport=sctp with sips schema. So sending SIP over TLS-WebSocket
must involve ;transport=ws as sips schema.

Note that ;transport=tls has never been defined (nor in RFC 2543) and
it seems to appear in RFC 3261 due to dubious reasons, but it is not
used in RFC 3261.

Please check http://tools.ietf.org/html/rfc5630#section-3.1.4.

> if we want to use SIP URI with any other secure communication mechanism like
> WSS, might require
> update to RFC5630. like
> <rfc5630> sec 3.1.3.
>
>    a SIP URI, and send the request over TLS ** or any other secure transport
> mechanism like WSS**
>
> </rfc5630>

TLS is a extra-layer on top of TCP and also on top of WebSocket. When
applied on top of TCP transport it is commonly named "TLS", but it
should be better to call it "TLS-TCP" (in the same way that TLS over
SCTP is named "TLS-SCTP" for Via transport value in RFC 4168.

> [ABN] similar typo mistake in message F3 as well.

Good catch.

> [ABN] Probably for the sake of clarity, we can give call flow for Secure Web
> Socket (WSS)
> and non-secure Web Socket (WS). this content is already covered in different
> sections (this doc and rfc6455 as well). But putting it together with a call
> flow would make the concept more clearer.

The problem is that, trying to include a full secure call would lead
to multiple mail threads discussing SIPS stuf that is really difficult
to understand and implement. There is a RFC trying to improve/explain
it (RFC 5630). I don't think the mission of this draft is to clarify
SIPS usage.

Thanks a lot.

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

---

From: "Nataraju A.B" <[email-masked]>
Date: Thu, 19 Apr 2012 20:47:28 +0530

On Wed, Apr 18, 2012 at 11:21 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> like
> Web
> different

[ABN] Inaki, I understand your point. Anyway you would have analyzed
thoroughly to address the secure and non-secure websocket scenarios. The
same information can serve as a ready reference for people to use this
draft.

Not a problem, even if you drop this comment (rfc4168 don't do this....:)

-- 
Thanks,
Nataraju A.B.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 19 Apr 2012 18:31:36 +0200

> same information can serve as a ready reference for people to use this

In fact, examples in the draft use secure WebSocket connections, so
IMHO we "help" people implementing secure SIP. But SIPS schema is
another history nobody wants to deal with (that is my opinion after
many threads about it).

The most realistic scenario is that in which clients connect to their
proxy/server using a secure transport and the proxy decides whether to
use a secure or non-secure transport for communicating with other
servers, gateways or SIP networks, and examples in the draft show that
case.

If somebody wants to use SIPS with WebSocket transport, then just use
SIPS schema everywhere and WSS connections (and read RFC 5630) :)

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

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 28 Apr 2012 18:22:48 +0300

On 4/18/12 8:51 PM, Iñaki Baz Castillo wrote:
> TLS is a extra-layer on top of TCP and also on top of WebSocket.
TLS is not on top of WebSocket, but it is the other way around.
Once again:
WebSocket is not a transport protocol, but a protocol that is used to 
transport content as HTTP is.
WebSocket can run on top of TCP (WS) or on top of TLC (WSS).

So once again please do not say WebSocket is a transport protocol 
because it is not!

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

>   When

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 29 Apr 2012 19:07:24 +0200

2012/4/28 Salvatore Loreto <[email-masked]>:
> So once again please do not say WebSocket is a transport protocol because it
> is not!

Hi Salvatore,let me clarify this subject. The draft defines two things:

1) A WebSocket Sub-Protocol called "sip".

2) A new SIP transport called "WebSocket".

The SIP transport defined by this draft is WebSocket. WebSocket is,
indeed, a layer on top of a network transport (layer 3) but it's
designed to work as a *transport* layer since it defines a framing
mechanism to send application messages and control mesages in both
directions. Applications (i.e. JavaScript scripts, PHP/Java web apps)
use WebSocket as a transport layer.

There are other cases in which a transport runs on top of other
transports. For example, in the recent IETF #83 the RTCWEB WG approved
(or discussed) SCTP-over-DTLS-over-ICE-over-UDP as the transport for
the WebRTC Data-Channel mechanism. In some cases a "transport" does
not necessarily mean "layer 3 network transport".

So, regardless WebSocket is not a layer 3 transport, it's used as a
transport by this specification and therefore it's considered a "SIP
transport".

Regards.

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

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 29 Apr 2012 19:44:51 +0200

On 4/29/12 7:07 PM, Iñaki Baz Castillo wrote:
> 2012/4/28 Salvatore Loreto<[email-masked]>:
that is OK and I am not arguing against point 1.
> 2) A new SIP transport called "WebSocket".
I am not comfortable with this point, but maybe it is just me be a purist

> use WebSocket as a transport layer.
my point is that there is a difference between an application transport 
layer
and a transport protocol!

> not necessarily mean "layer 3 network transport".

this is slightly different
in RTCWeb the Data-Channel all the stack if formed by different 
transport protocols
however the fact the part of them run in the user-land space and then 
encapsulated in UDP
introduce some limitation to the SCTP futures etc.
but the UDP is still used in the full way on each side

there is a huge list of examples in literature of transport protocols 
designed and run on top
of UDP due to the flexibility of this transport protocol (e.g. pseud TCP 
protocols etc.)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 29 Apr 2012 20:08:17 +0200

> I am not comfortable with this point, but maybe it is just me be a purist

A "SIP transport" involves VIA transport values, SIP URI's transport
parameter value, DNS resolution (locating servers, NAPTR/SRV records,
default ports), secure or not secure transport, reliable transport or
not (so different timers in RFC 3261 are taken depending on that), and
so on.

That is what I mean with "SIP transport", and not just the layer
through which messages are transmitted/carried/transported.

Is it ok with this definition? :)

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