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

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 16 Apr 2012 18:49:38 +0200

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

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

Abstract:
  The WebSocket protocol enables two-way realtime communication between
  clients and servers.  This document specifies a new WebSocket sub-
  protocol as a reliable transport mechanism between SIP (Session
  Initiation Protocol) entities and enables usage of the SIP protocol
  in new scenarios.

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

This new version incorporates improvements and changes based on the
comments and reviews on the previous version, along with the consensus
got in IETF 83 Paris.

As usual, comments are welcome. Thanks a lot.

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

---

From: Adam Roach - SIPCORE Chair <[email-masked]>
Date: Mon, 16 Apr 2012 13:02:46 -0500

[as chair]

SIPCORE Working Group:

This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 
document to satisfy our recently added milestone to define a WebSockets 
transport for the SIP protocol. Interested parties should voice their 
support and/or concerns on the SIPCORE mailing list. The chairs plan to 
make a determination of consensus on Friday, April 27th.

Thank you. The draft announcement follows.

/a

-------- Original Message --------
Subject: [sipcore] New Version Notification for 
draft-ibc-sipcore-sip-websocket-02.txt
Date: Mon, 16 Apr 2012 18:49:38 +0200
From: Iñaki Baz Castillo <[email-masked]>
To: SIPCORE WG <[email-masked]>

Abstract:

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Apr 2012 13:09:55 -0500

> make a determination of consensus on Friday, April 27th.

I support adoption of draft-ibc-sip-websocket-02 to satisfy the newly
added milestone.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 16 Apr 2012 14:14:11 -0400

+1 on draft-ibc-sip-websocket-02 being adopted as WG item to address WebSockets milestone

--G

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 16 Apr 2012 20:15:43 +0200

+1

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Apr 2012 20:34:49 +0200

I support adoption of the draft.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach - SIPCORE Chair
Sent: 16. huhtikuuta 2012 21:03
To: SIPCORE (Session Initiation Protocol Core) WG
Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02

[as chair]

SIPCORE Working Group:

This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02
document to satisfy our recently added milestone to define a WebSockets transport for the SIP protocol. Interested parties should voice their support and/or concerns on the SIPCORE mailing list. The chairs plan to make a determination of consensus on Friday, April 27th.

/a

-------- Original Message --------
Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-02.txt
Date: Mon, 16 Apr 2012 18:49:38 +0200
From: Iñaki Baz Castillo <[email-masked]>
To: SIPCORE WG <[email-masked]>

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

Abstract:

This new version incorporates improvements and changes based on the comments and reviews on the previous version, along with the consensus got in IETF 83 Paris.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 16 Apr 2012 13:46:33 -0500

> I support adoption of the draft.

I also support adoption of the draft.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 16 Apr 2012 21:28:08 +0200

I do support the adoption of this draft.

Regards,

On Apr 16, 2012, at 8:02 PM, Adam Roach - SIPCORE Chair wrote:

> [as chair]
> 
> SIPCORE Working Group:
> 
> This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 document to satisfy our recently added milestone to define a WebSockets transport for the SIP protocol. Interested parties should voice their support and/or concerns on the SIPCORE mailing list. The chairs plan to make a determination of consensus on Friday, April 27th.
> 

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 17 Apr 2012 09:47:31 +0200

> This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 document to satisfy our recently added milestone to define a WebSockets transport for the SIP protocol. Interested parties shou…
I support adoption of this document.

/O
> As usual, comments are welcome. Thanks a lot.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 05:01:23 +0000

As per my current reading, The current draft assumes about dialog-stateful proxy wherein all record-route header will be added whenever Websocket to other transport routing happens in the proxy and proxy will be involved in all the transaction within the dialog. So, it is not possible to have stateless or transaction stateful proxy. It will be good in case this limitation is explicitly mentioned in the draft.

Thanks
Partha 

>Sent: Monday, April 16, 2012 11:33 PM

---

From: "Nataraju A.B" <[email-masked]>
Date: Wed, 18 Apr 2012 11:48:29 +0530

Partha,

I also feel the same. The scenario is very similar to proxy interfacing
between UDP and TCP on different sides, where dialog stateful proxy
functionality is required. stateless / transaction stateful proxies would
not work properly when requests are sent over different protocols.

Thanks,
Nataraju A B

On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthasarathi <
[email-masked]> wrote:

> As per my current reading, The current draft assumes about dialog-stateful
> proxy wherein all record-route header will be added whenever Websocket to
> other transport routing happens in the proxy and proxy will be involved in
> all the transaction within the dialog. So, it is not possible to have
> stateless or transaction stateful proxy. It will be good in case this
> limitation is explicitly mentioned in the draft.
>
> Thanks
> Partha
>

-- 
Thanks,
Nataraju A.B.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 07:02:01 +0000

Nataraju,

As per Sec 18 of RFC 3261 in , "All SIP elements MUST implement UDP and TCP.", so it is possible to have stateless or transaction stateful proxy routing with change in transport mechanism from UDP to TCP and vice versa. The simple scenario like INVITE transaction over TCP whereas Re-INVITE over UDP based on contact SIP URI with UDP as a transport should work as per RFC 3261.

In case of draft-ibc-sipcore-sip-websocket-02 draft, SIP UA over websocket (like browser) will not implement either UDP or TCP transport which is a deviation from RFC 3261. This deviation leads to this limitation of not having stateless or Transaction stateful proxy in websocket transport.

Thanks
Partha

From: Nataraju A.B [mailto:[email-masked]]
Sent: Wednesday, April 18, 2012 11:48 AM
To: Ravindran, Parthasarathi
Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

Partha,

I also feel the same. The scenario is very similar to proxy interfacing between UDP and TCP on different sides, where dialog stateful proxy functionality is required. stateless / transaction stateful proxies would not work properly when requests are sent over different protocols.

Thanks,
Nataraju A B
On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> wrote:
As per my current reading, The current draft assumes about dialog-stateful proxy wherein all record-route header will be added whenever Websocket to other transport routing happens in the proxy and proxy will be involved in all the transaction within the dialog. So, it is not possible to have stateless or transaction stateful proxy. It will be good in case this limitation is explicitly mentioned in the draft.

Thanks
Partha

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>Behalf Of Adam Roach - SIPCORE Chair
>From: Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>>
>To: SIPCORE WG <[email-masked]<mailto:[email-masked]>>
>
><[email-masked]<mailto:[email-masked]>>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

--
Thanks,
Nataraju A.B.

---

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

Partha,

I was referring to scenario,

UAC                  Proxy                   UAS
 -----sips/tcp---->     ------>sip/udp --->

UAC requested for a secure connection. But assume proxy at the edge and
can't guarantee secure connection towards UAS. hence It is sending a
request to UAS over simple udp *without security*.

In this case, proxy must behave like a dialog stateful proxy. stateless or
transaction stateful proxy can't inter work in this scenario.

This is my understanding. Others please share your opinion on the same....

Thanks,
Nataraju A B

On Wed, Apr 18, 2012 at 12:32 PM, Ravindran, Parthasarathi <
[email-masked]> wrote:

>  Nataraju,**
>
> ** **
>
> As per Sec 18 of RFC 3261 in , “All SIP elements MUST implement UDP and
> TCP.”, so it is possible to have stateless or transaction stateful proxy
> routing with change in transport mechanism from UDP to TCP and vice versa.
> The simple scenario like INVITE transaction over TCP whereas Re-INVITE over
> UDP based on contact SIP URI with UDP as a transport should work as per RFC
> 3261.  ****
>
> ** **
>
> In case of draft-ibc-sipcore-sip-websocket-02 draft, SIP UA over websocket
> (like browser) will not implement either UDP or TCP transport which is a
> deviation from RFC 3261. This deviation leads to this limitation of not
> having stateless or Transaction stateful proxy in websocket transport.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *From:* Nataraju A.B [mailto:[email-masked]]
> *Sent:* Wednesday, April 18, 2012 11:48 AM
> *To:* Ravindran, Parthasarathi
> *Cc:* SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG
> *Subject:* Re: [sipcore] Stateless or Transaction stateful proxy possible
> in Websocket transport? [RE: Call for Adoption:
> draft-ibc-sipcore-sip-websocket-02]****
>
> ** **
>
> Partha, ****
>
> ** **
>
> not work properly when requests are sent over different protocols.****
>
> ** **
>
> Thanks,****
>
> Nataraju A B****
>
> [email-masked]> wrote:****
>
> https://www.ietf.org/mailman/listinfo/sipcore****
>
>
>
> ****
>
> ** **
>
> --
> Thanks,****
>
> Nataraju A.B.****
>
> ** **
>

-- 
Thanks,
Nataraju A.B.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 10:16:50 +0200

2012/4/18 Ravindran, Parthasarathi <[email-masked]>:
> As per my current reading, The current draft assumes about dialog-stateful proxy wherein all record-route header will be added whenever Websocket to other transport routing happens in the proxy and proxy will be involved in all the transaction within the dialog.

Hi, the draft does not assume that. Perhaps you talk about the example
scenario in the non-normative Appendix A?.

Anyhow what you mean "dialog-stateful proxy" is incorrect (see below please).

> So, it is not possible to have stateless or transaction stateful proxy. It will be good in case this limitation is explicitly mentioned in the draft.

AFAIR a proxy can be *transaction stateless* regardless it bridges
different SIP transports. A stateless proxy is supposed to route
responses based on Via header. In case of reliable transports, the
first choice must be using the existing connection. If the *stateless*
proxy adds ;received and ;rport to the Via in the incoming request,
then it could later route responses to the UAC by inspecting those
parameters in the responses and getting the associated connection. The
proxy could also mantain a relationship between branch values and
associated connections, but then it would be not so "stateless".

Also, please don't mix "loose-routing" and "dialog-stateful". A pure
SIP proxy performing loose-routing (in-dialog requests go through the
proxy) can be a transaction stateful proxy but know nothing about
"dialogs".

Regards.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 08:23:23 +0000

Hi Nataraju,

As per Sec 20.42 of RFC 3261  SIPS URI indicates that the transport is TLS (and not TCP)
and the snippet is "When a request is sent to a SIPS URI, the protocol still indicates "SIP",
and the transport protocol is TLS."

As per Sec 26.2.1 Para 7 of RFC 3261, TLS transport is hop-by-hop and not end-to-end and RFC
Snippet is as follows:

"Note that
transport mechanisms are specified on a hop-by-hop basis in SIP, thus
a UA that sends requests over TLS to a proxy server has no assurance
that TLS will be used end-to-end."

Please note that SIP UA with TLS transport is not going to violate Sec 18 of RFC 3261 "All SIP
elements MUST implement UDP and TCP.".  In the below mentioned callflow, proxy shall
acts as stateless or transaction stateful proxy wherein UAC shall sent INVITE with SIPS URI
towards proxy, proxy forwards INVITE in UDP/TCP towards UAS and receive contact with UDP/TCP
as a transport in 2xx response from UAS, 2xx is forwarded towards UAC. Here, UAC is expected to
send RE-INVITE/BYE towards UAS with transport as UDP/TCP. So, it is possible to interwork with
TLS to UDP/TCP as per RFC 3261.

In case you mention the same above logic of TLS applies to Websocket, anybody implement SIP
over websocket in browser using JavaScript violates RFC 3261 as it is not possible for browser to
send REINVITE/BYE using UDP/TCP transport towards UAS directly with stateless/Transaction
stateful proxy as a first proxy hop.

Thanks
Partha

Sent: Wednesday, April 18, 2012 12:59 PM

Partha,

UAC                  Proxy                   UAS

UAC requested for a secure connection. But assume proxy at the edge and can't guarantee secure connection towards UAS. hence It is sending a request to UAS over simple udp without security.

In this case, proxy must behave like a dialog stateful proxy. stateless or transaction stateful proxy can't inter work in this scenario.

Thanks,
Nataraju A B

On Wed, Apr 18, 2012 at 12:32 PM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> wrote:
Nataraju,

Thanks
Partha

From: Nataraju A.B [mailto:[email-masked]<mailto:[email-masked]>]

Partha,

Thanks,
Nataraju A B

Thanks
Partha

--
Thanks,
Nataraju A.B.

--
Thanks,
Nataraju A.B.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 08:35:12 +0000

Inaki,

Please provide SIP over Webexample example without record-route and 2xx response from UAS with UDP/TCP transport in contact header, then it will be obvious why it is not possible to be transaction stateful proxy for Websocket to UDP/TCP transport conversion. I have clarified those scenario in the another mail thread to Nataraju. 

