Subject: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 23 Aug 2012 18:23:18 +0530

Hi all,

As I discussed during IETF-84 meeting,  the following text is provided for
the starting the discussion on deviation of RFC 3261 mandatory to implement
(UDP/TCP) transport in this draft. 

"In case SIP WebSocket Client is a web browser and SIP Websocket Server is a
SIP proxy, then record-route header MUST be included by SIP Websocket server
in all SIP messages. This requirement assures that SIP WebSocket Client is
able to contact with UAS through SIP Websocket Server during the mid-dialog
irrespective of the contact SIP URI received from UAS "

The above normative statement will be update to  RFC 3261.

Thanks

Partha

---

From: José Luis Millán <[email-masked]>
Date: Thu, 23 Aug 2012 18:15:49 +0200

Hi,

2012/8/23 Parthasarathi R <[email-masked]>

>  Hi all,****
> ** **
> (UDP/TCP) transport in this draft. ****
>
> ** **
>
> “In case SIP WebSocket Client is a web browser and SIP Websocket Server is
> a SIP proxy, then record-route header MUST be included by SIP Websocket
> server in all SIP messages. This requirement assures that SIP WebSocket
> Client is able to contact with UAS through SIP Websocket Server during the
> mid-dialog irrespective of the contact SIP URI received from UAS ”
>

Record-Route header field is useful for a proxy in order to remain in the
dialog path. It is not necessary for all SIP messages. This is defined in
RFC 3261 as 'loose routing' and draft-ibc-sipcore-sip-websocket-02 does not
change it at all.

Section 2 of Apendix A (Implementation guidelines) already mentions it:

"
 The proxy performs Loose Routing and remains in dialogs path as

   specified in [RFC3261 <http://tools.ietf.org/html/rfc3261>].
Otherwise in-dialog requests would fail
   since SIP WebSocket Clients make use of their SIP WebSocket Server in
   order to send and receive SIP requests and responses.

"

Regards,

>  **
>
> The above normative statement will be update to  RFC 3261.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Aug 2012 21:52:05 +0530

Hi Jose,

Let us assume draft-ibc-sipcore-sip-websocket-02 does not change proxy
behavior in SIP websocket server then

the dialog creation in the following topology breaks as follows:

Topolgy:

  UAC SIP Websocket client (Browser)------Proxy SIP Websocket
Server------UAS (RFC 3261 UA) 

Callflow steps:

1)    UAC SIP Websocket client initiates INVITE dialog towards SIP Websocket
server

2)    INVITE is forwarded towards UAS by SIP Websocket server

3)    UAS receives INVITE and sent 200 OK response with contact address with
UDP transport

towards SIP Websocket server

4)    SIP Websocket server forwards 200 OK towards SIP Websocket client
without record-route

5)    Whether SIP Websocket Client(browser) will be able to send ACK towards
UAS contact

       address in UDP transport? No.

In case normal RFC 3261 application or application based on SIP websocket
client, ACK will send towards 

UAS contact address with UDP transport as per mandatory to implement
transport mechanism in RFC 3261. 

As browser acting as SIP Websocket client violates the mandatory to
implement transport mechanism,

the callflow breaks in this specification. 

In case you wish to put some other text, Please let us discuss.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of José Luis Millán
Sent: Thursday, August 23, 2012 9:46 PM
To: Parthasarathi R
Cc: [email-masked]
Subject: Re: [sipcore] Mandatory to implement transport comment on
draft-ibc-sipcore-sip-websocket-02

Hi,

Hi all,

“In case SIP WebSocket Client is a web browser and SIP Websocket Server is a
SIP proxy, then record-route header MUST be included by SIP Websocket server
in all SIP messages. This requirement assures that SIP WebSocket Client is
able to contact with UAS through SIP Websocket Server during the mid-dialog
irrespective of the contact SIP URI received from UAS ”

"

   specified in [RFC3261 <http://tools.ietf.org/html/rfc3261> ].  Otherwise
in-dialog requests would fail
   since SIP WebSocket Clients make use of their SIP WebSocket Server in
   order to send and receive SIP requests and responses.

"

Regards,

Thanks

Partha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 24 Aug 2012 18:39:12 +0200

> the callflow breaks in this specification.

Hi Partha. As said many times this draft is not *just* about web
browsers. Please imagine that new versions of iOS and Android come
with a WebSocket Client stack (so native apps can use it). Should we
also add them to the draft?:

“In case SIP WebSocket Client is a web browser or a native iOS or
Android application, and SIP Websocket Server is a SIP proxy, then..."

Ugly, agree?

Anyhow, for the case of a web browser (which indeed cannot send a UDP
datagram) the draft already describes a full guideline in the Appendix
section:

http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02#appendix-A

IMHO that's enough. The mandatory sections of the draft should not
focus just on web browsers.

BTW your text is incomplete:

“In case SIP WebSocket Client is a web browser and SIP Websocket
Server is a SIP proxy, then record-route header MUST be included by
SIP Websocket server in all SIP messages. This requirement assures
that SIP WebSocket Client is able to contact with UAS through SIP
Websocket Server during the mid-dialog irrespective of the contact SIP
URI received from UAS ”

That's not enough. If you want to also *receive* incoming requests you
need to mandate Outbound RFC 5626 (since the proxy cannot establish a
WebSocket connection with a web browser). But we don't want to mandate
Outbound (it was discussed and voted in Paris) since the draft just
describes a SIP transport and does not assume specific topologies or
UA devices.

IMHO the Appendix guideline (which was already discussed in this WG)
is the appropriate section for talking about specific common
scenarios. The draft should not "update" RFC 3261 just for the case of
web browsers.

Regards.

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

---

From: José Luis Millán <[email-masked]>
Date: Fri, 24 Aug 2012 18:48:43 +0200

Hi Partha,

Please, read inline.

> 2)    INVITE is forwarded towards UAS by SIP Websocket server

.. which adds a Record-Route header field because it wants to stay in
the signaling path during the dialog ;-)

> 3)    UAS receives INVITE and sent 200 OK response with contact address with

it builds the 200 OK response taking the Record-Route headers from the
received INVITE request.

> 4)    SIP Websocket server forwards 200 OK towards SIP Websocket client

It receives 200 OK with the Record-Route headers

>        address in UDP transport? No.

