IETF Logo Mail Archive

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

Ravindran Parthasarathi <pravindran@sonusnet.com> Tue, 01 November 2011 19:10 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 436D321F8D0E for <sipcore@ietfa.amsl.com>; Tue, 1 Nov 2011 12:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 gPxKy7ljPu+S for <sipcore@ietfa.amsl.com>; Tue, 1 Nov 2011 12:10:01 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0387811E80B5 for <sipcore@ietf.org>; Tue, 1 Nov 2011 12:09:53 -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 pA1J9cKC016304; Tue, 1 Nov 2011 15:09:38 -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 15:08:11 -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:38:14 +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:38:13 +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:38:13 +0530
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>, "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: AcyVikXNSMUssoD1TwmwuLzmfhjfMwCNzwOAAAB9xIAAA3sXgAABP8eAADu8GgAAAQROgA==
Date: Tue, 01 Nov 2011 19:08:13 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CBDD3@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> <387F9047F55E8C42850AD6B3A7A03C6CBD80@inba-mail01.sonusnet.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CBD80@inba-mail01.sonusnet.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 19:08:14.0721 (UTC) FILETIME=[9B3CE710:01CC98C9]
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 19:10:02 -0000

Typo - because SIP outbound(RFC 5626) is "not" addressed as

>-----Original Message-----
>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
>Behalf Of Ravindran Parthasarathi
>Sent: Wednesday, November 02, 2011 12:24 AM
>To: Worley, Dale R (Dale); sipcore@ietf.org
>Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket)
>
>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 not addressed as
>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
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org
>https://www.ietf.org/mailman/listinfo/sipcore

v2.23.0 | Report a Bug | By Email