Thanks
Partha 

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Wednesday, April 18, 2012 1:47 PM
>Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible
>in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-
>websocket-02]
>
>> As per my current reading, The current draft assumes about dialog-
>stateful proxy wherein all record-route header will be added whenever
>Websocket to other transport routing happens in the proxy and proxy will
>be involved in all the transaction within the dialog.
>
>> So, it is not possible to have stateless or transaction stateful
>proxy. It will be good in case this limitation is explicitly mentioned
>in the draft.
>
>responses based on Via header. In case of reliable transports, the first
>choice must be using the existing connection. If the *stateless* proxy
>adds ;received and ;rport to the Via in the incoming request, then it
>could later route responses to the UAC by inspecting those parameters in
>the responses and getting the associated connection. The proxy could
>also mantain a relationship between branch values and associated
>connections, but then it would be not so "stateless".
>
>
>Also, please don't mix "loose-routing" and "dialog-stateful". A pure SIP
>proxy performing loose-routing (in-dialog requests go through the

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 08:44:06 +0000

One minor correction, I agree that dialog-stateful proxy is not mandatory but transaction stateful proxy with record-route header is mandatory for websocket transport and stateless proxy is not possible. This has to be mentioned in the draft.

>From: Ravindran, Parthasarathi
>Sent: Wednesday, April 18, 2012 2:06 PM
>To: 'Iñaki Baz Castillo'
>Subject: RE: [sipcore] Stateless or Transaction stateful proxy possible
>Please provide SIP over Webexample example without record-route and 2xx
>response from UAS with UDP/TCP transport in contact header, then it will
>be obvious why it is not possible to be transaction stateful proxy for
>Websocket to UDP/TCP transport conversion. I have clarified those
>scenario in the another mail thread to Nataraju.
>
>Thanks
>Partha
>
>>Websocket to other transport routing happens in the proxy and proxy
>>will be involved in all the transaction within the dialog.
>>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 10:44:50 +0200

2012/4/18 Ravindran, Parthasarathi <[email-masked]>:
> anybody implement SIP over websocket in browser using JavaScript violates RFC 3261 as it is not
> possible for browser to send REINVITE/BYE using UDP/TCP transport towards UAS directly with
> stateless/Transaction stateful proxy as a first proxy hop.

Then SIP UAs in Outbound (RFC 5626) scenarios also violate RFC 3261
since TCP UAs behind NAT cannot receive requests and responses via
UDP, neither they can receive inbound TCP connections.

But what is the exact problem? the draft is not for "web browsers",
but for any SIP entity running a WebSocket client and/or server (along
with other SIP transports).

Does a SIP stack in JavaScrtip running in a web browser and making
usage of WS transport violate RFC 3261 since it does not support
UDP/TCP transports? probably. Is that a real problem? not at all if
the SIP infrastucture applies other SIP standards (such as RFC 5626)
or "propietary mechanisms" for ensuring that the web browser sends and
receives all the SIP requests and responses through its opened
WebSocket connection.

Best regards.

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

---

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

2012/4/18 Ravindran, Parthasarathi <[email-masked]>:
> Inaki,
>
> Please provide SIP over Webexample example without record-route and 2xx response from UAS with UDP/TCP transport in contact header, then it will be obvious why it is not possible to be transaction stateful proxy for Websocket to UDP/TCP transport conversion.

Ravindran, please read my previous mail in which I explain that your
concept of "transaction stateful proxy" is incorrect.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 08:57:00 +0000

In case the intention of the draft is to violate RFC 3261, 
IMO, we will need more analysis before adopting this draft.

AFAIK, RFC 5626 considers UDP transport as well and Sec 1 Para 3 explains as 

"   The key idea of this specification is that when a UA sends a REGISTER
   request or a dialog-forming request, the proxy can later use this
   same network "flow" -- whether this is a bidirectional stream of UDP
   datagrams, a TCP connection, or an analogous concept in another
   transport protocol -- to forward any incoming requests that need to
   go to this UA in the context of the registration or dialog."

Please indicates where RFC 5626 violates RFC 3261.

Thanks
Partha

>Sent: Wednesday, April 18, 2012 2:15 PM
>Cc: Nataraju A.B; SIPCORE (Session Initiation Protocol Core) WG; SIPCORE
>Chairs
>> anybody implement SIP over websocket in browser using JavaScript
>> violates RFC 3261 as it is not possible for browser to send
>> REINVITE/BYE using UDP/TCP transport towards UAS directly with
>since TCP UAs behind NAT cannot receive requests and responses via UDP,
>neither they can receive inbound TCP connections.
>
>But what is the exact problem? the draft is not for "web browsers", but
>for any SIP entity running a WebSocket client and/or server (along with
>other SIP transports).
>
>Does a SIP stack in JavaScrtip running in a web browser and making usage
>of WS transport violate RFC 3261 since it does not support UDP/TCP
>transports? probably. Is that a real problem? not at all if the SIP
>infrastucture applies other SIP standards (such as RFC 5626) or
>"propietary mechanisms" for ensuring that the web browser sends and
>receives all the SIP requests and responses through its opened WebSocket
>connection.
>
>
>Best regards.
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 10:59:00 +0200

2012/4/18 Ravindran, Parthasarathi <[email-masked]>:
> One minor correction, I agree that dialog-stateful proxy is not mandatory but transaction stateful proxy with record-route header is mandatory for websocket transport

That is just true in case the UA just implements a WebSocket client
(so it's a SIP WebSocket Client according to "Definitions" section in
the draft, but not a SIP WebSocket Server). This is true in the case
of a web browser but the draft does NOT assume that clients are web
browsers.

> and stateless proxy is not possible.

In a previous mail I've explained that a staless proxy can bridge
different SIP transports. Please find a reference for your assertion
(I could be wrong).

> This has to be mentioned in the draft.

Please check RFC 4168 (SIP SCTP transport), and let's imagine this scenario:

  alice ----(SCTP)----- proxy -----(UDP)---- bob

If bob does not implement SCTP transport (and alice announces a URI
with ;transport=stcp in her Contact), then the proxy needs to add
Record-Route (loose-routing) thinkgs to work, am I right?

Well, please look in RFC 4168 for keywords "proxy", "loose-routing",
"record-route", "stateless", "stateful" and so. No matches. So, why
should this draft solve all the problems of the world related to SIPS
or transport bridging? That is not the purpose of this draft which
just defines a new SIP transport. The issues you mean are not specific
for this new transport, but for any other transport which is not UDP
or TCP. There should be other drafts or places for solving or defining
procedures for them.

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 11:08:14 +0200

> IMO, we will need more analysis before adopting this draft.

Thanks a lot Partha.

Please let us know where the draft violates RFC 3261. If you assume
that a SIP UA implementing the WebSocket transport is a web browser
(so can only make outbound connections and does not speak SIP UDP/TCP)
then that is your assumption, but NOT the assumption of the draft.

Now imagine that I code a SIP softphone for my smartphone, and such a
softphone speaks SIP over UDP, TCP and WebSocket, and implements both
a WebSocket client and a WebSocket server (so becomes a SIP WebSocket
Client and a SIP WebSocket Server according to "Definitions" section
in the draft). Does it violate RFC 3261?

Best regards.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 18 Apr 2012 11:14:50 +0200

Hi,

> IMO, we will need more analysis before adopting this draft.

SIP clients implementing this draft may also implement UDP and TCP transports, this draft doesn't say they shouldn't.

Now lets assume we are using a JS SIP stack in a browser: UDP and TCP can't be used, so why implement them in the first place? Also, the client will register with WS transport and *use* transport=ws in the Contat header so trying to reach him on TCP or UDP would be incorrect.

Also, TCP and UDP are mandatory to implement as per RFC3261, not mandatory to use.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 09:35:41 +0000

As per your below statement, JavaScript with SIP and RTCWeb Browser MUST NOT use this draft as it violates RFC 3261.

Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket will not listen for the incoming call without registration but in case of your draft is written with SIP softphone (smartphone) in mind , it is possible to listen in Port 80 or any other Websocket port which is not addressed in this draft till now. We need to discuss and sort it out.

Thanks
Partha

>Sent: Wednesday, April 18, 2012 2:38 PM
>> In case the intention of the draft is to violate RFC 3261, IMO, we
>> will need more analysis before adopting this draft.
>
>Thanks a lot Partha.
>
>Please let us know where the draft violates RFC 3261. If you assume that
>a SIP UA implementing the WebSocket transport is a web browser (so can
>only make outbound connections and does not speak SIP UDP/TCP) then that
>is your assumption, but NOT the assumption of the draft.
>
>softphone speaks SIP over UDP, TCP and WebSocket, and implements both a
>WebSocket client and a WebSocket server (so becomes a SIP WebSocket
>Client and a SIP WebSocket Server according to "Definitions" section in
>the draft). Does it violate RFC 3261?
>
>Best regards.
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 18 Apr 2012 11:53:13 +0200

> As per your below statement, JavaScript with SIP and RTCWeb Browser MUST NOT use this draft as it violates RFC 3261.

It doesn't, see my previous email explaining why.

> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket will not listen for the incoming call without registration but in case of your draft is written with SIP softphone (smartphone)…

The fact that a JS SIP client (running in a web browser) does not listen for incoming connections is a limitation imposed by the WebSocket API, not by this draft. This specification defines 2 entities: a SIP WebSocket Client and a SIP WebSocket Server, so nobody stops you from creating an entity that implements both and can accept incoming WebSocket connections. Of course, such an application would not run in a browser.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 10:07:50 +0000

Even if it is the limitations of websocket, SIP UA MUST listen in
UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST
be considered as a violation of RFC 3261. In case you think that this draft
does not violate any RFC 3261 for SIP UA, the Current text in the draft is not
clear enough, Please mention it explicitly in the draft that

"As per this specification, SIP UA MUST support UDP, TCP transport apart 
from Websocket as a transport"

This information helps for the implementers who wish to use this draft for 
RTCWeb client to SIP Interop in the standard way. I'm writing this mail as 
most of the folks support this draft for interworking RTCWeb client to SIP 
in the standard manner as per my discussion in IETF-83. 

I'll write the separate mail thread for discussing incoming SIP over websocket
as it is one another major open item in this draft.

Thanks
Partha

>From: Saúl Ibarra Corretgé [mailto:[email-masked]]
>Sent: Wednesday, April 18, 2012 3:23 PM
>Cc: Iñaki Baz Castillo; SIPCORE (Session Initiation Protocol Core) WG;
>SIPCORE Chairs; Nataraju A.B
>> As per your below statement, JavaScript with SIP and RTCWeb Browser
>MUST NOT use this draft as it violates RFC 3261.
>>
>
>> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket
>will not listen for the incoming call without registration but in case
>of your draft is written with SIP softphone (smartphone) in mind , it is
>possible to listen in Port 80 or any other Websocket port which is not
>addressed in this draft till now. We need to discuss and sort it out.
>>
>
>The fact that a JS SIP client (running in a web browser) does not listen
>for incoming connections is a limitation imposed by the WebSocket API,
>not by this draft. This specification defines 2 entities: a SIP
>WebSocket Client and a SIP WebSocket Server, so nobody stops you from
>creating an entity that implements both and can accept incoming
>WebSocket connections. Of course, such an application would not run in a
>browser.
>
>
>Regards,
>
>--
>Saúl Ibarra Corretgé
>AG Projects
>
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 18 Apr 2012 12:14:14 +0200

> clear enough, Please mention it explicitly in the draft that

"MUST implement" doesn't imply "MUST use" AFAIK.

> from Websocket as a transport"

It's not needed, 3261 sec 18 covers this: " All SIP elements MUST implement UDP and TCP.  SIP elements MAY implement other protocols."

> as it is one another major open item in this draft.

I don't think it's a "major open item", the draft specifies it, but t can't be used in a RTCWeb context because browsers don't listen for incoming WebSocket connections. Other endpoints implementing this draft will be able to listen for incoming connections just fine.

--
Saúl Ibarra Corretgé
AG Projects

---

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

> as it is one another major open item in this draft.
[ABN] Partha,
          Can you name some scenario which need this incoming SIP requests
@ the WebSocket client ????

-- 
Thanks,
Nataraju A.B.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 10:26:58 +0000

Saul,

I guess that you wish to see the requirement like

"As per this specification, SIP UA MUST implement UDP, TCP transport
apart from Websocket as a transport"

Please note that my intention of the this mail thread is not to
create this requirement but to clarify the implementers about proxy usage.

Thanks
Partha 

>Sent: Wednesday, April 18, 2012 3:44 PM
>Cc: SIPCORE (Session Initiation Protocol Core) WG; SIPCORE Chairs; Iñaki
>Baz Castillo; Nataraju A.B
>> Even if it is the limitations of websocket, SIP UA MUST listen in UDP
>> & TCP as per RFC 3261 and not adhere to this requirement which MUST be
>> considered as a violation of RFC 3261. In case you think that this
>> draft does not violate any RFC 3261 for SIP UA, the Current text in
>> the draft is not clear enough, Please mention it explicitly in the
>> draft that
>>
>
>> "As per this specification, SIP UA MUST support UDP, TCP transport
>> apart from Websocket as a transport"
>>
>
>It's not needed, 3261 sec 18 covers this: " All SIP elements MUST
>implement UDP and TCP.  SIP elements MAY implement other protocols."
>
>> This information helps for the implementers who wish to use this draft
>> for RTCWeb client to SIP Interop in the standard way. I'm writing this
>> mail as most of the folks support this draft for interworking RTCWeb
>> client to SIP in the standard manner as per my discussion in IETF-83.
>>
>> I'll write the separate mail thread for discussing incoming SIP over
>> websocket as it is one another major open item in this draft.
>>
>
>I don't think it's a "major open item", the draft specifies it, but t
>can't be used in a RTCWeb context because browsers don't listen for
>incoming WebSocket connections. Other endpoints implementing this draft
>will be able to listen for incoming connections just fine.
>
>--
>Saúl Ibarra Corretgé
>AG Projects
>
>

---

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

On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, Parthasarathi <
[email-masked]> wrote:

> [ABN] It may be overkill to ask Websocket client to support for TCP and
UDP and listen for incoming connections, just to be inline / compatible
with SIP.

          is it worth doing so ???

> websocket

-- 
Thanks,
Nataraju A.B.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 18 Apr 2012 12:35:27 +0200

Partha,

> create this requirement but to clarify the implementers about proxy usage.

No, I don't wish to see any of that. Have a look at RFC4168, it defines SCTP and it doesn't say any of that, it's perfectly clear that that specification (and this one) define *new* transports for the SIP protocol. I don't see a need to remind people of what RFC3261 says.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 13:37:16 +0200

> apart from Websocket as a transport"

Please check RFC 4168 (SIP SCTP transport) and find a similar statement.

> create this requirement but to clarify the implementers about proxy usage.

Thanks for clarifying it. If not, someone might think that what you
claim is that a web browser can not be SIP compliant since it does not
speak SIP UDP/TCP.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Apr 2012 15:40:14 +0200

Hi,

I may have misunderstood something in the conversation, but my suggestion would be to consider *NOT* mandating SIP WebSocket clients to implement SIP UDP and TCP.

Especially if I write a JavaScript SIP browser app, I very likely would want to support only WebSocket.

Also, I don't think we can directly compare with SCTP, since the typical use-case for WebSocket is browser apps (eventhough a native app can of course also use WS).

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: 18. huhtikuuta 2012 14:37
To: Ravindran, Parthasarathi
Cc: SIPCORE (Session Initiation Protocol Core) WG; Saúl Ibarra Corretgé
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

> Please note that my intention of the this mail thread is not to create 
> this requirement but to clarify the implementers about proxy usage.

Thanks for clarifying it. If not, someone might think that what you claim is that a web browser can not be SIP compliant since it does not speak SIP UDP/TCP.

Regards.

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 18 Apr 2012 17:11:14 +0300

> Also, I don't think we can directly compare with SCTP, since the typical use-case for WebSocket is browser apps (eventhough a native app can of course also use WS).

I think that in general we can not compare SCTP to WebSocket at all
because the first is a pure Transport Protocol, the latter is an 
application protocol that is used as transport.

 From a pure WebSocket prospective, what you are going to define is SIP 
as a websocket sub-protocol that is transported on top of.

The important thing to standardize from a SIPCore prospective is the 
interaction/translations that happens between the WebSocket server and 
the SIP proxy
that are two different logical entities.

my two cents
Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 18 Apr 2012 16:24:06 +0200

Hi,

On Apr 18, 2012, at 4:11 PM, Salvatore Loreto wrote:

> because the first is a pure Transport Protocol, the latter is an application protocol that is used as transport.
> 
> From a pure WebSocket prospective, what you are going to define is SIP as a websocket sub-protocol that is transported on top of.
> 
> The important thing to standardize from a SIPCore prospective is the interaction/translations that happens between the WebSocket server and the SIP proxy

Sorry about the confusion, the only reason why I mentioned SCTP was to illustrate that the suggested additions weren't IMHO necessary as they weren't for SCTP. Just as an example.

As I mentioned earlier, I would not mention anything regarding UDP and TCP, 3261 applies. Even if browsers are not able to use TCP and UDP directly I don't see a strong reason to forbid them.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 16:31:59 +0200

> As I mentioned earlier, I would not mention anything regarding UDP and TCP, 3261 applies. Even if browsers are not able to use TCP and UDP directly I don't see a strong reason to forbid them.

Agreed. Let's imagine a SIP local network in which the administrator
just wants SIP over TLS-TCP for security/privacy reasons, so SIP
phones and the SIP proxy/PBX/server just talk TLS-TCP transport. Would
we say that those SIP phones are violating the RFC 3261 since they are
not listening into insecure UDP transport? I don't think so.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 16:24:13 +0200

2012/4/18 Salvatore Loreto <[email-masked]>:
> interaction/translations that happens between the WebSocket server and the
> SIP proxy that are two different logical entities.

Hi Salvatore, I don't consider them two different logical entities.
The draft 02 states the following in "Definitions" section (which was
added after your review):

   SIP WebSocket Server:  A SIP entity capable of listening for inbound
         connections from WebSocket clients and speaking the WebSocket
         SIP Sub-Protocol as defined by this document.

So when the WebSocket message/arrives to the WebSocket listening
server, the application on top of it (a SIP proxy/UAS) should extract
the SIP message from the WS message, parse it and process it in the
same way that if the SIP message arrived via another SIP transport.
Just it. And for sending responses the SIP proxy/UAS should reuse the
existing WS connection (which implies creating a WS message and
writting the SIP response inside). Just it.

The same is true for a SIP WebSocket Client:

   SIP WebSocket Client:  A SIP entity capable of opening outbound
         connections with WebSocket servers and speaking the WebSocket
         SIP Sub-Protocol as defined by this document.

For example, if the SIP application is a JavaScript code running on a
web browser, the SIP stack (JS code) sends and receives SIP messages
to/from its transport layer (as in any other SIP transport), but in
this case the transport layer is a WebSocket client interface which
generates a WS message (using the JS WebSocket API) and sends it. Same
occurs when receiving an incoming SIP request/response which is
extracted by the JS app (the SIP stack) from the received WS message.

So honestly I see no "interaction/translations that happens between
the WebSocket server and the SIP proxy".

Best regards.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Apr 2012 10:47:54 -0400

On 4/18/12 4:23 AM, Ravindran, Parthasarathi wrote:

> Please note that SIP UA with TLS transport is not going to violate Sec
> 18 of RFC 3261 “All SIP elements MUST implement UDP and TCP.”.
> In the below mentioned callflow, proxy shall

I think we need to bite the bullet here and decide to revise/clarify 
that statement in 3261. There is a note following that statement that is 
useful context for understanding it:

    All SIP elements MUST implement UDP and TCP.  SIP elements MAY
    implement other protocols.

       Making TCP mandatory for the UA is a substantial change from RFC
       2543.  It has arisen out of the need to handle larger messages,
       which MUST use TCP, as discussed below.  Thus, even if an element
       never sends large messages, it may receive one and needs to be
       able to handle them.

Clearly there are some objectives that this normative statement is 
trying to solve:

- a basic level of protocol interoperability
- support for large messages

I think we can find a way to achieve those objectives while loosening 
the requirements to support the sorts of constrained implementation 
environments we are seeing.

Both the websocket transport and outbound rely upon a neighboring sip 
element to bridge the gap to interoperability. So rather than 
implementing UDP and TCP itself, the websocket client depends upon the 
websocket server to implement them on its behalf.

I think it will take a bit work to craft new language that provides the 
needed additional flexibility while not giving license to create 
implementations that lack basic interoperability.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Apr 2012 10:58:52 -0400

There has already been a lot of discussion on this thread. But one 
fundamental point about the message below doesn't seem to have been 
mentioned. (Or did I miss it?) See inline.

> request to UAS over simple udp *without security*.

This was allowed by 3261, but that behavior was repealed by rfc5630 
section 5.3.

	Thanks,
	Paul

> In this case, proxy must behave like a dialog stateful proxy. stateless
> or transaction stateful proxy can't inter work in this scenario.
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 18 Apr 2012 15:10:44 +0000

Hi Paul/Inaki,

We are in the same page that there is no need of UDP and TCP transport while websocket is used as a transport in SIP UA even though it is a deviation from RFC 3261. As Nataraj/Christer mentioned in the other mail threads, UDP & TCP is an overkill for SIP UA while using SIP UA with websocket and non-starter for web-browsers with SIP based on Javascript. 

Having said that, please indicate that Websocket (to any transport) Proxy MUST include record-route header in all SIP messages and it is a mandatory header for websocket proxy as per this specification. It may be preferable to provide the reason for this mandating. IMO, This information helps websocket proxy implementers.  Also indicates that, stateless proxy is not applicable for this transport.

I like to hear in case any other way to make SIP over websocket works without record-route header.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Paul Kyzivat
>Sent: Wednesday, April 18, 2012 8:18 PM
>To: [email-masked]
>> 18 of RFC 3261 "All SIP elements MUST implement UDP and TCP.".
>> In the below mentioned callflow, proxy shall acts as stateless or
>> transaction stateful proxy wherein UAC shall sent INVITE with SIPS URI
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Apr 2012 17:55:52 +0200

2012/4/18 Ravindran, Parthasarathi <[email-masked]>:

> Having said that, please indicate that Websocket (to any transport) Proxy MUST include record-route header in all SIP messages and it is a mandatory header for websocket proxy as per this specification. It may be preferable to provide the reason for this mandating. IMO, This information helps websocket proxy implementers.

Hi Ravindran. If a proxy behaves as an Outbound Edge Proxy (RFC 5626)
then it adds Record-Route always (since NATted clients can only
receive incoming requests from their Outbound proxy via TCP, UDP, or
WebSocket).

Implementing RFC 5626 "Outbound" was a MUST in previous draft version,
but such a requirement was removed in IETF #83 after consensus by
members of this WG, so the draft does NOT mandate RFC 5626 (which IMHO
is a good decision since it "just defines a new SIP transport" rather
than a complete SIP topology).

Anyhow, Record-Route (Loose-Routing mechanism as defined in RFC 3261)
is *NOT* required in *ALL* the cases in which a SIP WebSocket UA is
involved, for example:

- alice is a SIP UA implementing a SIP WS Client and a SIP WS Server
(so it can open and accept WS connections).

- The very same for bob, another SIP WS UA. But bob also speaks UDP
and registers to P1 via UDP.

- P1 is a proxy/registrar implementing a SIP WebSocket Server (so just
listens for inbound WS connections) and also UDP.

- P1 does NOT perform Loose-Routing (it does NOT add Record-Route headers).

- alice, bob and P1 are located in the same network (or have public IP...).

So:

      alice                     P1                    bob

F1    INVITE -----(WS)--------->
F2                                INVITE ----(UDP)------->

F3                                <---(UDP)----------- 200
F4     <-----(WS)----------- 200

F5    ACK ---------------------(WS)---------------------->

F6    <------------------------(WS)------------------- BYE
F7    200 ---------------------(WS)---------------------->

F1: INVITE from alice has a Contact URI with ;transport=ws.

F2. P1 does NOT add Record-Route header.

F3. 200 from bob contains a Contact URI with ;transport=ws (which is
valid regardless the INVITE arrived via UDP transport).

F5. alice opens a new WS connection to the Contact URI of bob (since
ACK must be send end to end when there is no Record-Route in 200) and
sends the ACK.

F7. bob opens a new WS connection to the Contact URI of alice and sends the BYE.

This is perfectly valid according to RFC 3261 and there is NO need for
Loose-Routing mechanism, so the draft MUST NOT mandate Loose-Routing
mechanism.

Again, you assume that the SIP WebSocket UA is a web browser that can
only open outbound WS connections. The draft is not based on such an
assumption (regardless we all know that this will be the scenario in
99% of cases). We leave the SIP topology open (this was recently
discussed in this maillist before IETF #83).

> Also indicates that, stateless proxy is not applicable for this transport.

Please read my previous replies. Stateless proxy CAN be used (please
read my first reply in this thread in which I explain it).

> I like to hear in case any other way to make SIP over websocket works without record-route header.

See example above.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Apr 2012 18:08:37 +0200

Hi,

>> As I mentioned earlier, I would not mention anything regarding UDP and TCP, 3261 applies. Even if >>browsers are not able to use TCP and UDP directly I don't see a strong reason to forbid them.
>

I agree that we shouldn't forbid.

Regards,

Christer

---

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

2012/4/18 Paul Kyzivat <[email-masked]>:
> I think we can find a way to achieve those objectives while loosening the
> requirements to support the sorts of constrained implementation environments
> we are seeing.
>
> element to bridge the gap to interoperability. So rather than implementing
> UDP and TCP itself, the websocket client depends upon the websocket server
> to implement them on its behalf.
>

Hi Paul, the scenario is similar to the one in which a SIP UA behind
NAT registers using UDP through its Outbound Edge Proxy, so it can
only receive incoming requests (from outside its local network) via
its Outbound proxy. Neither it can receive inbound TCP connections.

So, perhaps we could extract some related text from RFC 5626? But note
that mandating RFC 5626 was removes in Paris due the got consensus.

However, this discussion assumes that the SIP UA is a SIP WebSocket
Client just capable of using WebSocket transport (so probably a web
browser), and that the SIP WebSocket Server is a SIP proxy which
cannot open outbound WS connections (and speaks other transports).
This assumption does not exist in the draft. If a UA or a proxy
implements both a SIP WebSocket Client and a SIP WebSocket Server then
all this discussion becomes "invalid" since topology constrains are
relaxed.

So:

- This draft does not assume network topology.
- This draft does not assume clients and proxies/servers nature.
- RFC 3261 mandates UDP and TCP.

JavaScripts SIP stacks running in browsers will not implement SIP UDP/TCP.
Are those SIP stacks "violating" RFC 3261? well, things change since
2002, and probably a SIP transport like WebSocket was not expected
when RFC 3261 was written. But anyhow, from the point of view of the
draft itself, IMHO the spec is not violating RFC 3261 since it does
not assume the "web browser" scenario.

Best regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Apr 2012 18:17:14 +0200

Hi,

In general I agree that a transport mechanism specification shouldn't mandate entities to Record-Route.

But, as others have also indicated, in most cases it will be needed. The signalling path between the UA and the "outbound proxy" will be established already during registration (which means the proxy will also have to insert Path), and will then be used for UA originating and terminating sessions.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Iñaki Baz Castillo [[email-masked]]
Sent: Wednesday, April 18, 2012 6:55 PM
To: Ravindran, Parthasarathi
Cc: [email-masked]
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

So:

      alice                     P1                    bob

See example above.

Regards.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Apr 2012 12:58:49 -0400

Iñaki,

I agree that there is nothing in this draft that requires someone 
implementing it to violate 3261.

However, as you mention below, a typical use case for this draft is 
javascript sip stacks running in a browser that would not be able to 
implement sip tcp and udp transports. AFAIK those would indeed be 
non-compliant to 3261. If we want to encourage such implementations, 
then we should do something so that they can be compliant. ISTM that 
this will require a revision to 3261. That could be done in a separate 
draft, or it could be done in this draft that is already revising 3261.

One disadvantage to doing it in this draft is that then compliance to 
the revised language would be advertised by advertising support for 
*this* document. If the relaxation is to apply to other implementations 
of sip that don't want to implement the websocket transport, then it 
should be done separately.

	Thanks,
	Paul

On 4/18/12 12:13 PM, Iñaki Baz Castillo wrote:
> 2012/4/18 Paul Kyzivat<[email-masked]>:

---

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

2012/4/18 Paul Kyzivat <[email-masked]>:
> non-compliant to 3261. If we want to encourage such implementations, then we
> should do something so that they can be compliant. ISTM that this will
> require a revision to 3261. That could be done in a separate draft, or it
> could be done in this draft that is already revising 3261.
>
> One disadvantage to doing it in this draft is that then compliance to the
> revised language would be advertised by advertising support for *this*
> document. If the relaxation is to apply to other implementations of sip that
> don't want to implement the websocket transport, then it should be done
> separately.

I agree. A new draft should address this issue by covering the following topics:

- Scenarios in which just *secure* SIP transport is required (so UDP
has no place). This could occur in local networks, providers networks
or whatever.

- Scenarios in which a single transport can be used (i.e. in Outbound
topology in which UA's are behind different NAT's and connect to the
same Edge Proxy using TCP or UDP, so they cannot receive requests via
a different transport).

- Special cases in which it's clear that ~100% of implementations are
not able to support SIP UDP/TCP transports (as in this draft).

Basically it would say "in certain cases a SIP entity MAY NOT
implement UDP and/or TCP transports".

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 19 Apr 2012 01:56:04 +0000

Inaki,

I agree with Christer for mandating path in case REGISTER is the first message
and it is not required to be mandated in case INVITE is the first message.

In the mentioned below callflow, P1 should be some prior knowledge about Bob
that Bob supports websocket transport which is not always feasible through 
standard mechanism. Also, the callflow is not generic enough to handle 
SIP entity which supports UDP & TCP transport only.

Thanks
Partha

>From: Christer Holmberg [mailto:[email-masked]]
>Sent: Wednesday, April 18, 2012 9:47 PM
>To: Iñaki Baz Castillo; Ravindran, Parthasarathi
>Cc: [email-masked]
>But, as others have also indicated, in most cases it will be needed. The
>signalling path between the UA and the "outbound proxy" will be
>established already during registration (which means the proxy will also
>have to insert Path), and will then be used for UA originating and
>terminating sessions.
>
>Regards,
>
>Christer
>
>
>
>
>
>> Having said that, please indicate that Websocket (to any transport)
>Proxy MUST include record-route header in all SIP messages and it is a
>mandatory header for websocket proxy as per this specification. It may
>be preferable to provide the reason for this mandating. IMO, This
>information helps websocket proxy implementers.
>
>
>then it adds Record-Route always (since NATted clients can only receive
>incoming requests from their Outbound proxy via TCP, UDP, or WebSocket).
>
>Anyhow, Record-Route (Loose-Routing mechanism as defined in RFC 3261) is
>*NOT* required in *ALL* the cases in which a SIP WebSocket UA is
>involved, for example:
>
>
>- alice is a SIP UA implementing a SIP WS Client and a SIP WS Server (so
>it can open and accept WS connections).
>
>- The very same for bob, another SIP WS UA. But bob also speaks UDP and
>registers to P1 via UDP.
>
>F5. alice opens a new WS connection to the Contact URI of bob (since ACK
>must be send end to end when there is no Record-Route in 200) and sends
>the ACK.
>
>assumption (regardless we all know that this will be the scenario in 99%
>of cases). We leave the SIP topology open (this was recently discussed
>in this maillist before IETF #83).
>
>
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 19 Apr 2012 02:47:05 +0000

Hi Nataraju,

[ABN] Partha,
          Can you name some scenario which need this incoming SIP requests @ the WebSocket client ????

There are two scenario which I could think of

1)      Skype sort of websocket application in endpoint

2)      B2BUA which listen on websocket to receive the calls without registration

Thanks
Partha

From: Nataraju A.B [mailto:[email-masked]]
Sent: Wednesday, April 18, 2012 3:50 PM
To: Ravindran, Parthasarathi
Cc: Saúl Ibarra Corretgé; SIPCORE (Session Initiation Protocol Core) WG; SIPCORE Chairs; Iñaki Baz Castillo
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> wrote:

I'll write the separate mail thread for discussing incoming SIP over websocket
as it is one another major open item in this draft.
[ABN] Partha,
          Can you name some scenario which need this incoming SIP requests @ the WebSocket client ????

Thanks
Partha

>From: Saúl Ibarra Corretgé [mailto:[email-masked]<mailto:[email-masked]>]

--
Thanks,
Nataraju A.B.

---

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

On Wed, Apr 18, 2012 at 10:28 PM, Paul Kyzivat <[email-masked]>wrote:

> non-compliant to 3261. If we want to encourage such implementations, then
> we should do something so that they can be compliant. ISTM that this will
> document. If the relaxation is to apply to other implementations of sip
> that don't want to implement the websocket transport, then it should be
> done separately.
>

   [ABN] I agree, it is better to address these issues in a new draft to
specify the deviations from 3261 due to web socket transport support. At
least there should be a statement in this doc/draft mentioning the
deviation from 3261 like,

   5.4.  Deviations from RFC 3261

   These deviations shall be conditional, non support for UDP / TCP
acceptable only when WebSocket transport or equivalent one is supported. In
no other cases this relaxation applicable.

>> 2012/4/18 Paul Kyzivat<[email-masked]>**:
>>
>>> implementing
> ______________________________**_________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>

-- 
Thanks,
Nataraju A.B.

---

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

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

> then we
> that

    [ABN] In addition, we can also add the change for deprecated transport
parameter, *transport=tls*.

transport-param   =  "transport="
                     ( "udp" / "tcp" / "sctp" / other-transport)

     --> "tls" removed

This should have been taken care when rfc5630 was introduced (but some
how missed). Atleast we can take care off through this new draft.

-- 
Thanks,
Nataraju A.B.

---

From: Brett Tate <[email-masked]>
Date: Thu, 19 Apr 2012 08:01:19 -0700

> [ABN] In addition, we can also add the change for deprecated 
> transport parameter, transport=tls.
>
> This should have been taken care when rfc5630 was introduced 
> (but some how missed). Atleast we can take care off through 
> this new draft.

RFC 5630 and RFC 3261 indicate why "tls" was not to removed from ABNF.

RFC 5630:

3.1.4.  Usage of the transport=tls URI Parameter and the TLS Via
        Parameter

   [RFC3261], Section 26.2.2 deprecated the "transport=tls" URI
   transport parameter in SIPS or SIP URIs:

      Note that in the SIPS URI scheme, transport is independent of TLS,
      and thus "sips:[email-masked];transport=TCP" and
      "sips:[email-masked];transport=sctp" are both valid (although
      note that UDP is not a valid transport for SIPS).  The use of
      "transport=tls" has consequently been deprecated, partly because
      it was specific to a single hop of the request.  This is a change
      since RFC 2543.

   The "tls" parameter has not been eliminated from the ABNF in
   [RFC3261], Section 25, since the parameter needs to remain in the
   ABNF for backward compatibility in order for parsers to be able to
   process the parameter correctly.  The transport=tls parameter has
   never been defined in an RFC, but only in some of the Internet drafts
   between [RFC2543] and [RFC3261].

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 19 Apr 2012 10:04:53 -0500

On 04/18/2012 08:56 PM, Ravindran, Parthasarathi wrote:
> SIP entity which supports UDP&  TCP transport only.

This has already been covered extensively on the list; this document 
should not *normatively* make any such statements. The requirement to 
use Outbound, Path, or any other non-RFC 3261 mechanism is dependent on 
the architecture of the SIP deployment, and it's up to the implementor 
to determine whether any such mechanisms are necessary and how they 
should be used. The document describing the WebSocket transport has no 
place mandating such usage.

In addition, whether these requests are the 'first message' over the 
WebSocket connection or not is not relevant. If a UA wants to open a 
SIP-over-WebSocket connection and then send four OPTIONS requests before 
sending a REGISTER, there's no reason for that to be a problem.

If the informative sections of the document need to be expanded to 
include such guidance and recommendations that could be useful, but 
that's a separate discussion.

---

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

> and it is not required to be mandated in case INVITE is the first message.

Hi Partha, honestly I don't think it's a good idea to mandate SIP
topology requirements in a draft describing a SIP transport (just it).
We tryed to mandate Outbound RFC 5626 and such a requirement was
removed in IETF #83 due to consensus. So mandating Path is mostly the
same "error".

It was clearly agreed in Paris that the draft should not assume a SIP
network topology, but also that it should include a *informative*
section for the most expected use case (clients like SIP browsers).
This is already done in Appendix I which describes such an scenario
and all the SIP standards (Outbound, Path, GRUU) that could help to
make it to work. But *just* it.

Again, the draft does NOT assume that clients are web browsers so
please consider it for future suggestions about the draft.

> SIP entity which supports UDP & TCP transport only.

I don't agree. But if it is easier to understand imagine that alice,
bob and the proxy/registrar all of them implement a WebSocket client
and server, so alice can open a WS connection to proxy and also to
bob, and the same for bob. So no Record-Route required. That's all.

Regards.

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

---

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

Partha,
After some thinking, I also found we need incoming SIP requests @ websocket
clients for presence services like gtalk, yahoo, skype messengers...

On Thu, Apr 19, 2012 at 8:17 AM, Ravindran, Parthasarathi <
[email-masked]> wrote:

>  Hi Nataraju,****
> [ABN] Partha, ****
> @ the WebSocket client ???? ****
>
> ** **
>
> There are two scenario which I could think of****
>
> ** **
>
> **1)      **Skype sort of websocket application in endpoint ****
>
> **2)      **B2BUA which listen on websocket to receive the calls without
> registration****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *Sent:* Wednesday, April 18, 2012 3:50 PM
> *Cc:* Saúl Ibarra Corretgé; SIPCORE (Session Initiation Protocol Core)
> WG; SIPCORE Chairs; Iñaki Baz Castillo
> as it is one another major open item in this draft.****
>
> [ABN] Partha, ****
>
> @ the WebSocket client ???? ****
>
>
> Thanks
> Partha****
>
>
> >To: Ravindran, Parthasarathi****
>

