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

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, <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.
>
> 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
>
>