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

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

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

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 31 Oct 2005 14:54:23 +0200

[email-masked] writes:

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

there is very little ietf can do about that.  if it is unfeasibly
expensive or power consuming to keep nat binding open by minimal size
udp packets @ every 15 sec, then there is something wrong with the
pricing models and/or the technology.

i have had flat rate edge service since spring this year and have not
had any problems running sip services (voip, messaging, presence) from
behind nat using a laptop connected to nokia edge phone.  even voice
quality has been good with iLBC codec, but delay, of course, has been
long.

there has been no need to standardize any of the nat traversal
technology that i'm using.  standard, not nat-aware sip ua works just
fine.  smart sip proxy along with media proxy is all that is needed and
the great thing is that such software is available for free.

i expect things to improve greatly next year when i get an all ip flash
ofdm mobile connection and can junk the old gsm/edge (or umts) stuff
(which nokia doesn't currently have).

-- juha