IETF Logo Mail Archive

Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)

Iñaki Baz Castillo <ibc@aliax.net> Wed, 14 September 2011 08:41 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA57C21F8ABB for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 01:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 h6DOnxz8ij-B for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 01:41:24 -0700 (PDT)
Received: from mail-qw0-f42.google.com (mail-qw0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4A821F849B for <rtcweb@ietf.org>; Wed, 14 Sep 2011 01:41:22 -0700 (PDT)
Received: by qwi4 with SMTP id 4so1924284qwi.29 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 01:43:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.42.76 with SMTP id r12mr2579421qce.178.1315989810200; Wed, 14 Sep 2011 01:43:30 -0700 (PDT)
Received: by 10.229.79.207 with HTTP; Wed, 14 Sep 2011 01:43:30 -0700 (PDT)
In-Reply-To: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com>
References: <CALiegfk6BhtzErXOQM8iSV7FC6isYUwOS1KPYCw_M1vEcNP6eQ@mail.gmail.com> <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com>
Date: Wed, 14 Sep 2011 10:43:30 +0200
Message-ID: <CALiegfnR=b-9AOBmzytAT-AX9Evr1vegFK-J+MtAhBNWNAAWbA@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: "Avasarala, Ranjit" <Ranjit.Avasarala@polycom.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2011 08:41:24 -0000

2011/9/14 Avasarala, Ranjit <Ranjit.Avasarala@polycom.com>:
> I have few initial comments on your draft

Hi Ranjit, replies inline:


> 1) in Section 3, its mentioned that there is no real benefit of using SIP over Websockets. If this is the case, why are you proposing integrating SIP with Websockets?

As Saul pointed out, the text says:

   There is no benefit on using SIP over WebSocket  transport between
   two SIP nodes when none of them runs within a web browser.

JavaScript can open a WebSocket connection from a web browser to a
server, but not an arbitrary TCP or UDP connection.


> 2) Also just integrating SIP for signaling case is really no use, as there are several other ways of achieving signaling in web - E.g. using libjingle of WebRTC, etc

The fact that there are other alternatives for signaling in the web
does not mean that using SIP is invalid.
If I want to build a SIP phone in a web, why should I use libjingle
rather than SIP protocol? Why should I code a complex server behaving
as a gateway between Jingle and SIP protocols?

Any protocol conversion (i.e. from Jingle to SIP) means loss of
features. Our draft proposes the contrary: no protocol conversion
(just SIP), and just transport protocol conversion (as already exists
in SIP when bridging UDP/TCP/TLS-TCP/SCTP...).



> 3) In Section 4, you mentioned that since Websocket is a reliable transport protocol, the websocket sub-protocol defined for SIP also becomes reliable. I don't agree with this - The websocket connection is actually initiated by the web browser client towards the web server and this connection needs to be kept alive through some keep alive mechanism. Otherwise the connection may close. I am not sure of reliability.

"Reliability" does not mean that. "Reliability" means data delivery
acknowledgment in the transport. This is true in TCP (so also in
WebSocket which works on top of TCP) and false in UDP (which is not a
reliable transport protocol).

The keep-alive mechanism is needed for cases in which there is a NAT
router in the path. Those routers usually close a TCP connection after
some minutes of inactivity. This happens in any TCP connection from
client to server through a NAT box.


> 4) In Section 4.1,I am not clear of the Via transport parameter having the value of "WS". Why do you need this when the whole SIP message is going as part of WebSocket payload [Using websocket API]?

This is how SIP protocol works and this is explained in RFC 3261. You
can also check a similar example for SIP over SCTP transport at:

  http://tools.ietf.org/html/rfc4168#section-4


Best regards.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email