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

From: José Luis Millán <[email-masked]>
Date: Tue, 13 Sep 2011 22:50:54 +0200

On Tue, Sep 13, 2011 at 9:25 PM,  <[email-masked]> wrote:
> Hi Inaki,
>
> Fully agree about everything you say below.

Hi,

Sorry if this mail arrives out of the original mail thread.

>
> It would be interesting to understand the performance differences of the
native vs. Javascript SIP stack, if there is anything we should be worried
about. This is my only concern when (perhaps one day) applying RTCWeb in
devices like smartphones. If the JS stack works in (any of) today's high end
smartphones without problems, we should be fine.

The are no meaningful performance penalties at all using the JavaScript SIP
stack in our prototype. In fact, multiple SIP stack instances can run in a
single Web browser freshly.  BTW, is there any WebSocket capable web browser
for smartphones?

>
> Markus
>
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>Of ext Iñaki Baz Castillo
>>Sent: 13 September, 2011 21:23
>>To: Ravindran Parthasarathi
>>Cc: [email-masked]
>>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket
Transport
>>for Session Initiation Protocol (SIP)
>>
>>2011/9/13 Ravindran Parthasarathi <[email-masked]>:
>>> Hi Inaki,
>>>
>>> I like the idea of using SIP between browser & server.
>>>
>>> I really don't know the strong reason for tunneling SIP message within
>>websocket. In fact, we are discussing SIP vs websocket in
>>http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html mail
>>thread as signaling protocol for RTCweb. Could you please mention the
>>technical advantage in going in the path of SIP over websocket rather than
>>having plain SIP connection over TCP or TLS or (UDP or DTLS).
>>
>>Hi Ravindran,
>>
>>SIP is a complex protocol and there are numerous extensions and features
in
>>many RFC's extending the SIP protocol. Having to rely on the features
>>implemented in a native SIP stack within the web-browser seems not enough
>>flexible IMHO. I also expect many limitations and lack-of-features in the
>>different SIP implementations of each browser (and each version of the
>>browser).
>>
>>In the other side, if the SIP stack is coded within a JavaScript library
and makes
>>usage of the WebSocket protocol, innovation depends on the developer and
>>not on the browser native capabilities. A web page could offer a minimal
SIP
>>stack just implementing basic outgoing calls (i.e. "Click2Call" buttons in
the
>>web), while another web page could prefer to provide a powerful SIP stack
>>implementing blink/attended transfer, subscription to presence and
>>dialogs/calls, conference features, call-pickup, SIP messaging and so on
>>(imagine such phone integrated within an enterprise intranet). I don't
expect
>>that the SIP stack integrated within *every* existing web-browsers would
>>implement all those SIP features in a correct way (because that does not
>>happen neither when using expensive SIP desktop phones or softphones).
>>
>>Also, the specification defined in the draft solves NAT issues (at
signaling
>>level) without requiring server side solutions for fixing NAT in clients.
>>
>>WebSocket protocol is becoming a new "transport" protocol.
>>Implementing SIP protocol on top of it can only bring advantages and new
>>possibilities. The specification in the draft is an adaptation of SIP to
make use
>>of WebSocket, as it already does with UDP, TCP and SCTP transports.
>>
>>
>>BTW, as said in the first mail, we have published the draft after having a
>>working prototype making usage of the specification described in the
>>document. After that, we see no real advantage on having a native SIP
stack
>>within a web browser. The prototype will be shown soon.
>>
>>Best regards.
>>
>>--
>>Iñaki Baz Castillo
>><[email-masked]>
>>_______________________________________________
>>rtcweb mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Tim Panton <[email-masked]>
Date: Thu, 15 Sep 2011 11:02:04 +0100

On 13 Sep 2011, at 21:50, José Luis Millán wrote:

> > It would be interesting to understand the performance differences of the native vs. Javascript SIP stack, if there is anything we should be worried about. This is my only concern when (perhaps one day) applying RTCWeb in devices like smartphones. If the JS stack works in (any of) today's high end smartphones without problems, we should be fine.
> 
> The are no meaningful performance penalties at all using the JavaScript SIP stack in our prototype. In fact, multiple SIP stack instances can run in a single Web browser freshly.  BTW, is there any WebSocket capable web browser for smartphones?

As an additional datapoint, The Phono.com javascript XMPP stack performs fine on android and iOS within a Phonegap app.
Native browser javascript engines tend to be slightly better optimized than the ones available to mobile apps,
so I doubt that performance would be an issue.

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 15 Sep 2011 13:34:01 -0400

