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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sat, 29 Oct 2005 19:05:26 +0100

In line.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Jonathan Rosenberg
> Sent: 28 October 2005 16:32
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Making SBCs more transparent for NAT traversal
> 
<snipped>
> 
> 
> > 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.
> 
> The latest ICE spec talks about how to use ICE and not see 
> any increase 
> in call setup. The key idea is to do the allocations based on 
> UI hints 
> on the originator. For example, on a mobile, it would be when 
> the user 
> enters there address book or begins entering digits on the 
> keypad. Even 
> if you dont do that, there are optimizations you can make in ice 
> processing that will send an immediate invite without any stun/turn 
> allocations; those would be done in parallel with the invite, 
> and then 
> only added in an UPDATE if the native IP/port didnt't 
> immediately work.
> 
The key justification for the user entering destination data before hitting the send key in 3GPP is to save bringing up the signalling channel to activity before the send key is hit. Obviously this dates back to the circuit switched days before IMS, but similar considerations of radio bandwidth availability still apply. This using ICE before the user has hit the send key defeats the object. Now if we could do it at registration...

<snipped>
> 
> > 
> > (Another thing I'm worried is that e.g. in 3GPP and ETSI TISPAN SBCs
> > seem to be the *only* standardized mechanism for NAT traversal. 
> 
> Yes, I'm worried about this too. For TISPAN especially this seems a 
> mistake. ICE, when used with session policy, gives you all of the 
> control that an SBC can give, but in a way that has none of 
> its drawbacks.
> 
Similar concerns. The only thing I have managed to retain in the specs is the ability to do other mechanisms if they are available. Not specified - out of scope of release 1.

> Thanks,
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Sat, 29 Oct 2005 14:20:15 -0500

I fail to understand the 3GPP focus on frugal signaling bandwidth, since it
is advertised as a high speed service.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Drage, Keith (Keith)
Sent: Saturday, October 29, 2005 1:05 PM
To: Jonathan Rosenberg; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal

In line.

regards

Keith

<snipped>
> only added in an UPDATE if the native IP/port didnt't 
The key justification for the user entering destination data before hitting
the send key in 3GPP is to save bringing up the signalling channel to
activity before the send key is hit. Obviously this dates back to the
circuit switched days before IMS, but similar considerations of radio
bandwidth availability still apply. This using ICE before the user has hit
the send key defeats the object. Now if we could do it at registration...

<snipped>
> control that an SBC can give, but in a way that has none of 
Similar concerns. The only thing I have managed to retain in the specs is
the ability to do other mechanisms if they are available. Not specified -
out of scope of release 1.

---

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

inline.

Drage, Keith (Keith) wrote:

>> The latest ICE spec talks about how to use ICE and not see any
>> increase in call setup. The key idea is to do the allocations based
>> on UI hints on the originator. For example, on a mobile, it would
>> be when the user enters there address book or begins entering
>> digits on the keypad. Even if you dont do that, there are
>> optimizations you can make in ice processing that will send an
>> immediate invite without any stun/turn allocations; those would be
>> done in parallel with the invite, and then only added in an UPDATE
>> if the native IP/port didnt't immediately work.
>> 
> 
> The key justification for the user entering destination data before
> hitting the send key in 3GPP is to save bringing up the signalling
> channel to activity before the send key is hit. Obviously this dates
> back to the circuit switched days before IMS, but similar
> considerations of radio bandwidth availability still apply. This
> using ICE before the user has hit the send key defeats the object.

As you say, things are different with IP. I'm curious if this remains an 
issue. How frequently does a user enter digits or go into the address 
book, and not make a call, and what are the real costs associated with 
setting up a signaling channel?

> Now if we could do it at registration...

You could allocate the stun/turn addresses at any time, but the problem 
is keeping the bindings alive until the call is set up. That will keep 
the phone active continuously which seems like a non-starter.

> 
> <snipped>
> 
>>> (Another thing I'm worried is that e.g. in 3GPP and ETSI TISPAN
>>> SBCs seem to be the *only* standardized mechanism for NAT
>>> traversal.
>> 
>>  control that an SBC can give, but in a way that has none of its
>> drawbacks.
>> 
> 
> Similar concerns. 

Oh? TISPAN is worried about the cost of setting up signaling channels on 
a wireless network?

-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