IETF Logo Mail Archive

Re: [sipcore] Proposal for a new SIP transport (WebSocket)

Ravindran Parthasarathi <pravindran@sonusnet.com> Tue, 01 November 2011 18:56 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 A343C11E816E for <sipcore@ietfa.amsl.com>; Tue, 1 Nov 2011 11:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.357
X-Spam-Level:
X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, J_CHICKENPOX_83=0.6]
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 iknB9XLPJtR4 for <sipcore@ietfa.amsl.com>; Tue, 1 Nov 2011 11:56:53 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E05F011E811F for <sipcore@ietf.org>; Tue, 1 Nov 2011 11:56:52 -0700 (PDT)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA1IsbeI006412; Tue, 1 Nov 2011 14:54:37 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 14:53:51 -0400
Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 00:23:55 +0530
Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 2 Nov 2011 00:23:54 +0530
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Wed, 2 Nov 2011 00:23:54 +0530
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket)
Thread-Index: AcyVikXNSMUssoD1TwmwuLzmfhjfMwCNzwOAAAB9xIAAA3sXgAABP8eAADu8GgA=
Date: Tue, 01 Nov 2011 18:53:53 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CBD80@inba-mail01.sonusnet.com>
References: <CALiegf=_8GuvEHPR=rFA3Urtj0WxzRFQ4W=_dxkCDKZMbHL_aw@mail.gmail.com> <CALiegf=pRjgBUpLxm3e7CopwSrS8e9BekKdF5ZZEW04S29-XnA@mail.gmail.com> <A5D2BE40-0619-40E3-B884-2340E0D6AF4E@acmepacket.com> <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> <CALiegfkgnaGzstBwXV0_v9obtxMYKCzRSB_f2Yy+W3C-BRLADQ@mail.gmail.com>, <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> <CD5674C3CD99574EBA7432465FC13C1B225CA60114@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B225CA60114@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.53.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Nov 2011 18:53:55.0706 (UTC) FILETIME=[9B399DA0:01CC98C7]
Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket)
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: Tue, 01 Nov 2011 18:56:53 -0000

Dale,

>
>It sounds like WebSocket paths are effectively a variant of the
>connection between the UA and the Edge Proxy in SIP Outbound (RFC
>5626), and what they need is a "flow token" (defined by the edge
>proxy), not a new Via transport value (standardized).
>

Agree with you. In fact, I got the same answer for not choosing SIP as RTCWeb signaling protocol because SIP outbound(RFC 5626) is addressed in part of RFC 3261 and the same NAT issue is addressed in websocket base protocol itself.

Thanks
Partha

>-----Original Message-----
>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
>Behalf Of Worley, Dale R (Dale)
>Sent: Tuesday, November 01, 2011 1:07 AM
>To: sipcore@ietf.org
>Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket)
>
>> From: Iñaki Baz Castillo [ibc@aliax.net]
>>
>> Well, honestly I see no use case for using WebSocket transport between
>> SIP proxies/servers. WebSocket is clearly a transport for web browsers
>> and also for client applications. There is no advantage in using
>> WebSocket between other SIP nodes.
>
>It sounds like WebSocket paths are effectively a variant of the
>connection between the UA and the Edge Proxy in SIP Outbound (RFC
>5626), and what they need is a "flow token" (defined by the edge
>proxy), not a new Via transport value (standardized).
>
>> From: Hadriel Kaplan [HKaplan@acmepacket.com]
>>
>> 2) Since websocket can cross even restrictive firewalls, you could use
>> a piece of proxy-ish software on your laptop like SER or Asterix or
>> SipXecs or whatever.  I have no idea why you'd want to run those from
>> behind a restrictive firewall, or why you couldn't configure the
>> firewall to let you do it, instead of using websocket; but if you
>> needed to, you could use websocket.
>
>Isn't there an RFC (around 1 April 1988?) detailing encapsulating IP
>packets in HTTP requests/responses as a way to get through restrictive
>firewalls?
>
>Dale
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org
>https://www.ietf.org/mailman/listinfo/sipcore

v2.23.0 | Report a Bug | By Email