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

<> Fri, 16 September 2011 07:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3CFA21F8BE5 for <>; Fri, 16 Sep 2011 00:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9z3rURmeNQ+1 for <>; Fri, 16 Sep 2011 00:27:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B378C21F8BDC for <>; Fri, 16 Sep 2011 00:27:26 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8G7TScd017814; Fri, 16 Sep 2011 10:29:38 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Sep 2011 10:29:35 +0300
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 16 Sep 2011 09:29:35 +0200
Received: from ([]) by ([]) with mapi id 14.01.0323.007; Fri, 16 Sep 2011 09:29:12 +0200
Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)
Date: Fri, 16 Sep 2011 07:29:11 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Sep 2011 07:29:35.0562 (UTC) FILETIME=[62785AA0:01CC7442]
X-Nokia-AV: Clean
Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Sep 2011 07:27:27 -0000


The real-time media traffic should definitely go over UDP. And even if in that case there is also a question about keepalives, that is not so critical as typically the real-time sessions are not that long. And when they are on, users do understand that the battery can run out after a while if they don't charge. This is the so called "talk time" in legacy mobile phone terms. But all "signaling" needs to be on TCP, as that connectivity is in many cases needed all the time, to be able to receive calls, messages and other events. And users don't accept that the phone/tablet runs out of battery, even if it is "unused" from their perspective. This is the "stand-by time" in legacy terms.

Now, these may be quite specific issues to battery powered devices using cellular/wide-are type of radios for their Internet access. But I think that will be an important segment of devices for RTCWeb too. 


>-----Original Message-----
>From: [] On Behalf
>Of ext Dzonatas Sol
>Sent: 15 September, 2011 22:49
>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport
>for Session Initiation Protocol (SIP)
>On 09/15/2011 12:24 PM, wrote:
>> SIP over UDP is used by mobile operators themselves, as they are in control
>of the access infrastructure, and can make special provisions for their own
>services. But if you try to run SIP over UDP over mobile networks to any
>independent ("OTT") Internet service, it is likely to not work that well, due to
>battery consumption. Even with public addresses, in many mobile networks
>firewalls drop UDP flow state after 30 seconds.
>If the concern is the battery, then with ICE, SIP over UDP is something we
>want can reserve in stateful progressions. People don't like that stateful
>discussion when it comes to buffer size and transient mix, as they defaulted
>to cache under IPv4.
>E911 traffic would be transient to corporate cache, for example. There are
>more options as we garbage collect, resolve, and reserve those allocations
>after clean from either cache or transient states. Behind corporate firewalls,
>cache items could be datestamp'd, which simply releases them from the
>transient state. Under SMTP, that was normal.
>UDP is BSD friendly, and I like how rtcweb fits right in the UDP header with
>extended Content-Length:. If the SSRC is touched, then expand or deliver.
>> TCP usually survives longer, in most networks actually more than 15
>> minutes. Unfortunately a small percentage of networks breaks even TCP
>> in less than 5 minutes. (Several companies, including Nokia, have
>> concrete stats from all over the globe.)
>> So all in all I'm not sure that HTTP or websockets are in a worse position than
>pure SIP. The main differences are that the Javascript app may not have
>access to some helpers the more native mobile platform may offer.
>> Markus
>>> -----Original Message-----
>>> From: [] On
>>> Behalf Of ext Randell Jesup
>>> Sent: 15 September, 2011 22:13
>>> To:
>>> Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket
>>> Transport for Session Initiation Protocol (SIP)
>>> On 9/15/2011 11:57 AM, Roman Shpount wrote:
>>>> Actually SIP over UDP is what is typically used for mobile apps now.
>>>> If you are doing SIP from the public IP, you do not need to maintain
>>>> the connection even if TCP/TLS is used.
>>> Markus had a point: SIP over UDP requires keepalives if it's behind a
>>> NAT as well.  So maybe it's not such a big difference, depending on
>>> the keepalive rates needed (and for UDP circa 30 sec is typical).
>>> --
>>> Randell Jesup
>>> _______________________________________________
>>> rtcweb mailing list
>> _______________________________________________
>> rtcweb mailing list
><i>The wheel.</i metro-link=t dzonatasolyndra>
>rtcweb mailing list