-- 
Thanks,
Nataraju A.B.

---

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

> clients for presence services like gtalk, yahoo, skype messengers...

I don't understand. Presence in SIP is based on PUBLISH, SUBSCRIBE,
NOTIFY. If the SIP client is connected to an Outbound proxy the SIP
client would reuse the same connection for sending PUBLISH, SUBSCRIBES
and so (since there is already a open connection open to the outbound
proxy as RFC 3261 states) and therefore also for receiving NOTIFY
requests (within the subscription dialog).

But again, nothing prevents somebody to code a SIP WebSocket entity
capable of creating outbound WS connections and listening for inbound
WS connections. Please don't assume that the draft just talks about
web browsers.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 20 Apr 2012 00:39:03 +0000

Hi Inaki,

There are only two options which I could think of forward for this draft

1) As I earlier mentioned, Websocket transport works well only in specific SIP topology and not in all topology as it is not capable of supporting UDP/TCP transport. In case the draft is only going to specify transport, then SIP entities support this draft has to have compliance with RFC 3261 (UDP, TCP transport) as well and particularly you have to mention how Javascript based SIP stack will compliance with RFC 3261.

2) Alternative is to specify SIP topology requirement wherein websocket really applies. Include the related header like record-route & path with the detail information where these headers are mandated.

