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

[<[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of ext Roman Shpount
Sent: 15 September, 2011 20:34
To: Tim Panton
Cc: [e-mail]
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

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

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


On Tue, Sep 13, 2011 at 9:25 PM,  <[e-mail]> 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?

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.


_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb