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

On 09/15/2011 11:49 AM, Markus.Isomaki@nokia.com 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.
>    

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.

> 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Roman Shpount
> Sent: 15 September, 2011 20:34
> To: Tim Panton
> Cc: rtcweb@ietf.org
> 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<tim@phonefromhere.com>  wrote:
>
> On 13 Sep 2011, at 21:50, Jos� Luis Mill�n wrote:
>
>
> On Tue, Sep 13, 2011 at 9:25 PM, �<Markus.Isomaki@nokia.com>  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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    

-- 

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