ACK request will be formed with the dialog`s route set, being the
first hop the SIP WebSocket Server.

> the callflow breaks in this specification.

Why didn't you add a Record-Route header in the point '2' ( INVITE is
forwarded towards UAS by SIP Websocket server) ?

You should have added if you wanted to stay in the signaling path
during the dialog. This is stated in RFC 3261. The reason your ACK
does not reach the destination is a configuration problem more that
specification definition issue.

Regards.

>    specified in [RFC3261].  Otherwise in-dialog requests would fail
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Aug 2012 22:45:17 +0530

Jose,

I haven't added "record-route" in point 2 as RFC 3261 does not mandates to
add :-) 
In case of RFC 3261 SIP transports, the dialog creation happens without
"record-route" 
whereas SIP over WebSocket transport in browser is different.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of José Luis Millán
Sent: Friday, August 24, 2012 10:19 PM
To: Parthasarathi R
Cc: [email-masked]
Subject: Re: [sipcore] Mandatory to implement transport comment on
draft-ibc-sipcore-sip-websocket-02

Hi Partha,

Please, read inline.

Regards.

> “In case SIP WebSocket Client is a web browser and SIP Websocket Server is
a

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Aug 2012 23:11:02 +0530

Inaki,

Paul started the relaxing the criteria for mandatory to implement transport mail thread during WG adoption of SIP over websocket draft and one of the mail is http://www.ietf.org/mail-archive/web/sipcore/current/msg04930.html. My understanding of the mail thread conclusion was that narrow approach of providing leniency for mandatory to implement transport in SIP over Websocket draft itself.  I noticed in the current document that there is no relevant text for this leniency and so raised the issue in IETF-84 SIPCore meeting. As per IETF-84 SIPCore meeting discussion, I started this mail thread.

In case you are not in favor of narrow approach proposed by Paul, then it is a separate discussion. Also you have indicated that the narrow approach needs more text, then please suggest the text and let us discuss.

Thanks
Partha 

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Friday, August 24, 2012 10:09 PM
To: Parthasarathi R
Cc: José Luis Millán; [email-masked]
Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02

Ugly, agree?

Regards.

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

---

From: José Luis Millán <[email-masked]>
Date: Fri, 24 Aug 2012 19:44:20 +0200

> I haven't added "record-route" in point 2 as RFC 3261 does not mandates to

It mandates to insert a Record-Route header field if the proxy wishes
to remain on the path of future requests in a dialog.

"
16.6 Request Forwarding

If this proxy wishes to remain on the path of future requests
in a dialog created by this request (assuming the request
creates a dialog), it MUST insert a Record-Route header field
value into the copy before any existing Record-Route header
field values, even if a Route header field is already present.
"

Addition of Record-Route header field is already commented in
draft-ibc-sipcore-sip-websocket-02, in section 2 of Appendix A:  SIP
WebSocket Server Considerations.

"

May the following (extracted from the previous text) not be clear?

"
SIP WebSocket Clients make use of their SIP WebSocket Server in
order to send and receive SIP requests and responses
"

Considering the previous text, isn't it clear that the SIP WebSocket
Server is used by the SIP WebSocket Client for sending and receiving
SIP requests and responses, which involves SIP WebSocket Server
staying in the signaling path?

Regards.

---

From: José Luis Millán <[email-masked]>
Date: Fri, 24 Aug 2012 20:15:28 +0200

Hi Partha,

I honestly think this thread is not a good starting point for
discussing the subject related to 3261 requirement for UDP and TCP
transports.

Best regards,

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 24 Aug 2012 20:42:12 +0200

2012/8/24 Parthasarathi R <[email-masked]>:
> UAS contact address in UDP transport? No.
>
> client, ACK will send towards UAS contact address with UDP transport as per mandatory to implement
> implement transport mechanism, the callflow breaks in this specification.

Hi Partha, please read the following scenario:

UAC SIP UDP/TCP client ------ Proxy SIP ----- UAS SIP UDP/TCP/SCTP

Callflow steps:

1) UAC resolves via RFC3263 the transport and destination of the Proxy
(UDP is the first NAPTR option) and uses UDP to send an INVITE to the
AoR of UAS through the Proxy. The INVITE has a Contact URI with
;transport=udp.

2) INVITE arrives to the Proxy which does NOT add Record-Route,
performs RFC3263 with the Request-URI (SCTP is the preferred
transport) and opens an SCTP connection with UAS for forwarding the
INVITE.

3) UAS receives INVITE and sent 200 OK response with Contact address
with ;transport=sctp.

4) Proxy forwards the 200 OK to UAC (no Record-Route).

5) UAC should now send the ACK by opening an SCTP connection with UAS.

Can UAC do that? not, because it does NOT implement SCTP transport. So
the only solution here is for the Proxy to add Record-Route to the
initial INVITE.

Please let me know where RFC 4168 (SIP SCTP transport) talks about
this scenario and where the RFC mentions the words "Record-Route" or
"Proxy" (it does not). So, shouldn't RFC 4168 also update RFC 3261 by
stating that "If an INVITE arrives to a proxy through an SCTP
connection and the proxy forwards it via UDP or TCP then it
MUST/SHOULD add Record-Route headers"? It does not so, why should the
sip-websocket draft mandate it?

Please, reply. Thanks a lot.

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 25 Aug 2012 21:21:37 +0530

Inaki,

I could not see the relation between UAC SIP Websocket client violates RFC 3261 normative statement and your callflow. In your callflow, the dialog fails because of the extension is not supported by UAC.

Thanks
Partha 

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Saturday, August 25, 2012 12:12 AM
To: Parthasarathi R
Cc: José Luis Millán; [email-masked]
Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02

Callflow steps:

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 25 Aug 2012 21:36:56 +0530

Inaki/Jose,

Your current argument in the different mail of this same mail thread argue for not to close this open item which allows to relaxing the criteria for mandatory to implement (UDP/TCP) transport. If so, SIP over Websocket client MUST support UDP & TCP as SIP transport to meet RFC 3261 normative statement. Please note that SIP over Websocket implementation with UDP & TCP as SIP transport is possible by Linux/Windows application but not by Browser as of now.

I'll like to hear more opinion from different folks before closing this open item.

Thanks
Partha

-----Original Message-----
From: Parthasarathi R [mailto:[email-masked]] 
Sent: Friday, August 24, 2012 11:11 PM
To: 'Iñaki Baz Castillo'
Cc: 'José Luis Millán'; [email-masked]'
Subject: RE: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02

Inaki,

Thanks
Partha 

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Friday, August 24, 2012 10:09 PM
To: Parthasarathi R
Cc: José Luis Millán; [email-masked]
Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02

Ugly, agree?

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Aug 2012 20:46:07 +0200

Hi,

I am not sure who I agree/disagree with, but my opinion is that a WebSocket UA shall not be mandated to implement UDP and TCP.

A WebSocket UA might work in an environement where it can't use UDP or TCP anyway. For example, if a JavaScript SIP UA in a browser technically can only use WebSocket for SIP, why mandate it to implement something that it can't use???

As far as the WebServer SIP proxy it concerned, it MUST Record-Route.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Parthasarathi R [[email-masked]]
Sent: Saturday, August 25, 2012 7:06 PM
To: 'Iñaki Baz Castillo'; 'José Luis Millán'
Cc: [email-masked]
Subject: Re: [sipcore] Mandatory to implement transport comment on      draft-ibc-sipcore-sip-websocket-02

Inaki/Jose,

Thanks
Partha

-----Original Message-----
From: Parthasarathi R [mailto:[email-masked]]
Sent: Friday, August 24, 2012 11:11 PM
To: 'Iñaki Baz Castillo'
Cc: 'José Luis Millán'; [email-masked]'
Subject: RE: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02

Inaki,

Thanks
Partha

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]]
Sent: Friday, August 24, 2012 10:09 PM
To: Parthasarathi R
Cc: José Luis Millán; [email-masked]
Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02

Ugly, agree?

Regards.

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

---

From: José Luis Millán <[email-masked]>
Date: Sun, 26 Aug 2012 12:09:37 +0200

Hi,

Most WebSocket implementations do not allow (and there is no evidence
they will in the near future) receiving incoming connections. They can
only establish outgoing connections with WebSocket server
implementations.

The specification of this new transport allows SIP to be used as a
session establishment protocol in the World Wide Web, in scenarios
where non of other transport protocols defined for SIP can be used.

SIP is the one entering in the WWW within this draft, allowing
massively used applications to use our loving protocol. Most of those
applications do not implement any existing SIP transport but
WebSocket, the one we are adopting in this document.

This specification defines the way SIP WebSocket Client and Server
communicate and the mechanisms for the SIP element acting as WebSocket
Server to interact with other non WebSocket SIP elements.

We authors propose the following statements to be used in this
specification according to this task:

"
SIP WebSocket Servers implementing this specification MUST implement
UDP and TCP as stated in [RFC 3261].

SIP WebSocket Clients implementing this specification MAY implement
UDP and TCP protocols, being their interoperability guaranteed by SIP
WebSocket Servers which MUST be used as the first hop in the signaling
path.

"

Of course, by definition, a SIP WebSocket server MUST Record-Route.

Any comment about the proposed statements is appreciated.

Regards,

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 Aug 2012 13:35:39 +0200

Hi,

>only establish outgoing connections with WebSocket server

Exactly.

>where non of other transport protocols defined for SIP can be used.

Exactly. It's a completely new environment.

>WebSocket, the one we are adopting in this document.

Exactly.

>UDP and TCP as stated in [RFC 3261].

I would suggest to say that the MUST applies if such server also communicate SIP using non-WS interfaces.

Because, there could be a SIP WebSocket Server that *only* provides services to WS clients.

Maybe something like:

"SIP WebSocket Servers implementing this specification, and that also support SIP using the transport mechanisms defined in [RFC 3261], MUST implement both UDP and TCP, as stated in the RFC"

>>path."

I can't parse the sentence.

Maybe something like:

"As a SIP WebSocket Client will always communicate with a SIP WebSocket Server, and since some environments do not enable SIP WebSocket Clients to use other UDP and TCP as SIP transport protocols for SIP, a SIP WebSocket Client is not mandated to implement support of UDP and TCP."

Regards,

Christer

---

From: José Luis Millán <[email-masked]>
Date: Tue, 28 Aug 2012 07:30:32 +0200

> "SIP WebSocket Servers implementing this specification, and that also support SIP using the transport mechanisms defined in [RFC 3261], MUST implement both UDP and TCP, as stated in the RFC"

Although it could seem logical at a first glance, such a statement
breaks the basic level of protocol interoperability. This limitation
is not imposed by the new transport and hence it seems reasonable that
the SIP WebSocket Server MUST implement UDP and TCP as stated in [RFC
3261].

do you agree?

> "As a SIP WebSocket Client will always communicate with a SIP WebSocket Server, and since some environments do not enable SIP WebSocket Clients to use other UDP and TCP as SIP transport protocols f…

Agree with this.

> Christer

Thank you for your comments Christer,

Regards

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Aug 2012 08:50:55 +0200

Hi,

> Although it could seem logical at a first glance, such a statement breaks the basic level of protocol interoperability. This limitation is not imposed by the new transport and hence it seems reasonable that the SIP WebSocket Server MUST implement UDP 
> and TCP as stated in [RFC 3261].
>
> do you agree?

I'm fine with your suggestion.

Regards,

Christer

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 28 Aug 2012 11:02:57 +0200

> I'm fine with your suggestion.

Great -- we'll update the draft accordingly

Cheers,
-Victor

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 28 Aug 2012 22:07:36 +0530

Hi,

It is good to see the addition of text around this open issue. As there is
no normative usage in the proposed text, The minor correction shall be as
follows:

"As a SIP WebSocket Client will always communicate with a SIP WebSocket
Server, and since some environments do not enable SIP WebSocket Clients to
use other UDP and TCP as SIP transport protocols for SIP, a SIP WebSocket
Client MAY not implement UDP and TCP as SIP transport"

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Victor Pascual Avila
Sent: Tuesday, August 28, 2012 2:33 PM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [sipcore] Mandatory to implement transport comment on
draft-ibc-sipcore-sip-websocket-02

On Tue, Aug 28, 2012 at 8:50 AM, Christer Holmberg
<[email-masked]> wrote:
>>> "SIP WebSocket Servers implementing this specification, and that also
support SIP using the transport mechanisms defined in [RFC 3261], MUST
implement both UDP and TCP, as stated in the RFC"
>>>
>>
>> Although it could seem logical at a first glance, such a statement breaks
the basic level of protocol interoperability. This limitation is not imposed
by the new transport and hence it seems reasonable that the SIP WebSocket
Server MUST implement UDP

Cheers,
-Victor