IMHO, the current draft is not clear enough about SIP over Websocket transport usage.

Thanks
Partha

>Sent: Thursday, April 19, 2012 9:03 PM
>Cc: Christer Holmberg; [email-masked]
>> I agree with Christer for mandating path in case REGISTER is the first
>> message and it is not required to be mandated in case INVITE is the
>first message.
>
>We tryed to mandate Outbound RFC 5626 and such a requirement was removed
>in IETF #83 due to consensus. So mandating Path is mostly the same
>"error".
>
>This is already done in Appendix I which describes such an scenario and
>all the SIP standards (Outbound, Path, GRUU) that could help to make it
>to work. But *just* it.
>
>Again, the draft does NOT assume that clients are web browsers so please
>consider it for future suggestions about the draft.
>
>
>> In the mentioned below callflow, P1 should be some prior knowledge
>> about Bob that Bob supports websocket transport which is not always
>> feasible through standard mechanism. Also, the callflow is not generic
>> enough to handle SIP entity which supports UDP & TCP transport only.
>
>I don't agree. But if it is easier to understand imagine that alice, bob
>and the proxy/registrar all of them implement a WebSocket client and
>server, so alice can open a WS connection to proxy and also to bob, and
>the same for bob. So no Record-Route required. That's all.
>
>
>
>Regards.
>
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 20 Apr 2012 10:04:37 +0200

Hi Partha,

> 1) As I earlier mentioned, Websocket transport works well only in specific SIP topology and not in all topology as it is not capable of supporting UDP/TCP transport. In case the draft is only going…

SIP over UDP also doesn't work on all topologies, just think about NAT. IMO this draft should not target at using SIP in web browsers using JavaScript, it should just define a new transport for the SIP protocol, which is exactly what it does. There are, indeed, inherent limitations when using SIP in a web browser, but these limitations are imposed by the WebSocket API, *not* by this draft.

Also note that there is no "IETF police", if I would implement this draft for using a SIP client within a browser I would not implement UDP or TCP support whatsoever, because they can't be used *in a browser*. Sue me :-)

> IMHO, the current draft is not clear enough about SIP over Websocket transport usage.

I fail to understand what is not clear about it. Of course WebSockets are used in browsers nearly 100% of the time, but this draft doesn't restrict itself to that model. You could write a desktop SIP client using WebSocket as a transport, and you could listen for incoming connections since limitations such as those in web browsers wouldn't apply. So, please, can you clarify *what* is it not clear about it?

Thanks and regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 20 Apr 2012 08:58:55 +0000

Saul,

My reading of your statement "There are, indeed, inherent limitations when using SIP in a web browser, but these limitations are imposed by the WebSocket API, *not* by this draft." is that websocket does not qualify as a transport for SIP as it is not possible to meet RFC 3261 requirement.

NAT is not SIP endpoint issue but it is a network issue. All NAT are not considered as part of RFC 3261 design but it is resolved as part of Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) RFC (5626). 

Thanks
Partha

Note: AFAIK, NAT issue in SIP is one of the reason for not selecting SIP as part of signaling/transport protocol in RTCWeb.

>Sent: Friday, April 20, 2012 1:35 PM
>Cc: Iñaki Baz Castillo; [email-masked]
>> 1) As I earlier mentioned, Websocket transport works well only in
>specific SIP topology and not in all topology as it is not capable of
>supporting UDP/TCP transport. In case the draft is only going to specify
>transport, then SIP entities support this draft has to have compliance
>with RFC 3261 (UDP, TCP transport) as well and particularly you have to
>mention how Javascript based SIP stack will compliance with RFC 3261.
>>
>
>SIP over UDP also doesn't work on all topologies, just think about NAT.
>IMO this draft should not target at using SIP in web browsers using
>JavaScript, it should just define a new transport for the SIP protocol,
>which is exactly what it does. There are, indeed, inherent limitations
>when using SIP in a web browser, but these limitations are imposed by
>the WebSocket API, *not* by this draft.
>
>Also note that there is no "IETF police", if I would implement this
>draft for using a SIP client within a browser I would not implement UDP
>or TCP support whatsoever, because they can't be used *in a browser*.
>Sue me :-)
>
>> 2) Alternative is to specify SIP topology requirement wherein
>websocket really applies. Include the related header like record-route &
>path with the detail information where these headers are mandated.
>>
>I fail to understand what is not clear about it. Of course WebSockets
>are used in browsers nearly 100% of the time, but this draft doesn't
>restrict itself to that model. You could write a desktop SIP client
>using WebSocket as a transport, and you could listen for incoming
>connections since limitations such as those in web browsers wouldn't
>apply. So, please, can you clarify *what* is it not clear about it?
>
>
>Thanks and regards,
>
>--
>Saúl Ibarra Corretgé
>AG Projects
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Apr 2012 11:01:42 +0200

Why not write a separate draft, which updates 3261 by saying that all transports are optional... That's how the real world looks, anyway.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: 20. huhtikuuta 2012 11:59
To: Saúl Ibarra Corretgé
Cc: Iñaki Baz Castillo; [email-masked]
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

Saul,

Thanks
Partha

>supporting UDP/TCP transport. In case the draft is only going to 
>specify transport, then SIP entities support this draft has to have 
>compliance with RFC 3261 (UDP, TCP transport) as well and particularly 
>you have to mention how Javascript based SIP stack will compliance with RFC 3261.
>>
>
>websocket really applies. Include the related header like record-route 
>& path with the detail information where these headers are mandated.
>>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 20 Apr 2012 11:18:41 +0200

+1

--
Saúl Ibarra Corretgé
AG Projects

---

From: José Luis Millán <[email-masked]>
Date: Fri, 20 Apr 2012 11:48:18 +0200

Hi Pharta,

> My reading of your statement "There are, indeed, inherent limitations when using SIP in a web browser, but these limitations are imposed by the WebSocket API, *not* by this draft." is that websocke…

Please, have a look at the response given by Paul in this thread .

http://www.ietf.org/mail-archive/web/sipcore/current/msg04802.html

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 20 Apr 2012 12:11:29 +0200

Partha,

> My reading of your statement "There are, indeed, inherent limitations when using SIP in a web browser, but these limitations are imposed by the WebSocket API, *not* by this draft." is that websocke…

Your reading is incorrect. The fact that *a device* be it a browser, a calculator or a softphone is unable to use a specific transport due to environment limitations doesn't render the transport unqualifiable.

Again, this is not the "SIP transport for web browsers" draft.

> NAT is not SIP endpoint issue but it is a network issue. All NAT are not considered as part of RFC 3261 design but it is resolved as part of Managing Client-Initiated Connections in the Session Ini…

Web browser limitations are not a SIP endpoint issue either.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Nataraju A.B" <[email-masked]>
Date: Fri, 20 Apr 2012 16:39:28 +0530

On Fri, Apr 20, 2012 at 3:41 PM, Saúl Ibarra Corretgé
<[email-masked]>wrote:

> > My reading of your statement "There are, indeed, inherent limitations
> when using SIP in a web browser, but these limitations are imposed by the
> WebSocket API, *not* by this draft." is that websocket does not qualify as
> a transport for SIP as it is not possible to meet RFC 3261 requirement.
> >
>
> Your reading is incorrect. The fact that *a device* be it a browser, a
> calculator or a softphone is unable to use a specific transport due to
> environment limitations doesn't render the transport unqualifiable.
>

[ABN] If that is the case, then it is illogical to compare sip over sctp /
 sip over ws  / sip over tcp as equivalent in some of the earlier mail
threads. isn't it ???

>
> > NAT is not SIP endpoint issue but it is a network issue. All NAT are not
> considered as part of RFC 3261 design but it is resolved as part of
> Managing Client-Initiated Connections in the Session Initiation Protocol
> (SIP) RFC (5626).
> >
>

-- 
Thanks,
Nataraju A.B.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 20 Apr 2012 13:56:45 +0200

Hi Partha,

I would like to comment you that there are other technologies that
allow coding applications to be executed in web browsers (apart from
JavaScript), those are Flash, Java, SilverLight...

I'm not an expert in them but I do know that some of them gives the
developer access to the TCP/UDP stack of the host, so you are able to
code a SIP TCP/UDP stack with them (in fact there are SIP TCP/UDP
implementations running as Java applets). Those technologies
(regardless they are proprietary or not) also implement, or will
implement soon, a WebSocket stack so they can connect to WebSocket
servers.

This means that you can build a SIP TCP/UDP/WebSocket client and run
it in a web browser.

And of course, there are WebSocket libraries available for many
languages (C, C++, Java, Ruby, Python, Perl...). Somebody could
implement SIP over WebSocket (along with other transports such a
TCP/UDP) and code a SIP client to run as a desktop application or
smartphone app or whatever.

Unfortunately you insist on "The WebSocket API" [1] which is a W3C
specification that enables WebSocket support in web browsers to be
managed via a JavaScript API. You assume that the "SIP WebSocket
Transport" is for web browsers and, not just it, but also that it is
for implementing a SIP stack in JavaScript language. Please check the
draft again and realize that all the references to web browsers,
JavaScript and "The WebSocket API" are just informative and not
normative.

The draft MUST NOT mention that a web browser + JavaScript "is not SIP
compliant since it cannot run SIP over TCP/UDP". The draft just
defines a SIP transport and does not assume not web browsers scenarios
neither JavaScript usage, and as said above, there are more
technologies for developing web applications.

In the other side, the draft does not define a signaling mechanism for
WebRTC. rtcweb WG specifications define the media transport (audio,
video, data channel) for web based applications but does not mandate a
signaling protocol between browsers and servers, neither it mandates
that such a protocol should be managed via JavaScript or that it
should be carried on top of HTTP or WebSocket (you could implement
your custom signaling protocol via RTMP or TCP by using Flash, Java
applet, SilverLight or whatever web technology, and then make use of
the WebRTC stak of the browser for enabling audio/video in your web
app).

So, summarizing:

a) Our draft does not assume web browsers scenario.

b) The web browser scenario must not assume JavaScript and "The
WebSocket API" only ingredients.

c) The limitation you mean (not SIP TCP/UDP transport) just applies in
"web browsers + JavaScript + The WebSocket API". That is a very
specific scope the draft does NOT assume.

Best regards.

[1] "The WebSocket API": http://dev.w3.org/html5/websockets/

PS: About "mandating" Path stuff in the draft, you were are ready
replied by me in a previous mail. Please consider reading it.

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Apr 2012 14:00:30 +0200

Hi,

In my opinion, the issue is not whether one has access to UDP/TCP or not - but the fact that it would be stupid and complex being mandated to implement so many different transports.

So, again, let's make every transport optional, and people will then implement based on customer requirements, network environments, platform characteristics, etc etc etc.

Regards,

Christer

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 20. huhtikuuta 2012 14:57
To: Ravindran, Parthasarathi
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

Hi Partha,

I would like to comment you that there are other technologies that allow coding applications to be executed in web browsers (apart from JavaScript), those are Flash, Java, SilverLight...

I'm not an expert in them but I do know that some of them gives the developer access to the TCP/UDP stack of the host, so you are able to code a SIP TCP/UDP stack with them (in fact there are SIP TCP/UDP implementations running as Java applets). Those technologies (regardless they are proprietary or not) also implement, or will implement soon, a WebSocket stack so they can connect to WebSocket servers.