The only potential problem with mobile applications and javascript based
signaling code is the effect of maintaining registrations for long periods
of time while waiting for a call on battery life and network utilization. A
regular SIP library can be designed is such a way that the device will go
into sleep mode and will wake up when a SIP packet is received. JavaScript
will need to open a connection to a server and send ping messages at
regular, fairly short, intervals, that will cause device to wake up every
time ping message needs to be sent and to consume both power and network
capacity. Such applications, running for the long periods of time can
seriously decrease battery lifetime. On the other hand, doing this during an
active call has a negligible effect on both power consumption or network
utilization, since device is already running and sending media.
_____________
Roman Shpount

On Thu, Sep 15, 2011 at 6:02 AM, Tim Panton <[email-masked]> wrote:

> As an additional datapoint, The Phono.com javascript XMPP stack performs
> fine on android and iOS within a Phonegap app.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 15 Sep 2011 10:39:27 -0700

On 9/15/2011 10:34 AM, Roman Shpount wrote:
> The only potential problem with mobile applications and javascript 
> based signaling code is the effect of maintaining registrations for 
> long periods of time while waiting for a call on battery life and 
> network utilization. A regular SIP library can be designed is such a 
> way that the device will go into sleep mode and will wake up when a 
> SIP packet is received. JavaScript will need to open a connection to a 
> server and send ping messages at regular, fairly short, intervals, 
> that will cause device to wake up every time ping message needs to be 
> sent and to consume both power and network capacity. Such 
> applications, running for the long periods of time can seriously 
> decrease battery lifetime. On the other hand, doing this during an 
> active call has a negligible effect on both power consumption or 
> network utilization, since device is already running and sending media.

+1

Any suggested solutions, other than "require (native) SIP"?   (Since 
SIP-in-JS would I assume fall into the case above.)

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Thu, 15 Sep 2011 13:52:17 -0400

I don't think this is a problem for RTC web to resolve. This is the same
problem that someone building an IM or email client for a web browser will
need to deal with. Some type of push notification framework is needed to
implement this and it might be something for W3C to standardize as a
solution for this problem.
_____________
Roman Shpount

On Thu, Sep 15, 2011 at 1:39 PM, Randell Jesup <[email-masked]>wrote:

> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: <[email-masked]>
Date: Thu, 15 Sep 2011 18:49:02 +0000

Hi,

This is an important point. But why do you think it is necessary for a Javascript based implementation, using HTTP or websockets, to send keepalives more often than a regular SIP UA would? If both are running on TCP, the NAT and firewall and such timers will be the same for both, and this gives an upper bound to the keepalive interval. (SIP over UDP is out of the question due to too short timers.)

RTCWeb HTTP or websocket servers should be designed so that they do not require some kind of hearbeat or pingpong or keepalive too often by themselves, and especially they should not interfere but let the clients do them. 

The trend has been that a lot of asynchronous communication is nowadays agregated to apps via some kind of "notification service" (several companies run them), so that not all apps need to do keepalives by themselves. It would be useful if the browser/web environment could also make use of these services. Unfortunately they are all proprietary and bound to a particular OS or vendor.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Roman Shpount
Sent: 15 September, 2011 20:34
To: Tim Panton
Cc: [email-masked]
Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)

The only potential problem with mobile applications and javascript based signaling code is the effect of maintaining registrations for long periods of time while waiting for a call on battery life and network utilization. A regular SIP library can be designed is such a way that the device will go into sleep mode and will wake up when a SIP packet is received. JavaScript will need to open a connection to a server and send ping messages at regular, fairly short, intervals, that will cause device to wake up every time ping message needs to be sent and to consume both power and network capacity. Such applications, running for the long periods of time can seriously decrease battery lifetime. On the other hand, doing this during an active call has a negligible effect on both power consumption or network utilization, since device is already running and sending media. 
_____________
Roman Shpount

Hi,

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 15 Sep 2011 14:57:08 -0400

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. If SIP over TCP/TLS from behind NAT is used, there
are no benefits of using SIP over a long poll HTTP connection or websockets.
Btw, sometime with SIP a combination technique is used, where a notification
is pushed to a SIP client using a mobile service specific push mechanism,
SIP client processes this notification, re-registers, and that connection is
used to place a call. Something similar can be used for a web app, but such
implementation would be specific to each mobile platform.
_____________
Roman Shpount

On Thu, Sep 15, 2011 at 2:49 PM, <[email-masked]> wrote:

