Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal

From: [email-masked]
Date: Mon, 31 Oct 2005 10:37:53 +0200

Hi Paul,

I try to explain the battery consumption and call setup latency concerns in more detail. I'm only talking about messaging related to NAT traversal. I don't think there are other reasons for keep-alive messages as such.

I assume that the keep-alives for SIP signaling connection/flow can't be avoided. So, the UA has to generate those packets. However, using TCP helps there, since hopefully the rate of needed messages is not that high. (Although it must be taken into account that if you have several applications doing the same, e.g. SIP, "push" e-mail and so on, and each are keeping their respective bindings alive, the rate of messaging is already quite high.) 

Then comes the media, which is the crucial point. If the UA wants to keep addresses derived from STUN or TURN constantly available for use, it has to generate a lot of messages for keeping the bindings refreshed. That means generating messages at much higher rate than for SIP/TCP, and is not feasible with a major part of today's cellular networks/devices. The other option is then to use STUN or TURN whenever they are needed. If this is done just before needing to send the SDP (either an offer or an answer), some delay is introduced in the call setup, which has been another source of trouble. 

Jonathan already explained that it would be possible to start STUN and/or TURN before the actual call setup starts, e.g. when the user browses through the address book. That's an interesting idea. I don't know how well that would work in practice, probably that depends on how the UI works. (I assume it would work quite well in today's mobile phones, since in most of them the user actively enters the address book, and probably quite often actually makes a call after that.) But on the callee side there typically are no hints until an INVITE hits the UA. 

Another possibility, also pointed out by Jonathan, is to send the initial offer/answer without STUN/TURN-based addresses, and collect them in parallel to that. Then, those addresses could be put into use with a subsequent offer/answer. I have still to think about how that would best be done taking also into account the other possible challenges there are in cellular access/devices, such as resource reservation and the ability to run only a single codec in the DSP. If ICE with STUN/TURN interleaves nicely with everything else in the call setup, its use probably would not be a problem.

The thing is that standardization has quite a lot of intertia, and it seems that TISPAN and 3GPP have already setup their minds about SBCs, for whatever reasons (SBCs are "available", TURN and ICE are not yet "mature", session policy work is not well known so SBCs seem to be the only way to enforce something, ...?). Perhaps this should be a discussion topic in the TISPAN ad hoc advertised by Dean.

Regards,
	Markus

Paul Kyzivat wrote:
> 
> [email-masked] wrote:
> > Hi,
> > 
> > One of the most common functions that SBCs or Back-to-Back 
> UAs in general are used is NAT traversal. There are a couple 
> of quite crucial benefits for doing this:
> > - There is no need to implement complex things like ICE or 
> TURN in the User Agent, and this makes deployment much faster. 
> > - In the cellular wireless environment use of STUN and TURN 
> is problematic. If you want to keep the UDP bindings for 
> media open constantly just in case they are needed, you will 
> drain the battery in the device quite dramatically (at least 
> in WCDMA this is a clear issue, and basically in all other 
> radio technologies, where the device can go to some sort of 
> "idle" or "power saving" mode). On the other hand if you do 
> STUN/TURN only when someone sends an INVITE to you or you 
> want to send INVITE, the session setup time will increase due 
> to additional RTTs.
> 
> Markus, I would like to understand this better. It feels like 
> there is a 
> fundamental dilemma regarding the power management for this 
> wireless device.
> 
> On one hand, you want to avoid sending anything when you have 
> nothing to 
> say. On the other hand, the other elements in a call have resources 
> committed to it, and want to abandon the call if the mobile 
> is no longer 
> there. All these various techniques amount to keep alive 
> messages of one 
> form or another. Ultimately the mobile has to send *something* 
> periodically to prove that it is present and functioning.
> 
> So it seems that the best you can hope for is that the mobile 
> only has 
> to send one or a few things, at a frequency that doesn't 
> bother it too 
> much, and that everything that holds state for the call can 
> be assured 
> as a result of this minimal signaling.
> 
> I *think* the SBC's role in this is that by coupling signaling and 
> media, it can use keep-alives on the signaling channel as 
> proof that the 
> mobile is alive, and keep generating its own keep-alives on the media 
> channels.
> 
> This imposes both assumptions and constraints on the relationship 
> between media and signaling sources. After all, sip 
> explicitly decouples 
> signaling and media.
> 
> If you have to turn on the radio periodically to send *some* sort of 
> keepalive, does it cost significantly more to send several of 
> them? Or 
> is it that the frequencies differ for the various ones and so 
> you need 
> to turn on the radio independently for each one. If so, maybe 
> that is an 
> area where some work could yield benefits.
> 
> 	Paul
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 31 Oct 2005 07:22:29 -0600

Besides the traffic for NAT traversal and SIP events (thanks Markus!), I
wonder if people have looked also at the requirements for 802.21 Media
Independent Handover that has recently generated interesting work in the
IETF as well.

SIP mobility and multimodal mobile devices go well together and the SIPPING
WG seems to be well placed to deal with this aspect of mobility.

> TISPAN and 3GPP have already setup their minds about SBCs

Maybe they need to take a 2nd look or 802.21 will readily enable users to
switch networks.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, October 31, 2005 2:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal

Hi Paul,

I try to explain the battery consumption and call setup latency concerns in
more detail. I'm only talking about messaging related to NAT traversal. I
don't think there are other reasons for keep-alive messages as such.

I assume that the keep-alives for SIP signaling connection/flow can't be
avoided. So, the UA has to generate those packets. However, using TCP helps
there, since hopefully the rate of needed messages is not that high.
(Although it must be taken into account that if you have several
applications doing the same, e.g. SIP, "push" e-mail and so on, and each are
keeping their respective bindings alive, the rate of messaging is already
quite high.) 

Then comes the media, which is the crucial point. If the UA wants to keep
addresses derived from STUN or TURN constantly available for use, it has to
generate a lot of messages for keeping the bindings refreshed. That means
generating messages at much higher rate than for SIP/TCP, and is not
feasible with a major part of today's cellular networks/devices. The other
option is then to use STUN or TURN whenever they are needed. If this is done
just before needing to send the SDP (either an offer or an answer), some
delay is introduced in the call setup, which has been another source of
trouble. 

Jonathan already explained that it would be possible to start STUN and/or
TURN before the actual call setup starts, e.g. when the user browses through
the address book. That's an interesting idea. I don't know how well that
would work in practice, probably that depends on how the UI works. (I assume
it would work quite well in today's mobile phones, since in most of them the
user actively enters the address book, and probably quite often actually
makes a call after that.) But on the callee side there typically are no
hints until an INVITE hits the UA. 

Another possibility, also pointed out by Jonathan, is to send the initial
offer/answer without STUN/TURN-based addresses, and collect them in parallel
to that. Then, those addresses could be put into use with a subsequent
offer/answer. I have still to think about how that would best be done taking
also into account the other possible challenges there are in cellular
access/devices, such as resource reservation and the ability to run only a
single codec in the DSP. If ICE with STUN/TURN interleaves nicely with
everything else in the call setup, its use probably would not be a problem.

The thing is that standardization has quite a lot of intertia, and it seems
that TISPAN and 3GPP have already setup their minds about SBCs, for whatever
reasons (SBCs are "available", TURN and ICE are not yet "mature", session
policy work is not well known so SBCs seem to be the only way to enforce
something, ...?). Perhaps this should be a discussion topic in the TISPAN ad
hoc advertised by Dean.

Regards,
	Markus

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Oct 2005 23:09:05 -0500

[email-masked] wrote:

> Hi Paul,
> 
> I try to explain the battery consumption and call setup latency
> concerns in more detail. I'm only talking about messaging related to
> NAT traversal. I don't think there are other reasons for keep-alive
> messages as such.
> 
> I assume that the keep-alives for SIP signaling connection/flow can't
> be avoided. So, the UA has to generate those packets. However, using
> TCP helps there, since hopefully the rate of needed messages is not
> that high. (Although it must be taken into account that if you have
> several applications doing the same, e.g. SIP, "push" e-mail and so
> on, and each are keeping their respective bindings alive, the rate of
> messaging is already quite high.)

Right - thats a good point actually. If you stick with UDP, the cost for 
the signaling keepalives will pretty much be the same as keeping a 
binding alive for a stun/turn binding you've allocated at registration 
time. This changes dramatically with TCP, as you mention. However, 3gpp 
doesnt use tcp, so I'm a bit confused...

> 
> Then comes the media, which is the crucial point. If the UA wants to
> keep addresses derived from STUN or TURN constantly available for
> use, it has to generate a lot of messages for keeping the bindings
> refreshed. That means generating messages at much higher rate than
> for SIP/TCP, and is not feasible with a major part of today's
> cellular networks/devices. The other option is then to use STUN or
> TURN whenever they are needed. If this is done just before needing to
> send the SDP (either an offer or an answer), some delay is introduced
> in the call setup, which has been another source of trouble.
> 
> Jonathan already explained that it would be possible to start STUN
> and/or TURN before the actual call setup starts, e.g. when the user
> browses through the address book. That's an interesting idea. I don't
> know how well that would work in practice, probably that depends on
> how the UI works. (I assume it would work quite well in today's
> mobile phones, since in most of them the user actively enters the
> address book, and probably quite often actually makes a call after
> that.) But on the callee side there typically are no hints until an
> INVITE hits the UA.

But thats OK. When the INVITE hits the UAS, it starts ringing, and then 
immediately begins its stun/turn allocations in parallel with the 
ringing. The entire ice negotiation will likely complete before the user 
even figures out which pocket their cell phone is in...

> 
> Another possibility, also pointed out by Jonathan, is to send the
> initial offer/answer without STUN/TURN-based addresses, and collect
> them in parallel to that. 

Right.

> Then, those addresses could be put into use
> with a subsequent offer/answer. I have still to think about how that
> would best be done taking also into account the other possible
> challenges there are in cellular access/devices, such as resource
> reservation and the ability to run only a single codec in the DSP. If
> ICE with STUN/TURN interleaves nicely with everything else in the
> call setup, its use probably would not be a problem.

The ICE negotiation needs to complete before resource reservation, if 
you want to avoid reserving resources on an address you never use.

> 
> The thing is that standardization has quite a lot of intertia, and it
> seems that TISPAN and 3GPP have already setup their minds about SBCs,
> for whatever reasons (SBCs are "available", TURN and ICE are not yet
> "mature", session policy work is not well known so SBCs seem to be
> the only way to enforce something, ...?). Perhaps this should be a
> discussion topic in the TISPAN ad hoc advertised by Dean.

Sounds like a good idea.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com