This means that you can build a SIP TCP/UDP/WebSocket client and run it in a web browser.

And of course, there are WebSocket libraries available for many languages (C, C++, Java, Ruby, Python, Perl...). Somebody could implement SIP over WebSocket (along with other transports such a
TCP/UDP) and code a SIP client to run as a desktop application or smartphone app or whatever.

Unfortunately you insist on "The WebSocket API" [1] which is a W3C specification that enables WebSocket support in web browsers to be managed via a JavaScript API. You assume that the "SIP WebSocket Transport" is for web browsers and, not just it, but also that it is for implementing a SIP stack in JavaScript language. Please check the draft again and realize that all the references to web browsers, JavaScript and "The WebSocket API" are just informative and not normative.

The draft MUST NOT mention that a web browser + JavaScript "is not SIP compliant since it cannot run SIP over TCP/UDP". The draft just defines a SIP transport and does not assume not web browsers scenarios neither JavaScript usage, and as said above, there are more technologies for developing web applications.

In the other side, the draft does not define a signaling mechanism for WebRTC. rtcweb WG specifications define the media transport (audio, video, data channel) for web based applications but does not mandate a signaling protocol between browsers and servers, neither it mandates that such a protocol should be managed via JavaScript or that it should be carried on top of HTTP or WebSocket (you could implement your custom signaling protocol via RTMP or TCP by using Flash, Java applet, SilverLight or whatever web technology, and then make use of the WebRTC stak of the browser for enabling audio/video in your web app).

So, summarizing:

b) The web browser scenario must not assume JavaScript and "The WebSocket API" only ingredients.

c) The limitation you mean (not SIP TCP/UDP transport) just applies in "web browsers + JavaScript + The WebSocket API". That is a very specific scope the draft does NOT assume.

Best regards.

PS: About "mandating" Path stuff in the draft, you were are ready replied by me in a previous mail. Please consider reading it.

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 20 Apr 2012 07:44:28 -0500

> So, again, let's make every transport optional, and people will then implement based on customer requirements, network environments, platform characteristics, etc etc etc.

Let's just get this started... it's already relevant since SCTP has been 
defined as a transport for SIP. A UA that wants to solely use SCTP 
should be allowed to do that without being labeled non-compliant with 
RFC 3261.

How would this work? Would this just be a two-page document updating 
that one small section of RFC 3261?

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 20 Apr 2012 07:47:30 -0500

> My reading of your statement "There are, indeed, inherent limitations when using SIP in a web browser, but these limitations are imposed by the WebSocket API, *not* by this draft." is that websocke…

This statement is not supported by any facts. It's completely possible 
and practical to use WebSocket between two *non-web-browser* UAs, if 
there is value in doing so. In fact, I can already see value in 
softphones and hardphones supporting SIP over WebSocket (in addition to, 
or instead of, UDP and plain TCP).

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Apr 2012 14:50:21 +0200

Hi,

> Let's just get this started... it's already relevant since SCTP has been defined as a transport for SIP. A UA that wants to solely use SCTP should be allowed to do that without being labeled non-compliant with RFC 3261.
>
> How would this work? Would this just be a two-page document updating that one small section of RFC 3261?

Pretty much, yes :)

Of course, in addition to the actual update there would need to be some justification text.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 20 Apr 2012 14:54:55 +0200

> Of course, in addition to the actual update there would need to be some justification text.

Hi, in a previous mail I suggested some points for such a new work.
This future draft could address this topic by covering the following
cases:

- Scenarios in which just a single transport can be used due to
network topology (i.e. in Outbound topology in which UA's are behind
different NAT's and connect to the same Edge Proxy using TCP or UDP,
so they cannot receive requests via a different transport than the one
they use to connect to their Outbound proxy).

- Special cases in which it's clear that, given enviroment/plattform
constrains, some implementations are not able to support SIP UDP/TCP
transports.

Basically such a draft could state that "in certain cases (such as
those described above) a SIP entity MAY NOT implement UDP and/or TCP
transports, being this an update to RFC 3261".

IMHO just one page :)

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Apr 2012 15:05:03 +0200

You can use IPSec to get secure SIP traffic with UDP :)

Regards,

Christer

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 20. huhtikuuta 2012 15:55
To: Christer Holmberg
Cc: Kevin P. Fleming; [email-masked]
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

- Scenarios in which just *secure* SIP transport is required (so UDP has no place). This could occur in local networks, providers networks or whatever.

- Scenarios in which just a single transport can be used due to network topology (i.e. in Outbound topology in which UA's are behind different NAT's and connect to the same Edge Proxy using TCP or UDP, so they cannot receive requests via a different transport than the one they use to connect to their Outbound proxy).

- Special cases in which it's clear that, given enviroment/plattform constrains, some implementations are not able to support SIP UDP/TCP transports.

Basically such a draft could state that "in certain cases (such as those described above) a SIP entity MAY NOT implement UDP and/or TCP transports, being this an update to RFC 3261".

IMHO just one page :)

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 20 Apr 2012 15:11:24 +0200

Rigth. Then let me add this scenario:

- Scenarios in which large SIP messages are required so UDP is no valid.

;)
El 20/04/2012 15:05, "Christer Holmberg" <[email-masked]>
escribió:

> Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in
> Websocket transport? [RE: Call for Adoption:
> draft-ibc-sipcore-sip-websocket-02]
>
> >>> So, again, let's make every transport optional, and people will then
> implement based on customer requirements, network environments, platform
> characteristics, etc etc etc.
> >>
> >> Let's just get this started... it's already relevant since SCTP has
> been defined as a transport for SIP. A UA that wants to solely use SCTP
> should be allowed to do that without being labeled non-compliant with RFC
> 3261.
> >>
> - Scenarios in which just *secure* SIP transport is required (so UDP has
> no place). This could occur in local networks, providers networks or
> whatever.
>
> - Scenarios in which just a single transport can be used due to network
> topology (i.e. in Outbound topology in which UA's are behind different
> NAT's and connect to the same Edge Proxy using TCP or UDP, so they cannot
> receive requests via a different transport than the one they use to connect
> to their Outbound proxy).
>
> Basically such a draft could state that "in certain cases (such as those
> described above) a SIP entity MAY NOT implement UDP and/or TCP transports,
> being this an update to RFC 3261".
>
> IMHO just one page :)
>
>
> --
> Iñaki Baz Castillo
> <[email-masked]>
>

---

From: Bob Penfield <[email-masked]>
Date: Fri, 20 Apr 2012 13:14:55 +0000

This is a going to be a Standards Track RFC, therefore it can "update" 3261 with text that relaxes the "UDP and TCP" requirement in circumstances where it is not possible (e.g. in a browser) or not practical. I don't think you need a separate draft.

When we were working on 3261 about 10 years ago, we had discussions/debates about whether UDP should be required. IIRC, there were some people advocating UDP be deprecated altogether. There were also discussions about removing the requirement for UDP at some point in the future. The standards need to evolve with the state of the art.

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, April 20, 2012 5:02 AM
To: Ravindran, Parthasarathi; Saúl Ibarra Corretgé
Cc: Iñaki Baz Castillo; [email-masked]
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: 20. huhtikuuta 2012 11:59
To: Saúl Ibarra Corretgé
Cc: Iñaki Baz Castillo; [email-masked]
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

Saul,

Thanks
Partha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 20 Apr 2012 16:03:36 +0200

> This is a going to be a Standards Track RFC, therefore it can "update" 3261 with text that relaxes the "UDP and TCP" requirement in circumstances where it is not possible (e.g. in a browser) or not…

Hi Bob. Taking into account that new SIP transports could appear in
the future, would not make more sense to write such an statement in a
separate draft? Just wondering. As Paul said, otherwise each new SIP
transport specification should include the same update to RFC 3261.

Thanks a lot.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Apr 2012 11:03:48 -0400

I've been looking for a suitable place to jump back into this thread.
Maybe this is as good a place as any. I've changed the subject to 
reflect the current focus of the discussion.

We have two ways forward on this - the narrow way, and the broad way.

The narrow way it to craft a specific exemption for implementers of the 
websocket transport - that they aren't required to implement UDP and 
TCP. Such an exemption could be included in the websocket transport draft.

The broad way is to do a standalone update to 3261 that removes/relaxes 
the requirement to implement UDP and TCP transports.

The narrow way will be easier to achieve. Its impact is narrower and 
easier to understand. So there is likely to be much less objection to 
it. And of course it doesn't require a separate document.

The broad way will cover many more cases all in one swipe of the pen. 
But that means that it will require much more scrutiny to avoid 
unintended consequences. As a result it will be harder to craft and 
harder to pass. My main concern is that it has to potential to erect new 
barriers to interoperability. The point of having some must-implement 
transports is to ensure some common basis for interop. This has the 
potential to lose that. I am myself uncertain if I would support such a 
change. This would depend on some very careful analysis.

I can't promise that the chairs or the AD will even approve of the broad 
approach.

(I guess there is a third way - to do *nothing* about the 
mandatory-to-implement transport requirement. Leave 
javascript-browser-based sip implementations that can't do UDP or TCP 
non-compliant. IMO that is an irresponsible direction that I don't want 
to consider.)

Given all of that, I would like to have some discussion of which way the 
group would like to go. Please do more that vote - actually make the 
case for why you want to go the way you do.

	Thanks,
	Paul [as co-chair]

On 4/20/12 8:54 AM, Iñaki Baz Castillo wrote:
> 2012/4/20 Christer Holmberg<[email-masked]>:

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 20 Apr 2012 18:49:35 +0200

2012/4/20 Paul Kyzivat <[email-masked]>:
> websocket transport - that they aren't required to implement UDP and TCP.
> Such an exemption could be included in the websocket transport draft.
>
> The broad way is to do a standalone update to 3261 that removes/relaxes the
> requirement to implement UDP and TCP transports.
>
> The narrow way will be easier to achieve. Its impact is narrower and easier
> to understand. So there is likely to be much less objection to it. And of
> course it doesn't require a separate document.
>
> The broad way will cover many more cases all in one swipe of the pen. But
> that means that it will require much more scrutiny to avoid unintended
> consequences. As a result it will be harder to craft and harder to pass. My
> main concern is that it has to potential to erect new barriers to
> interoperability. The point of having some must-implement transports is to
> ensure some common basis for interop. This has the potential to lose that. I
> am myself uncertain if I would support such a change. This would depend on
> some very careful analysis.
>
> mandatory-to-implement transport requirement. Leave javascript-browser-based
> sip implementations that can't do UDP or TCP non-compliant. IMO that is an
> irresponsible direction that I don't want to consider.)
>
> group would like to go. Please do more that vote - actually make the case
> for why you want to go the way you do.

Hi Paul, thanks for opening this thread. Here my opinion:

IMHO there are cases enough to go for the broad way (a separate
document updating RFC 3261), let me repeat them and include some new
ones:

- Scenarios in which just *secure* SIP transport is required and IPsec
is not available (so UDP has no place). This could occur in local
networks, providers networks or whatever. Note that UDP-DTLS for SIP
is an expired draft.

- Scenarios in which just a single transport can be used due to
network topology (i.e. in Outbound scenarios in which UA's are behind
different NAT's and connect to the same Edge Proxy using TCP or UDP,
so they cannot receive requests via a different transport than the one
they used to connect to their Outbound proxy).

- Special cases in which it's clear that, given enviroment/plattform
constrains, some implementations are not able to support SIP UDP/TCP
transports (i.e. JavaScript SIP stacks in web browsers supporting The
WebSocket API).

- Scenarios in which large SIP messages are required. For example,
when SIMPLE/XCAP presence is used, a NOTIFY with a long resource-list
body would not fit into a UDP datagram.

- Scenarios in which SIP interconnection is "private" or negotiated by
other means (i.e. within a SIP PSTN provider infrastructure in which
SIP over SCTP is used).

*But* given you explanation about how hard would be this specification
to be designed and approved, and given the fact that I don't expect so
many new SIP transports to appear in next years, I vote for the narrow
way (a text in our SIP WebSocket Transport draft updating RFC 3261).
Such a text would be placed within "Updates to RFC 3261 section" and
could state the following (text to be improved):

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

5.2.  Updates to RFC 3261

5.2.4  Relaxing TCP/UDP Implementation Requirement

Section 18 "Transport" in RFC 3261 states that all SIP elements MUST
implement UDP and TCP transports:

It is expected that the one of the use cases for the SIP WebSocket
transport will take place within web applications. JavaScript is one
of the existing alternatives for developing applications that run
within the browser, and "The WebSocket API" provides WebSocket access
for JavaScript applications. However the JavaScript stack in web
browsers does not allow direct access to the UDP and TCP layers so
these SIP stacks cannot implement SIP UDP and TCP transports, and must
rely on the WebSocket connection they have opened to the WebSocket
server for sending and receiving SIP messages.

Therefore this specification relaxes the requirement in section 18 of
RFC 3261 by stating that a SIP WebSocket Client (as defined in section
2.1 "Definitions" of this document) MAY NOT implement UDP and TCP
transports, and instead it MAY rely on the SIP WebSocket Server it
connects to for communicating with other SIP entities implementing
different SIP transports such as UDP and TCP.

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

So being pragmatic, my vote for the narrow way.

Thanks a lot.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Apr 2012 13:26:49 -0400

Iñaki,

Thanks for putting good arguments on the table.
I could nit pick them, but that wouldn't enhance the discussion.

I'd like to pose one more subject for discussion in this thread:

Can the "broad way" be constrained in a way that minimizes abuse - 
failure to interoperate for lack of a common transport when there is no 
compelling reason why a common transport could not have been used.

As that relates to your examples below:

- is *no* communication always preferable to insecure communication?
- how often are large sip messages universally required by a UA,
   rather than being required in certain contexts?

I know cases can be contrived, but does that apply to a piece of 
equipment, or does it apply to the deployment of that equipment in a 
particular context?

My point is to figure out if we can construct a revised requirement that 
provides sufficient flexibility where it is needed to create 
implementations, yet doesn't let implementers off the hook when its just 
easier for them to omit support.

For instance, I think we would probably still want to say that a 
transport supporting large messages must always be supported.

	Thanks,
	Paul

On 4/20/12 12:49 PM, Iñaki Baz Castillo wrote:
> 2012/4/20 Paul Kyzivat<[email-masked]>:

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Apr 2012 23:08:12 +0200

Hi,

Eventhough I would give my hum for the broad way, if that is difficult to get accepted there is also a middle way: RFC 3261 mandates support of TCP and UDP, but is updated to explicitly allow specifications for new transports (SCTP, WebSocket etc) to relax that requirement for implementations of those specific transports.