> Hi,
>
> This is an important point. But why do you think it is necessary for a
> Javascript based implementation, using HTTP or websockets, to send
> keepalives more often than a regular SIP UA would? If both are running on
> TCP, the NAT and firewall and such timers will be the same for both, and
> this gives an upper bound to the keepalive interval. (SIP over UDP is out of
> the question due to too short timers.)
>
> RTCWeb HTTP or websocket servers should be designed so that they do not
> require some kind of hearbeat or pingpong or keepalive too often by
> themselves, and especially they should not interfere but let the clients do
> them.
>
> The trend has been that a lot of asynchronous communication is nowadays
> agregated to apps via some kind of "notification service" (several companies
> run them), so that not all apps need to do keepalives by themselves. It
> would be useful if the browser/web environment could also make use of these
> services. Unfortunately they are all proprietary and bound to a particular
> OS or vendor.
>
> Markus
>
>
> Of ext Roman Shpount

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 15 Sep 2011 15:06:39 -0400

With that, I think it would be best to leave the timers configurable, 
with an agreed default, of course.  (I would imagine that sooner or 
later there will be an application that may demand faster heartbeat.)

Igor

On 9/15/2011 2:49 PM, [email-masked] wrote:
> ...
> ...
> .

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 15 Sep 2011 12:10:05 -0700

> RTCWeb HTTP or websocket servers should be designed so that they do not require some kind of hearbeat or pingpong or keepalive too often by themselves, and especially they should not interfere but…

In crowds of more than 10,000 people all with "mobiles" the heart-beat 
signal/server is liken to QoS for proximal optimization for them. They 
have the option to tune-out and still have expected bandwidth which is 
known to get worse without QoS in such scenarios. With "50mi wi-fi" out 
now, this is now liken to the clock towers at universities and not just 
some reminder of the Olympic bandwidth requirements. We can think of 
that as basic federation before we evolve security states; also, that 
help clear-up the situation of a stateful transfer between get-opts and 
SCTP such that schema moves up on the lexical stack.

I see why Bruce Perens wants "The Covenant" now.

> On Thu, Sep 15, 2011 at 6:02 AM, Tim Panton<[email-masked]>  wrote:
>
> On 13 Sep 2011, at 21:50, Jos� Luis Mill�n wrote:
>
>
> On Tue, Sep 13, 2011 at 9:25 PM, �<[email-masked]>  wrote:
>    
>> Hi Inaki,
>>
> The are no meaningful performance penalties at all using the JavaScript SIP stack in our prototype. In fact, multiple SIP stack instances can run in a single Web browser freshly. �BTW, is there any WebSocket capable web browser for smartphones?
>
> As an additional datapoint, The�Phono.com�javascript XMPP stack performs fine on android and iOS within a Phonegap app.

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 15 Sep 2011 12:12:37 -0700

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
[email-masked]

---

From: <[email-masked]>
Date: Thu, 15 Sep 2011 19:24:53 +0000

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.

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

>Of ext Randell Jesup
>Sent: 15 September, 2011 22:13
>To: [email-masked]
>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
>[email-masked]
>

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 15 Sep 2011 12:49:10 -0700

> 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…

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.

-- 

---

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 16 Sep 2011 08:51:03 +0200

Hi,

On Sep 15, 2011, at 7:52 PM, Roman Shpount wrote:

> I don't think this is a problem for RTC web to resolve. This is the same problem that someone building an IM or email client for a web browser will need to deal with. Some type of push notification framework is needed to implement this and it might be something for W3C to standardize as a solution for this problem. 

I fully agree here. AFAIK this group is not about getting applications to run smoothly on mobile platforms, it's about realtime communications within a browser. Having a JS SIP client on a browser might be OK for a desktop, but mobiles will always need native apps because they can be optimized for specific hardware and give a better user experience IMHO. That being said, I don't think mobile battery consumption is important in any way when discussing SIP over WebSocket.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: <[email-masked]>
Date: Fri, 16 Sep 2011 07:29:11 +0000

Hi,

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. 

Markus 

>Of ext Dzonatas Sol
>Sent: 15 September, 2011 22:49
>To: [email-masked]
>> 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
>>
>>
>>
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of ext Randell Jesup
>>> Transport for Session Initiation Protocol (SIP)
>>>
>>> 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
>>> [email-masked]
>>>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 16 Sep 2011 11:04:02 -0700

> Behalf Of Randell Jesup
> Sent: Thursday, September 15, 2011 12:13 PM
> To: [email-masked]

PCP could help with that, 
http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3

-d