Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]

"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Wed, 18 April 2012 08:23 UTC

Return-Path: <pravindran@sonusnet.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7C621F85FD for <sipcore@ietfa.amsl.com>; Wed, 18 Apr 2012 01:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.561
X-Spam-Level:
X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTUjaI+02aMQ for <sipcore@ietfa.amsl.com>; Wed, 18 Apr 2012 01:23:32 -0700 (PDT)
Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB9B21F866E for <sipcore@ietf.org>; Wed, 18 Apr 2012 01:23:31 -0700 (PDT)
Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT456Ak8fRNNNLtTrQ+Di5GsSbo8arOoj@postini.com; Wed, 18 Apr 2012 01:23:31 PDT
Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 04:24:04 -0400
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 13:53:24 +0530
From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: "Nataraju A.B" <nataraju.sip@gmail.com>
Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]
Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsA==
Date: Wed, 18 Apr 2012 08:23:23 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com>
References: <CALiegfmw+ouWqoVbsiMuq2CJ4TxkeREVVbw308FzwKpUUrw7tw@mail.gmail.com> <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <CA+rAfUPj4h0R_qHKw53SFotAQSe83m3jZyucBPxcXqVxfEqMCw@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <CA+rAfUM0MCfEd-Rj5aykeZ24=Kcgxk6GQzi4jFPc8P6EUQuoxg@mail.gmail.com>
In-Reply-To: <CA+rAfUM0MCfEd-Rj5aykeZ24=Kcgxk6GQzi4jFPc8P6EUQuoxg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.54.32]
Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F98inbamail01sonus_"
MIME-Version: 1.0
Cc: "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>, SIPCORE Chairs <sipcore-chairs@tools.ietf.org>
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02]
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 08:23:37 -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


From: Nataraju A.B [mailto:nataraju.sip@gmail.com]
Sent: Wednesday, April 18, 2012 12:59 PM
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 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 <pravindran@sonusnet.com<mailto:pravindran@sonusnet.com>> 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:nataraju.sip@gmail.com<mailto:nataraju.sip@gmail.com>]
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 <pravindran@sonusnet.com<mailto:pravindran@sonusnet.com>> 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

>-----Original Message-----
>From: sipcore-bounces@ietf.org<mailto:sipcore-bounces@ietf.org> [mailto:sipcore-bounces@ietf.org<mailto:sipcore-bounces@ietf.org>] On
>Behalf Of Adam Roach - SIPCORE Chair
>Sent: Monday, April 16, 2012 11:33 PM
>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.
>
>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 <ibc@aliax.net<mailto:ibc@aliax.net>>
>To: SIPCORE WG <sipcore@ietf.org<mailto:sipcore@ietf.org>>
>
>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
><ibc@aliax.net<mailto:ibc@aliax.net>>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<mailto:sipcore@ietf.org>
>https://www.ietf.org/mailman/listinfo/sipcore
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<mailto:sipcore@ietf.org>
>https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
sipcore@ietf.org<mailto:sipcore@ietf.org>
https://www.ietf.org/mailman/listinfo/sipcore



--
Thanks,
Nataraju A.B.




--
Thanks,
Nataraju A.B.