The fact would still exist, that there are cases (see Inaki's examples - eventhough I could also nit pick on some of them :)  where an implementation won't use, and/or cannot be reached using both TCP and UDP.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Friday, April 20, 2012 8:26 PM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [sipcore] Should we change mandatory-to-implement transports?

Iñaki,

        Thanks,
        Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sun, 22 Apr 2012 02:55:49 +0000

Sal & others,

After reading lot of mails and thinking further, I agree with you that Websocket is an application protocol that is used as an transport for SIP. TLS is one another application protocol on top of TCP which was considered as transport (transport=tls) earlier and deprecated as part of RFC 3261 in Sec 26.2.2. TLS and Websocket has some unique behavior like hop-by-hop protocol rather than end-to-end. 

TLS is adopted within SIP using new URI namely SIPS with transport=tcp. In the same way, I'm proposing SIPWS which implies websocket over TCP, SIPWSS which implies websocket over TLS over TCP. Please let me know your opinion on the same. 

Thanks
Partha

>Behalf Of Salvatore Loreto
>Sent: Wednesday, April 18, 2012 7:41 PM
>To: [email-masked]
>> I may have misunderstood something in the conversation, but my
>suggestion would be to consider *NOT* mandating SIP WebSocket clients to
>implement SIP UDP and TCP.
>>
>> Also, I don't think we can directly compare with SCTP, since the
>typical use-case for WebSocket is browser apps (eventhough a native app
>can of course also use WS).
>
>the SIP proxy that are two different logical entities.
>
>my two cents
>Sal
>
>--
>Salvatore Loreto, PhD
>www.sloreto.com
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sun, 22 Apr 2012 03:01:28 +0000

Paul,

Even before relaxing the transport criteria, let us discuss whether websocket is a new transport or new URI as the similar discussion happens for TLS as a transport over TCP in Sec 26.2.2. I have initiated the new thread with the proposal of using websocket as a new URI (SIPWS, SIPWSS). I'll get back to this thread in case folks proves websocket as a transport.

Thanks
Partha

>Sent: Friday, April 20, 2012 8:34 PM
>To: [email-masked]
>Subject: [sipcore] Should we change mandatory-to-implement transports?
>
>(I guess there is a third way - to do *nothing* about the mandatory-to-
>implement transport requirement. Leave javascript-browser-based sip
>implementations that can't do UDP or TCP non-compliant. IMO that is an
>>>>> So, again, let's make every transport optional, and people will
>then implement based on customer requirements, network environments,
>platform characteristics, etc etc etc.
>>>>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sun, 22 Apr 2012 03:27:52 +0000

Hi all,

<snip from Sal>

>the SIP proxy that are two different logical entities.

</Snip from Sal>

Websocket server is capable of performing real time communication using RTCWeb Specification without using SIP. Websocket server will reuse SDP and following the mechanism mentioned in JSEP (Updated RFC 3264 mechanism) in some form.  

I'm of the same opinion as Sal that interworking functionality between websocket server which is capable of performing real time communication & SIP entities is the important part of standardization.  draft-ibc-sipcore-sip-websocket-02 does not address how JSEP to SIP interaction occurs as it focus on the transport mechanism. I'll write new draft about the interworking between SIP and RTCWeb entity. Please let me other opinion on the same.

Thanks
Partha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 22 Apr 2012 15:20:47 +0200

Hi Paul, let me some comments inline:

> Can the "broad way" be constrained in a way that minimizes abuse - failure
> to interoperate for lack of a common transport when there is no compelling
> reason why a common transport could not have been used.
>

I could imagine a "like-Skype" service using SIP protocol and
providing both the server infrastructure and the SIP client (i.e. a
SIP softphone). Such a provider could be interested in secure
communications so its SIP client would just implement TLS-TCP
transport for signaling and SRTP (with DTLS or SDES) for media. The
provider does not want and does not accept that their SIP clients are
reachable via UDP, neither it accepts that their SIP clients
communicate with SIP entities other than their "official" SIP
proxies/servers.

>  rather than being required in certain contexts?

A SIP UA typically just registers using a single transport and, in
common scenarios, it is just reachable through the proxy it is
connected to (i.e. Outbound scenarios). Therefore the UA would prefer
to use TCP rather than UDP and then allow big SIP messages (in case
they are needed, as for example when receiving a NOTIFY with a
resource-list XML body).

If a vendor or provider offers such a service, it might consider a
waste of time to implement UDP transport.

> I know cases can be contrived, but does that apply to a piece of equipment,
> or does it apply to the deployment of that equipment in a particular
> context?

IMHO it's more related to the network context and security requirements.

UDP is not valid for all the SIP scenarios (it is not valid for big
messages and it cannot provide security). If a client wants
"security", why should its equipment support and listen into UDP
transport?

Also let me some questions coming to my mind:

1) If a SIP phone implements both UDP and TCP, but allows the user to
disable UDP (so it no longer listens into a UDP socket), is that phone
"violating" RFC 3261 or not?

2) If a SIP domain announces DNS NAPTR records just including SCTP
transport or just SCTP and TCP, is it "violating" RFC 3261? Note that
RFC 3263 states that, when NAPTR records are present, those are the
options to reach the server.

> easier for them to omit support.

I understand your point in favour of interoperability. Maybe the
following usecase seems a bit ironic:

- A scenario in which *direct* interoperability with other SIP
transports won't take place (i.e. a SIP stack in JavaScript using
WebSocket transport, and whose SIP outbound proxy provides
interoperability with other SIP transports when required).

> For instance, I think we would probably still want to say that a transport
> supporting large messages must always be supported.

I agree.

Said that, I also consider that such a new document requires lot of
work and analysis (as you predicted). Otherwise it could become a
risk. So for now I would vote for the narrow way. IMHO nothing prevent
the broad way to take place latter.

Best regards.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Apr 2012 15:49:00 -0400

Partha,

IMO the main thing we learned about sips is that it was a bad idea.
I don't support making that mistake again.

	Thanks,
	Paul

On 4/21/12 10:55 PM, Ravindran, Parthasarathi wrote:
> Sal&  others,

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Apr 2012 16:10:12 -0400

> communicate with SIP entities other than their "official" SIP

A service such as you describe, where all the pieces are provided by a 
single provider, is a proprietary solution, even if it is built using 
public standards.

The more interesting case is when the service is more open, allowing 
differing clients, and maybe differing servers as well. That allows 
tradeoffs to be made.

For instance, maybe somebody wants to make a client for your service 
that can be used by prisoners in a prison. And then maybe there is a law 
forbidding encryption from being used. (And don't get all over me about 
the details of the example - it is just the first one that came to mind.)

> they are needed, as for example when receiving a NOTIFY with a

But the UA *may* register with multiple addresses. Or it can register 
with an fqdn that has entries for multiple transports.

But even if it only registers with one, which one to use could be 
decided at deployment time rather than at implementation time.

> waste of time to implement UDP transport.

I am certainly willing to have a debate of the pros and cons of this. 
Making support of UDP optional might help to phase it out.

> "violating" RFC 3261 or not?

This is a valid question to ask - 3261 isn't clear on what it means by 
"implement".

IMO its currently mandatory to implement but not mandatory to use, so 
its valid to allow disabling it.

> options to reach the server.

Again I am inclined to think mandatory to implement, optional to use. So 
as long as the NAPTR config is a deployment-time decision its ok.

> interoperability with other SIP transports when required).

ISTM that this is a good example of why relaxing the requirements in a 
careful way could still allow the sorts of interop we need. E.g. relax 
the requirements on UAs that connect using outbound.

> the broad way to take place latter.

I'm generally in favor of general approaches to things rather than 
narrow ones. But I can also see why people might not want to expend the 
time and effort to sort out all the issues of the general issue, and so 
do the narrow way for now. And certainly doing that doesn't preclude 
doing something broader later.

	Thanks,
	Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 23 Apr 2012 05:32:16 +0000

Paul,

Could you please explain your view of why SIPS URI is a mistake for TLS transport. I'm interested in knowing as apart from RFC 3261, Sec 3.1.4 of RFC 5630 (recent RFC) also recommends the usage of SIPS URI with TCP as a transport for TLS over TCP (http://tools.ietf.org/html/rfc5630#page-5) and there is an explicit statement in the same para

"This specification does not make use of the transport=tls parameter."

Thanks
Partha

>Sent: Monday, April 23, 2012 1:19 AM
>To: [email-masked]
>Subject: Re: [sipcore] Websocket is a new transport or new URI?
>
>Partha,
>
>> After reading lot of mails and thinking further, I agree with you that
>Websocket is an application protocol that is used as an transport for
>SIP. TLS is one another application protocol on top of TCP which was
>considered as transport (transport=tls) earlier and deprecated as part
>of RFC 3261 in Sec 26.2.2. TLS and Websocket has some unique behavior
>like hop-by-hop protocol rather than end-to-end.
>>
>> TLS is adopted within SIP using new URI namely SIPS with
>transport=tcp. In the same way, I'm proposing SIPWS which implies
>websocket over TCP, SIPWSS which implies websocket over TLS over TCP.
>Please let me know your opinion on the same.
>>
>> Thanks
>> Partha
>>
>>> Subject: Re: [sipcore] Stateless or Transaction stateful proxy
>>> possible in Websocket transport? [RE: Call for Adoption:
>>> draft-ibc-sipcore-sip- websocket-02]
>>>
>>> suggestion would be to consider *NOT* mandating SIP WebSocket clients
>>> to implement SIP UDP and TCP.
>>>>
>>> typical use-case for WebSocket is browser apps (eventhough a native
>>> app can of course also use WS).
>>>
>>>  From a pure WebSocket prospective, what you are going to define is
>>> SIP as a websocket sub-protocol that is transported on top of.
>>>
>>> interaction/translations that happens between the WebSocket server
>>> and the SIP proxy that are two different logical entities.
>>>
>>> my two cents
>>> Sal
>>>
>>> --
>>> Salvatore Loreto, PhD
>>> www.sloreto.com
>>>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 23 Apr 2012 09:48:17 +0200

> waste of time to implement UDP transport.

Big payloads are often associated with presence but IIRC there is a vendor who could not use UDP due to big payloads and it was just using SDP. An imaginary example: a video streaming service built with SIP: several video streams for different video qualities and profiles, several audio streams for the different languages and several chat streams for the subtitles in different languages. That could get big :-)

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 23 Apr 2012 09:53:22 +0200

2012/4/22 Paul Kyzivat <[email-masked]>:
> single provider, is a proprietary solution, even if it is built using public
> standards.
>
> For instance, maybe somebody wants to make a client for your service that
> can be used by prisoners in a prison. And then maybe there is a law
> forbidding encryption from being used. (And don't get all over me about the
> details of the example - it is just the first one that came to mind.)

The example is good :)

But it is still decision of the service provider whether to offer a
transport other than a secure one. This is, the provider could let
clients to use their own SIP clients but still require TLS-TCP as
unique transport. But in that case we are indeed talking about
service-agnostic SIP UA's that won't *use* some transports (UDP and
insecure TCP) at deployment time. So there was no reason to *build*
those SIP UA's with no support for those transports. Therefore I agree
with you.

> IMO its currently mandatory to implement but not mandatory to use, so its
> valid to allow disabling it.
>
>
> Again I am inclined to think mandatory to implement, optional to use. So as
> long as the NAPTR config is a deployment-time decision its ok.

After rethinking about those two questions I also consider that these
cases don't violate RFC 3261. And it is unlikely to mandate people to
*enable* all the mandatory-to-implement transports in any scenario.

> careful way could still allow the sorts of interop we need. E.g. relax the
> requirements on UAs that connect using outbound.

And I might add "...and the Outbound proxy/registrar server(s)
provides interoperability with UDP and TCP transports".

> I'm generally in favor of general approaches to things rather than narrow
> ones. But I can also see why people might not want to expend the time and
> effort to sort out all the issues of the general issue, and so do the narrow
> way for now. And certainly doing that doesn't preclude doing something
> broader later.

If in the future there was interest on the broad way (the separate
document updating RFC 3261) I would like to help.

Thanks a lot.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 23 Apr 2012 09:54:39 +0200

Hi Paul,

[snip]

> This is a valid question to ask - 3261 isn't clear on what it means by "implement".
> 
> IMO its currently mandatory to implement but not mandatory to use, so its valid to allow disabling it.
> 

That's my reading as well. Assuming that, how is disabling a transport different from not implementing it? One can claim to implement transport X but never allow you to use it. Is RFC-compliance the only difference?

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 23 Apr 2012 10:10:40 +0200

> That's my reading as well. Assuming that, how is disabling a transport different from not implementing it? One can claim to implement transport X but never allow you to use it. Is RFC-compliance th…

If you buy a phone of vendor XXX which announces UDP transport in its
specifications but there is no way to use it, then the vendor lied you
:)

IMHO the point here is about devices not designed for specific
environments, but for "any" environment, so theorically it's good that
they MUST implement basic SIP transports as a requirement for
announcing a "SIP compliant" label. Whether certain transports are
later used or not is a deployment decision which depends on each
scenario requirements and topology.

Regards.

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 23 Apr 2012 15:53:03 +0200

I am pretty sure we don't want to any new URI schemes for SIP we will however have to think about sow SIPS applies to websockets if at all.

Regards
Andy

> Sent: 22 April 2012 20:49
> To: [email-masked]
> > After reading lot of mails and thinking further, I agree with you
> that Websocket is an application protocol that is used as an transport
> for SIP. TLS is one another application protocol on top of TCP which
> was considered as transport (transport=tls) earlier and deprecated as
> part of RFC 3261 in Sec 26.2.2. TLS and Websocket has some unique
> behavior like hop-by-hop protocol rather than end-to-end.
> >
> possible
> SIP
> and

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2012 10:11:20 -0400

On 4/23/12 3:53 AM, Iñaki Baz Castillo wrote:
> 2012/4/22 Paul Kyzivat<[email-masked]>:

That's good! :)

> provides interoperability with UDP and TCP transports".

Yes. That is what I meant - relax requirement on the UA that supports 
outbound, but leave the requirement in place for the proxy/registrar.

> document updating RFC 3261) I would like to help.

Thanks. I'll keep that in mind.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2012 10:18:19 -0400

> That's my reading as well. Assuming that, how is disabling a transport different from not implementing it? One can claim to implement transport X but never allow you to use it. Is RFC-compliance th…

The difference is that the decision about use is put into the hands of 
the person deploying the equipment rather than the people writing the 
code that goes into the equipment. Then, if an interop problem arises 
due to the choices made during deployment, they can be fixed during 
deployment merely by reconfiguration. The conformance of the equipment 
the deployer already bought makes it possible to solve the problem 
without buying new equipment.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2012 10:29:32 -0400

>>>   rather than being required in certain contexts?

Note that I am largely playing devil's advocate on this particular issue.

> Big payloads are often associated with presence but IIRC there is a vendor who could not use UDP due to big payloads and it was just using SDP. An imaginary example: a video streaming service built…

The usual argument, which you seem to be making again, is that some 
vendor decides it only needs to support UDP because it doesn't 
anticipate being deployed in any situations where messages will exceed 
the PDU size. And the usual counter-argument is that it is nearly 
impossible to guarantee that this will always be the case, and hence the 
implementation MUST be prepared to use TCP.

Here we are arguing the flip side - someone arguing that it NEEDS TCP in 
all its deployments because it will have *some* big messages in every 
deployment, and hence sees no reason to implement UDP. I'm just arguing 
that some deployer might have a usage in mind where UDP *would* work all 
the time, and hence decide to deploy with only UDP configured.

Its a weak argument. But I can imagine someone making it. E.g. somebody 
might do so in order to optimize a benchmark.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2012 10:37:37 -0400

On 4/23/12 1:32 AM, Ravindran, Parthasarathi wrote:
> Paul,
>
> Could you please explain your view of why SIPS URI is a mistake for TLS transport.

My view is that the *intent* of sips was to provide the sort of 
"guarantee" of security that https provides. But sips doesn't provide 
that guarantee, because it isn't e2e and a variety of other things. The 
end result is that with sips you have very little more confidence that 
you are securely talking to who you think than if you use best effort by 
using TLS on your first hop. In essence, sips provides a false sense of 
security to the naive, but little more than that.

	Thanks,
	Paul

> I'm interested in knowing as apart from RFC 3261, Sec 3.1.4 of RFC 5630 (recent RFC) also recommends the usage of SIPS URI with TCP as a transport for TLS over TCP (http://tools.ietf.org/html/rfc5630#page-5) and there is an explicit statement in the same para
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 23 Apr 2012 16:56:25 +0200

> 
> The difference is that the decision about use is put into the hands of the person deploying the equipment rather than the people writing the code that goes into the equipment. Then, if an interop problem arises due to the choices made during deployment, they can be fixed during deployment merely by reconfiguration. The conformance of the equipment the deployer already bought makes it possible to solve the problem without buying new equipment.
> 

Thanks for clarifying.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 23 Apr 2012 17:10:34 +0200

Hi Paul,

