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

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 31 Oct 2005 16:16:45 +0100

Hi,

I have to admit I haven't followed this whole discussion in detail, but
I would just to give a few clarifications. 

NOTE: The purpose of this mail is NOT to enter the debate whether SBCs
are needed or not, how much they "break" SIP etc etc etc, but ONLY to
give a little background and status on the work on NAT support in
TISPAN/3GPP.

First, I would also like to thank Markus for the initial e-mail. I think
it brings up interesting issues.

The "SBC" in TISPAN/3GPP is devided into signalling entities and media
entities. For UNI, the signalling entity is actually the P-CSCF (which
the signalling will traverse anyway), with some extended B2BUA
functionality. For each call, it is then decided whether the media
entity (called BGF in TISPAN) needs to be inserted in the media path,
e.g. to support NAT, IP version interworking, and/or due to some QoS
related functions. If none of that is needed, the P-CSCF will act like a
"normal" proxy, and the BGF may not be inserted in the media path.

(There ARE, however, other standardization bodies defining dedicated
"SBC" entities, but I don't have detailed information about that work.)

TISPAN chose to describe one NAT traversal solution for Release 1. BUT,
TISPAN does NOT forbid other mechansims from being used - and I believe
that is also mentioned in the appropriate specifications (I wonder if
anyone has read them...). TISPAN simply chose to describe this specific
mechanissim for Release 1. I am sure people will start looking at other
solutions when the work on Release 2 starts. So, therefor I don't really
understand comments like "TISPAN and 3GPP have already made up their
mind".

I also think it is important to mention that TISPAN/3GPP today talks
about two different NAT scenarios. One scenario is the so called "hosted
NAT" scenario, where one or more SIP unaware NAT(s) are located in the
path between the terminal and the P-CSCF. The other scenario is where
the P-CSCF/BGF acts like a SIP aware NAT itself (SIP-ALG). I assume the
discussion here has been mostly focused on the "hosted NAT" scenario.

When we talk about the SIP-ALG NATs, it is important to remember that
there may be multiple SIP-ALG NATs between the two terminals. TISPAN/3GG
also defines NNI SIP-ALG NAT entities, which may be located between
networks. 

And, when we talk about "hosted NAT", there may be one or more NATs
between the UE and P-CSCF both on the originating and the terminating
side. I assume all the alternative solutions take that into
consideration, but just to keep in mind.

When we talk about the mechanism of keeping NAT bindings open, I think
it is a separate issue. For SIP-ALG NATs, there may not be a need for
any UDP packages every 15 seconds, because the controller can keep the
NAT binding open as long as the session exists (and, in order to prevent
"hanging" sessions the SIP session-timer mechanism, or something
similar, can be used). 

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 31. lokakuuta 2005 10:56
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal
> 
> Henry,
> 
> "High speed" is a relative concept. 3G is certainly high 
> speed compared to GPRS or similar radio networks, but it is 
> very low speed compared to DSL or cable or even to 
> short-range radios such as 802.11. I don't think the main 
> benefit of 3G to be excessive speed, but the coverage it can 
> provide and the possibility to integrate it into a handheld 
> device (which is pretty much related to the power consumption 
> issue I raised).
> 
> Personally I belive that the quest for saving every possible 
> bit is sometimes a bit exaggerated. It comes from the current 
> pricing models of the cellular operators, and based on those 
> the conclusion is that almost any service is too expensive. I 
> would hope that once the usage increases, also the price per 
> bit will come down. While I think it is important to improve 
> some things such as SIP events (which is currently consuming 
> way too much bandwidth than is necessary), the main focus 
> should be on minimizing the critical latencies (such as call 
> setup time) and taking battery consumption issues into 
> account (not feasible to send something every 15 sec. for 24 
> hours a day etc.).  
> 
> Markus  
> 
> 
> > -----Original Message-----
> > From: ext Henry Sinnreich [mailto:[email-masked]]
> > Sent: 29 October, 2005 22:20
> > To: 'Drage, Keith (Keith)'; 'Jonathan Rosenberg'; Isomaki Markus
> > (Nokia-TP/Espoo)
> > Cc: [email-masked]
> > Subject: RE: [Sipping] Making SBCs more transparent for NAT 
> traversal
> > 
> > 
> > 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
> > 
> > > -----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
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> 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