> The usual argument, which you seem to be making again, is that some vendor decides it only needs to support UDP because it doesn't anticipate being deployed in any situations where messages will exceed the PDU size. And the usual counter-argument is that it is nearly impossible to guarantee that this will always be the case, and hence the implementation MUST be prepared to use TCP.
> 

I was trying to expose an example of the opposite :-) This vendor had to disable UDP support because their SDPs were really huge.

> Here we are arguing the flip side - someone arguing that it NEEDS TCP in all its deployments because it will have *some* big messages in every deployment, and hence sees no reason to implement UDP. I'm just arguing that some deployer might have a usage in mind where UDP *would* work all the time, and hence decide to deploy with only UDP configured.
> 
> Its a weak argument. But I can imagine someone making it. E.g. somebody might do so in order to optimize a benchmark.
> 

Sure, UDP-only deployments might be possible.

It seems like allowing for implementors to disable transports completely (or not even implement them) could open the can of worms, but at the same time one could find that limiting in certain environments. I don't even have a clear opinion on what would be best here :-S

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2012 11:19:28 -0400

> I was trying to expose an example of the opposite :-) This vendor had to disable UDP support because their SDPs were really huge.

It should not be necessary to disable UDP because messages sometimes get 
big. As long as both are supported the proper one can be used based on 
message size. Of course there are some cases where that won't work - 
e.g. an offerless invite sent via UDP, leading to the need to send an 
offer in a reply.

I suppose that in practice restricting use to TCP would avoid a number 
of nasty issues.

> It seems like allowing for implementors to disable transports completely (or not even implement them) could open the can of worms, but at the same time one could find that limiting in certain envir…

That is why we are discussing it. :)

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 23 Apr 2012 10:36:37 -0500

On 04/23/2012 10:19 AM, Paul Kyzivat wrote:
>>>> Big payloads are often associated with presence but IIRC there is a
>>>> vendor who could not use UDP due to big payloads and it was just
>>>> using SDP. An imaginary example: a video streaming service built
>>>> with SIP: several video streams for different video qualities and
>>>> profiles, several audio streams for the different languages and
>>>> several chat streams for the subtitles in different languages. That
>>>> could get big :-)
>>>
>>> anticipate being deployed in any situations where messages will
>>> exceed the PDU size. And the usual counter-argument is that it is
>>> nearly impossible to guarantee that this will always be the case, and
>>> hence the implementation MUST be prepared to use TCP.
>>>
>>
>> I was trying to expose an example of the opposite :-) This vendor had
>> to disable UDP support because their SDPs were really huge.
>

Wasn't that the purpose of RFC 3261 mandating support for both though? 
The same could happen in a SUBSCRIBE dialog; the SUBSCRIBE request and 
200 OK reply could be sent over UDP, but the first NOTIFY may have to be 
sent over TCP due to its size.

I think I'm in agreement with your 'narrow' approach, because it allows 
the relaxation to be applied only in cases where an alternate 'large 
message' transport (other than TCP or TLS/TCP) is being made available. 
Granted, Asterisk survived for many years only supporting UDP, and it 
was rare that a user ran into an problem due to message sizes, but with 
SDPs growing (ICE support is on the way) and complex presence data being 
transferred, it's clear that some sort of large message transport needs 
to be supported too.

---

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

2012/4/23 Paul Kyzivat <[email-masked]>:
> message size. Of course there are some cases where that won't work - e.g. an
> offerless invite sent via UDP, leading to the need to send an offer in a
> reply.

Hi Paul, that sounds a bit "theorical" for me. SIP phones usually
perform a single registration using a single transport and binding a
single Contact URI with same transport than the one used for sending
the REGISTER.

Indeed a SIP UA could register two URIs (one with ;transport=udp and
the other one with tcp), but then it would generate useless parallel
forking for initial incoming-requests (and lot of merged requests and
482 responses from the UA). Well, the UA could set different "q"
values and give more priority to the UDP binding, so the registrar
would just use TCP if sending the request over UDP fails (internal
503). However that would not work for in-dialog requests since the
RURI already indicates the transport.

IMHO this would be more feasible in the case of proxy to proxy
communication, in which proxy A could decide (based on request size)
whether to select one or other transport regardless the priority of
the NAPTR records, or selecting TCP regarless the RURI has an IP and
no ;transport=tcp param.

But honestly, in the UA side I don't expect that dynamic selection of
the transport could work in "real" scenarios (maybe I'm wrong).

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Apr 2012 11:45:11 +0200

Hi,

>> It should not be necessary to disable UDP because messages sometimes 
>> get big. As long as both are supported the proper one can be used 
>> based on message size. Of course there are some cases where that won't 
>> work - e.g. an offerless invite sent via UDP, leading to the need to 
>> send an offer in a reply.
>
> Hi Paul, that sounds a bit "theorical" for me. SIP phones usually perform a single registration using a single transport and binding a single Contact URI with same transport than the one used for sending the REGISTER.
>
> Indeed a SIP UA could register two URIs (one with ;transport=udp and the other one with tcp), but then it would generate useless parallel forking for initial incoming-requests (and lot of merged requests and
> values and give more priority to the UDP binding, so the registrar would just use TCP if sending the request over UDP fails (internal 503). However that would not work for in-dialog requests since the RURI already indicates the transport.

A well implemented registrar could use serial forking in this case. But, as you say, if the registrations use different route sets, you can't switch from one to another mid-session. In reality, however, the INVITE request/response is going to be the largest request within a dialog (unless you e.g. use an Info-Package with a large content).

But, even if a UA registers both using TCP, if there are proxies between the UA and the registrar I don't think it can be guaranteed that there will be TCP all the way (similar issue as for transport=tls). Or, is there a rule saying that a proxy must not downgrade from TCP to UDP?

> IMHO this would be more feasible in the case of proxy to proxy communication, in which proxy A could decide (based on request size) whether to select one or other transport regardless the priority of the NAPTR records, or selecting TCP regarless the 
> RURI has an IP and no ;transport=tcp param.
>
> But honestly, in the UA side I don't expect that dynamic selection of the transport could work in "real" scenarios (maybe I'm wrong).

I agree. Proxy-to-proxy is not a problem.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 24 Apr 2012 12:07:05 +0200

> A well implemented registrar could use serial forking in this case. But, as you say, if the registrations use different route sets, you can't switch from one to another mid-session. In reality, how…

But take also into account that a re-INVITE could be bigger than an
initial INVITE due to Route headers, and typically the RURI in a
re-INVITE maps to a specific IP:port and transport.

> But, even if a UA registers both using TCP, if there are proxies between the UA and the registrar I don't think it can be guaranteed that there will be TCP all the way (similar issue as for transpo…

Is not. But as said before, I expect that changing to TCP in case of a
big message is easier in proxy-to-proxy communication. The real
problem I see is when a UA uses UDP for common stuf (registration and
so).

BTW I don't think we should care too much about this irresolvable
problem. Instead let's encourage TCP transport in new deployments
regardless UDP "might" be valid.

Regards.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 24 Apr 2012 12:04:44 +0000

Paul,

Thanks for clarify your view. In case your view is correct, then Usage of SIPS Scheme (Sec 9.2) of draft-ibc-sipcore-sip-websocket-02 draft should forbid the usage of SIPS URI for websocket transport (WSS, WS) as SIPS URI is mistake for TLS, the mistake *MUST NOT* be repeated and the draft text has to be updated as

"SIPS URI MUST NOT be used for WS, WSS transport as the end-to-end security is not assured"

Please let me know your opinion on the above recommendation. I added the exact current text of the draft as a note of this mail for your reference.

Thanks
Partha

Note: Current text of draft-ibc-sipcore-sip-websocket-02

9.2.  Usage of SIPS Scheme

   SIPS scheme within a SIP request dictates that the entire request
   path to the target be secured.  If such a path includes a WebSocket
   node it MUST be a secure WebSocket connection. 

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: Monday, April 23, 2012 8:08 PM
>> I'm interested in knowing as apart from RFC 3261, Sec 3.1.4 of RFC
>> 5630 (recent RFC) also recommends the usage of SIPS URI with TCP as a
>> transport for TLS over TCP (http://tools.ietf.org/html/rfc5630#page-5)
>> and there is an explicit statement in the same para
>>
>>> considered as transport (transport=tls) earlier and deprecated as
>>>>> suggestion would be to consider *NOT* mandating SIP WebSocket
>>>>> clients to implement SIP UDP and TCP.
>>>>>>
>>>>>   From a pure WebSocket prospective, what you are going to define
>>>>> is SIP as a websocket sub-protocol that is transported on top of.
>>>>>
>>>>> The important thing to standardize from a SIPCore prospective is
>>>>> the interaction/translations that happens between the WebSocket
>>>>> server and the SIP proxy that are two different logical entities.
>>>>>
>>>>> my two cents
>>>>> Sal
>>>>>
>>>>> --
>>>>> Salvatore Loreto, PhD
>>>>> www.sloreto.com
>>>>>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Apr 2012 07:28:46 -0500

> "SIPS URI MUST NOT be used for WS, WSS transport as the end-to-end security is not assured"

How did you reach this conclusion? In this context, 
WebSocket-over-TLS-over-TCP is no different than TLS-over-TCP; usage of 
WebSocket on the first hop does not change the ability of the path to be 
end-to-end secure at all.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 24 Apr 2012 12:34:45 +0000

Kevin,

Please look into earlier mail of Paul's view on SIPS URI that SIPS URI (TLS over TCP) is not end-to-end (http://www.ietf.org/mail-archive/web/sipcore/current/msg04870.html).

I asked the subsequent question to Paul based on his view on SIPS URI. Hope this clarifies how I come to the below conclusion.

Thanks
Partha

>Behalf Of Kevin P. Fleming
>Sent: Tuesday, April 24, 2012 5:59 PM
>To: [email-masked]
>> Thanks for clarify your view. In case your view is correct, then Usage
>> of SIPS Scheme (Sec 9.2) of draft-ibc-sipcore-sip-websocket-02 draft
>> should forbid the usage of SIPS URI for websocket transport (WSS, WS)
>> as SIPS URI is mistake for TLS, the mistake *MUST NOT* be repeated and
>> the draft text has to be updated as
>>
>How did you reach this conclusion? In this context, WebSocket-over-TLS-
>over-TCP is no different than TLS-over-TCP; usage of WebSocket on the
>first hop does not change the ability of the path to be end-to-end
>secure at all.
>
>--
>Kevin P. Fleming
>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at
>www.digium.com & www.asterisk.org

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Apr 2012 07:44:18 -0500

> I asked the subsequent question to Paul based on his view on SIPS URI. Hope this clarifies how I come to the below conclusion.

His point was that SIPS itself has design flaws. Usage of WebSocket 
instead of TLS doesn't change that, and there's no reason that the 
WebSocket protocol specification should disallow usage of SIPS URIs over 
WebSocket connections. If an implementor wishes to use SIPS URIs and 
understands the consequences, they should be free to use them.

If you feel that *nobody* should use SIPS URIs under any circumstances 
(whether the transport is TLS, WebSocket, DTLS-SCTP or any other), then 
that's a totally different issue and should be addressed in a separate 
I-D that updates RFC3261.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 24 Apr 2012 13:18:13 +0000

Kevin,

Could you please let me know whether you agree that SIPS URI usage in Websocket over TLS over TCP (new design) has design flaw as TLS over TCP?  Please note that the issue is not to implementer but the (SIPS) information mislead the user. 

I'm not asking to forbid SIPS for all transport but atleast, SIPS MUST NOT be permitted for all the new transport which will be introduced in SIP in case it accepted as a known design flaw.

OTOH, I proposed to use new SIPWSS URI which shall indicate explicitly that first hop is secured by this mechanism.

Thanks
Partha

>Sent: Tuesday, April 24, 2012 6:14 PM
>Cc: [email-masked]
>> Please look into earlier mail of Paul's view on SIPS URI that SIPS URI
>(TLS over TCP) is not end-to-end (http://www.ietf.org/mail-
>archive/web/sipcore/current/msg04870.html).
>>
>> I asked the subsequent question to Paul based on his view on SIPS URI.
>Hope this clarifies how I come to the below conclusion.
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Apr 2012 08:24:18 -0500

> I'm not asking to forbid SIPS for all transport but atleast, SIPS MUST NOT be permitted for all the new transport which will be introduced in SIP in case it accepted as a known design flaw.

The 'design flaws' that have been discussed for SIPS URIs have nothing 
at all to do with the transport mechanism that is chosen. If WebSocket 
as a transport was unable to provide an appropriate level of security to 
meet the SIPS URI requirements/expectations, then I'd agree that the 
WebSocket transport specification should disallow usage of WebSocket for 
SIPS Request URIs. However, that is not the case: WebSocket provides 
nearly identical security properties to those provided by TLS.

Given that, there is no reason to disallow usage of WebSocket for SIPS 
URIs, unless TLS is also going to be disallowed. Just like the previous 
discussion about Path and Outbound, these are implementation choices 
that should be left up to the implementor. Usage of SIPS URIs over 
WebSocket transport is not fundamentally broken, any more than it is 
fundamentally broken on any other secure transport.

If the WG wants to make a statement about usage of SIPS URIs, then it 
should be done directly, for all transports, not just for WebSocket.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Apr 2012 15:35:51 -0400

> end-to-end secure at all.

It may be that WebSocket-over-TLS-over-TCP is *conceptually* no 
different than TLS-over-TCP. But its far from clear that this is so with 
the current wording of 3261 and 5630. I expect that a careful review of 
these needs to be done and some normative updates done. I went through 
3261 looking at discussions of sips for things that might be problematic 
or at least need some consideration. Here are some of them:

    Any
    implementation that supports TLS MUST support the SIPS URI scheme.
    The To header field allows for a display name.

    If the request arrived over TLS, and the Request-URI contained a SIPS
    URI, the "secure" flag is set to TRUE.

    If the request was sent over TLS, and the Request-URI contained a
    SIPS URI, the "secure" flag is set to TRUE.

    Furthermore, if the Request-URI contains a SIPS URI, TLS MUST
    be used to communicate with that proxy.

    For a SIPS URI, the transport parameter MUST
    indicate a reliable transport.

    When a request is sent to a SIPS URI, the
    protocol still indicates "SIP", and the transport protocol is TLS.

    When used as the Request-URI of a
    request, the SIPS scheme signifies that each hop over which the
    request is forwarded, until the request reaches the SIP entity
    responsible for the domain portion of the Request-URI, must be
    secured with TLS

    The use of SIPS in particular entails that mutual TLS authentication
    SHOULD be employed, as SHOULD the ciphersuite
    TLS_RSA_WITH_AES_128_CBC_SHA.

    and thus "sips:[email-masked];transport=tcp" and

    All SIP elements that support TLS MUST also support the SIPS URI
    scheme.

I'm not suggesting exactly *what* needs to be done - just that it needs 
to be figured out.

As a consequence, I would expect that it would be possible to use sips 
with websockets, but no requirement to do so. Whether its helpful, or 
wise, to use sips is a separate question.

	Thanks,
	Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 25 Apr 2012 09:18:02 +0000

Paul,

As you mentioned, it is possible to use SIPS URI even for the new 
transport like websocket with some normative changes and those 
changes needs to be figured out. As a result, SIPS URI is not going
to be mistake in the new transport as well.

My intent of this mail is to make consistent mechanism for all SIP 
application layer transport protocol over TCP. "Websocket 
over TCP" is same like "TLS over TCP" and has some of similar 
behavior like

1) Hop by hop behavior. 
2) Running on top of TCP transport
3) No port management

This mechanism has other added advantages like even if extension 
of websocket for new transport like SCTP will not impact SIP mechanism.
In case SIPWS URI looks like

    sipws:[email-masked];transport=tcp

As a theory, if websocket is extended for SCTP transport and then 
SIPWS URI will looks like

    sipws:[email-masked];transport=sctp

Please note that TLS over SCTP exists already as RFC3436. 

As we discussed, there was debate in RFC 3261 whether TLS is a transport 
or URI in SIP, it was decided as URI mechanism, TLS transport is 
deprecated and also there is no plan to change this stance as per 
this mail thread. So IMO, it is more appropriate to define new URI 
scheme like SIPWS rather than defining websocket as a transport. 
Please let me know your opinion on the same.

Thanks
Partha

>Sent: Wednesday, April 25, 2012 1:06 AM
>To: [email-masked]
>>> Thanks for clarify your view. In case your view is correct, then
>>> Usage of SIPS Scheme (Sec 9.2) of draft-ibc-sipcore-sip-websocket-02
>>> draft should forbid the usage of SIPS URI for websocket transport
>>> (WSS, WS) as SIPS URI is mistake for TLS, the mistake *MUST NOT* be
>>> repeated and the draft text has to be updated as
>>>
>> WebSocket-over-TLS-over-TCP is no different than TLS-over-TCP; usage
>> of WebSocket on the first hop does not change the ability of the path
>> to be end-to-end secure at all.
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 Apr 2012 12:36:33 +0200

Partha,

> over TCP" is same like "TLS over TCP" and has some of similar 

Can you elaborate on what consistent mechanism is needed and why?

>    sipws:[email-masked];transport=tcp

So, what does this mean, that we need to reach alice through a WebSocket connection? Should alice be able to register using such contact?

> Please let me know your opinion on the same.

What should we do if tomorrow I send a draft specifying pseudo-TCP transport (TCP implemented over UDP) for SIP? Yet another URI scheme? Not to mention that all equipment out there would go nuts os most likely just ignore URI schemes which are not 'sip' or 'sips'.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Apr 2012 10:55:02 -0400

I agree with Saúl here. I don't really understand what it is that Partha 
is proposing.

As I already stated, I think sips turned out to be a mistake - that it 
doesn't provide enough of a guarantee to be able to promise anything to 
an end user. But we investigated this ad nauseum and couldn't come up 
with anything substantially better.

So I'm ok to extend the applicability of sips to other transports that 
can provide at least as much security as TLS over TCP provides, for 
those that find that to be of *some* utility.

	Thanks,
	Paul

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 25 Apr 2012 09:37:07 -0600

Jeez, with all due respect, I've been following these hundreds of messages
that seem to be necessary to add support for Websocket as a transport.

Is this really what the original developers intended when they made the
statement that SIP is transport independent?  Doesn't seem very independent
to me.  In my mind independent to me means I switch from SOCK_DGRAM or
SOCK_STREAM to SOCK_WEBSOCKET (or whatever) in my socket() call and I'm
done.

FM

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Wednesday, April 25, 2012 8:55 AM
To: Saúl Ibarra Corretgé
Cc: Ravindran, Parthasarathi; [email-masked]
Subject: Re: [sipcore] Websocket is a new transport or new URI?

I agree with Saúl here. I don't really understand what it is that Partha is
proposing.

As I already stated, I think sips turned out to be a mistake - that it
doesn't provide enough of a guarantee to be able to promise anything to an
end user. But we investigated this ad nauseum and couldn't come up with
anything substantially better.

So I'm ok to extend the applicability of sips to other transports that can
provide at least as much security as TLS over TCP provides, for those that
find that to be of *some* utility.

	Thanks,
	Paul

On 4/25/12 6:36 AM, Saúl Ibarra Corretgé wrote:
>> application layer transport protocol over TCP. "Websocket over TCP" 
>> is same like "TLS over TCP" and has some of similar behavior like
>>
>
>> This mechanism has other added advantages like even if extension of 
>> websocket for new transport like SCTP will not impact SIP mechanism.
> So, what does this mean, that we need to reach alice through a WebSocket
connection? Should alice be able to register using such contact?
>> As we discussed, there was debate in RFC 3261 whether TLS is a 
>> transport or URI in SIP, it was decided as URI mechanism, TLS 
>> transport is deprecated and also there is no plan to change this 
>> stance as per this mail thread. So IMO, it is more appropriate to 
>> define new URI scheme like SIPWS rather than defining websocket as a
transport.
> What should we do if tomorrow I send a draft specifying pseudo-TCP
transport (TCP implemented over UDP) for SIP? Yet another URI scheme? Not to
mention that all equipment out there would go nuts os most likely just
ignore URI schemes which are not 'sip' or 'sips'.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 25 Apr 2012 11:09:59 -0500

> with anything substantially better.

Time for institutional memory, perhaps?  The long discussions (May -
June 2006) on why sips failed and ideas to come up with new URI schemes
to replace it and attendant problems (upcasting URIs, downcasting URIs
without user consent, hop-by-hop semantics versus end-to-end, etc.) is
summarized in
http://www.ietf.org/mail-archive/web/sip/current/msg24047.html

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Apr 2012 12:38:36 -0400

Vijay,

Thanks for this reference! Its one thing to have a recollection of a 
discussion long ago, but something else to have the minutes of that 
discussion!

	Thanks,
	Paul

---

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

Hi Partha,

2012/4/25 Ravindran, Parthasarathi <[email-masked]>:
> So IMO, it is more appropriate to define new URI

The SIP transport defined by this draft is WebSocket, instead of TCP.
WebSocket (RFC 6455) is defined to work on top of TCP but, even if a
future spec defines WebSocket to run over SCTP, the SIP transport
would still be "WebSocket" (or perhaps "WebSocket-SCTP" but that
something in which I won't waste time now given the fact that RFC 6455
*mandates* TCP layer-3 transport and does not leave the door open for
other layer-3 transports).

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.

You can find lot of 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. A "transport" does not necessarily
mean "layer 3 network transport".

About SIPS, the last S in SIPS stands for "secure" regardless of the
undelying SIP transport used. AFAIK it does not necessarily mean
"TLS". Take for example draft-jennings-sip-dtls-05 [1] which defines
SIP over DTLS over UDP. The draf is expired, but anyhow, it defines a
secure SIP transport which does not use TLS but DTLS (which is similar
but NOT the same). The draft also allows SIPS messages through DTLS
over UDP.

[1] http://tools.ietf.org/html/draft-jennings-sip-dtls-05

When a SIPS message is carried on top of a secure WebSocket connection
(which means SIP over WebSocket over TLS over TCP) the security level
is basically the same as if it was SIP over TLS over TCP. Therefore I
consider that a secure WebSocket connection fits the requirements of
the SIPS mechanism, thus secure WebSocket should be considered as a
secure SIP transport.

About the SIPWS and SIPWSS schemas you propose, don't take me wrong
but I consider that the worst possible idea. First of all because I
don't agree with your rationale (I insist that, from the point of view
of a SIP stack, WebSocket is the ***SIP transport***, instead of TCP).
Secondly, because adding new URI schemas would just break the existing
SIP world (there are still some SIP entities that don't understand
SIPS schema and you are proposing two new ones?).

Thanks a lot for your comments.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Apr 2012 22:17:34 +0200

Hi,

I agree with Inaki.

Whatever "layer" we consider the WebSocket to be, in my opinion the URI scheme is used for addressing (either as an AOR or a contact), and should be independent of the transport.

For what would the new scheme be needed  anyway?

Regards,

Christer

Sent: Wednesday, April 25, 2012 8:25 PM

Hi Partha,

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 26 Apr 2012 01:45:51 +0000

Vijay,

Thanks for forwarding the fruitful information. Now I understand why Paul
is saying that SIPS URI is a mistake in RFC 3261. The point to be noted is 
that there is no IETF document to clarify this.

Hi all,

I agree that it is better to proceed websokcet as a transport rather than 
new URI to avoid earlier mistake now.

SIPS is not deprecated for TLS over TCP as it is widely deployed.
Having said that, I'm not fully convinced with SIPS usage for websocket
as IMO, it is extending the mistake to the new transport as well. Knowing
that it is a mistake in the base RFC 3261, it is not the right thing to be 
allowed for new transport introduced. Let us discuss this open item in 
this thread or other thread.

>From the TCP/IP protocol stack perspective, TLS as URI and WebSocket 
as transport is not the right thing as it is confusing as follows.

     sips:[email-masked];transport=ws

The better approach will be 

    sip:[email-masked];transport=wss

Thanks
Partha

>From: Vijay K. Gurbani [mailto:[email-masked]]
>Sent: Wednesday, April 25, 2012 9:40 PM
>To: Paul Kyzivat
>Cc: Saúl Ibarra Corretgé; Ravindran, Parthasarathi; [email-masked]
>> I agree with Saúl here. I don't really understand what it is that
>> Partha is proposing.
>>
>> doesn't provide enough of a guarantee to be able to promise anything
>> to an end user. But we investigated this ad nauseum and couldn't come
>> up with anything substantially better.
>
>summarized in http://www.ietf.org/mail-
>archive/web/sip/current/msg24047.html
>
>- vijay
>--

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 26 Apr 2012 08:52:22 +0000

Hi Christer,

When I argued for new URI, the contact shall use new URI with 
the existing TCP transport like

"sipws" URI shall be compare with "ws" URI in Websocket protocol 
(Sec 3 of RFC 6455). 

Thanks
Partha

>Sent: Thursday, April 26, 2012 1:48 AM
>Subject: RE: [sipcore] Websocket is a new transport or new URI?
>
>Hi,
>
>I agree with Inaki.
>
>Whatever "layer" we consider the WebSocket to be, in my opinion the URI
>scheme is used for addressing (either as an AOR or a contact), and
>should be independent of the transport.
>
>> So IMO, it is more appropriate to define new URI scheme like SIPWS
>> rather than defining websocket as a transport.
>
>
>future spec defines WebSocket to run over SCTP, the SIP transport would
>still be "WebSocket" (or perhaps "WebSocket-SCTP" but that something in
>which I won't waste time now given the fact that RFC 6455
>(or discussed) SCTP-over-DTLS-over-ICE-over-UDP as the transport for the
>WebRTC Data-Channel mechanism. A "transport" does not necessarily mean
>"layer 3 network transport".
>
>
>
>undelying SIP transport used. AFAIK it does not necessarily mean "TLS".
>Take for example draft-jennings-sip-dtls-05 [1] which defines SIP over
>DTLS over UDP. The draf is expired, but anyhow, it defines a secure SIP
>transport which does not use TLS but DTLS (which is similar but NOT the
>same). The draft also allows SIPS messages through DTLS over UDP.
>
>(which means SIP over WebSocket over TLS over TCP) the security level is
>basically the same as if it was SIP over TLS over TCP. Therefore I
>consider that a secure WebSocket connection fits the requirements of the
>SIPS mechanism, thus secure WebSocket should be considered as a secure
>SIP transport.
>
>
>
>About the SIPWS and SIPWSS schemas you propose, don't take me wrong but
>I consider that the worst possible idea. First of all because I don't
>agree with your rationale (I insist that, from the point of view of a
>SIP stack, WebSocket is the ***SIP transport***, instead of TCP).
>SIP world (there are still some SIP entities that don't understand SIPS
>schema and you are proposing two new ones?).
>
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 26 Apr 2012 12:25:41 +0200

I thought RFC 5630 went a long way to explaining exactly what you got when you specified SIPS.

It is up to the reader to work out how useful it is as a result - not exactly a great leap.

Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: 26 April 2012 02:46
To: Gurbani, Vijay K (Vijay); Paul Kyzivat; Iñaki Baz Castillo
Cc: [email-masked]; Saúl Ibarra Corretgé
Subject: Re: [sipcore] Websocket is a new transport or new URI?

Vijay,

Hi all,

Thanks
Partha

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sat, 28 Apr 2012 02:22:49 +0000

Paul,

I prefer narrow way as I doubt whether it is possible to generalize in relaxing the transport. But the narrow way has to consider the side effect of the relaxing  of "UDP, TCP" transport mandate normative statement. Sec 7 of RFC 5630 provides those considerations for SIP usage & TLS transport. The main consideration which I'm thinking for websocket as a transport as of now are record-route, path handling in websocket.

Thanks
Partha

>Sent: Sunday, April 22, 2012 8:32 AM
>To: 'Paul Kyzivat'; [email-masked]
>Subject: RE: [sipcore] Should we change mandatory-to-implement
>transports?
>
>Paul,
>
>Even before relaxing the transport criteria, let us discuss whether
>websocket is a new transport or new URI as the similar discussion
>happens for TLS as a transport over TCP in Sec 26.2.2. I have initiated
>the new thread with the proposal of using websocket as a new URI (SIPWS,
>SIPWSS). I'll get back to this thread in case folks proves websocket as
>a transport.
>
>Thanks
>Partha
>
>>harder to pass. My main concern is that it has to potential to erect
>>new barriers to interoperability. The point of having some
>>must-implement transports is to ensure some common basis for interop.
>>This has the potential to lose that. I am myself uncertain if I would
>>support such a change. This would depend on some very careful analysis.
>>
>>I can't promise that the chairs or the AD will even approve of the
>>broad approach.
>>
>>Given all of that, I would like to have some discussion of which way
>>the group would like to go. Please do more that vote - actually make
>>the case for why you want to go the way you do.
>>
>>	Thanks,
>>	Paul [as co-chair]
>>
>>> so they cannot receive requests via a different transport than the
>>> one they use to connect to their Outbound proxy).
>>>

---

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

On 4/18/12 5:24 PM, Iñaki Baz Castillo wrote:
> 2012/4/18 Salvatore Loreto<[email-masked]>:
I understand clearly your point, but perhaps I wasn't able to express so 
good mine.
Once more: I could use your argument with almost all the protocols and say
for example XMPP (just s/XMPP/SIP in your above text):

    when a XMPP message/arrives to the WebSocket listening server, the
    application
    on top of it (a SIP proxy/UAS) should extract the SIP message from
    the XMPP message,
    parse it and process it in the same way that is the SIP message
    message arrived via another
    SIP transport.

BTW: "SIP transport" is also an interesting definition, indeed WebSocket 
is not a transport protocol
but can be used to transport SIP message as well as other stuff.

I would hear the opinion of the Chairs about this,
if they are OK to define (and talk in this draft of) WebSocket I will 
shut up!
Chairs?

> the WebSocket server and the SIP proxy".
So honestly I don't buy your explanation.

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 28 Apr 2012 20:08:38 +0300

> TCP. Such an exemption could be included in the websocket transport draft.

I would go for the narrow, at least from a WebSocket prospective.

 From a WebSocket point of view,
what we are defining in SIPCore is ***SIP as a WebSocket subprotocol***
indeed we are going also to register into IANA a value for it.

If we take this approach, everything will become simpler.

my 2 cents

/Sal

> (I guess there is a third way - to do*nothing*  about the

---

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

2012/4/28 Salvatore Loreto <[email-masked]>:
> BTW: "SIP transport" is also an interesting definition, indeed WebSocket is
> not a transport protocol
> if they are OK to define (and talk in this draft of) WebSocket I will shut
> up!
> Chairs?

Hi Salvatore, I expect that this subject has been already taked into
account by chairs since they declared (after IETF 83) a new SIPCORE WG
milestone:

  Apr 2013  WebSockets transport definition for SIP to the IESG
(proposed standard)

:)

> So honestly I don't buy your explanation.

Without more arguments I cannot give a better explanation. However I
would like to clarify that this is not about having a Apache web
server with "mod_websocket" enabled, and passing SIP messages received
via the WebSocket connection to a "real" SIP proxy using some
proprietary/custom communication. This is not what this specification
attempts to achieve.

The draft states (in "Definitions" section):

So, this SIP entity includes a WebSocket server for SIP-over-WebSocket
in the same way it includes a TCP server for SIP-over-TCP or a UDP
socket for SIP-over-UDP. And therefore the SIP entity and the
WebSocket server are not two logical independent entities (not when we
are speaking about a "SIP WebSocket Client" or a "SIP WebSocket
Server"). This is what the draft talks about, and not about
communication between WebSocket servers and SIP entities.

Best regards.

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