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

From: Juha Heinanen <[email-masked]>
Date: Tue, 1 Nov 2005 12:23:08 +0200

Juha Heinanen writes:

 > 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 would just like to clarify that it is the proxy that sends the udp
packets send to keep the nat binding alive.  the mobile terminal only
needs to RECEIVE them, not send anything unless there is real sip/media
traffic flow.

radio on my desk runs on same batteries for months and it even has
amplifier in it.  so there should be no power issue with mobile
terminals with the keepalives unless the their radio protocol is really
screwed up.

-- juha

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 1 Nov 2005 18:56:16 -0600

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

As Adam says, I'm not a valid use case for anything, but I probably  
fiddle with my phone, do stuff to the address book, or just plain-old  
accidentally press keys five or ten times as often as I actually make  
a call or fire up the browser. If it turned on the radio every time,  
I don't think my battery would last past lunch.

And I'm not sure we'd even want the wireline components being tickled  
that often, especially with preconditions and advance-reserved QoS.

--
Dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 02 Nov 2005 10:13:26 +0200

Hi,

> This changes dramatically with TCP, as you mention. However, 3gpp 
> doesnt use tcp, so I'm a bit confused...

Note that the 3GPP specs do not keep vendors from using TCP. It is true, 
however, that many deployments use UDP at this point.

Cheers,

Gonzalo

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Nov 2005 12:14:39 -0000

3GPP specifications require exactly the same transport protocol (UDP/TCP/SCTP) support and usage as RFC 3261.

3GPP cannot answer for vendors who do not follow the specifications!

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Gonzalo Camarillo
> Sent: 02 November 2005 08:13
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sipping] Making SBCs more transparent for NAT traversal
> 
> 
> Hi,
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 5 Nov 2005 20:20:07 +0100

Hi, 

>>I asked how the NAT would know which packages are 
>>"keepalive" ones. Even  > if you standardize some kind of 
>>"keepalive protocol", the NAT still only  > sees IP packages, 
>>doesn't it?
>i was talking about mobile operator NAT that usually is 
>bundled with GGSN.  sure ericsson and nokia must be able to 
>implement such a NAT, if you are able to implement IMS.

No doubt about it. 

I just wanted to clarify what YOU meant by "mobile operator NAT",
because it didn't sound like standard NAT functionality to me.

Regards,

Christer

---

From: [email-masked]
Date: Mon, 28 Nov 2005 13:17:08 +0200

> From: ext Cullen Jennings [mailto:[email-masked]]
> Sent: 28 November, 2005 08:37
> To: Isomaki Markus (Nokia-TP/Espoo); Jonathan Rosenberg; Alan
> Hawrylyshen
> Cc: sipping
> Well one of the things I thought they did turned out I was 
> wrong on outbound
> so it has shaken my faith in information I had but .... 
> adding Alan here as
> he was the person I was talking to about this.
> 
> In theory, a SBC could tell a UA behind a NAT to send RTP to 
> port X on the
> SBC then reinvite to send to port Y on the SBC, and if the 
> source port had
> not changed, it means the UA is behind a NAT that is port 
> preserving and a
> media relay is not needed. At that point the SBC could 
> reinvite the media to
> no longer go through a media relay.
> 

Instead of mid-call procedures like this, would it make sense for the SBC to find out during registration time what type of NAT the UA is behind? I suppose STUN could be used for that. Or is it so that to be sure you have to determine this separately for every media stream? 

> I think that some SBC vendors had a "media path optimization" 
> approaches
> that used SIP signaling to decide if a media relay was needed or not.
> 
> What I was talking about when I mentioned this was once your 
> SBC does ICE,
> on side A it can advertise candidates that are the far end UA 
> of side B. If
> that candidate works, then the SBC is not a media relay and 
> if it does not
> work, well you fall back to candidates where the SBC is a media relay.
>

This was also my original idea, i.e. UA's using ICE for advertising candidates and doing connectivity checks, but allowing the SBC to add its own address as a candidate too. That candidate would be used throughout the call only if the others don't work. So, it would be similar to TURN, but embedded in session setup itself.
 
> Both ICE and SIP Identity work well for SBC though I often 
> hear that they
> don't work. 
> 

I think many things can be made to work well with SBCs, if SBCs are implemented in a correct way. 

Markus

> 
> 
> 
> On 11/1/05 12:40 PM, "[email-masked]" 
> <[email-masked]>
> wrote:
> 
> > Cullen,
> > 
> > Can you elaborate on this a bit? Although you say that SBCs 
> use STUN and ICE I
> > assume you mean that the UA uses STUN and ICE, and based on 
> that the SBC knows
> > when it can stay out of the media path. Or how does it work?
> > 
> > Markus
> > 
> >> From: ext Cullen Jennings [mailto:[email-masked]]
> >> Sent: 29 October, 2005 08:19
> >> To: Jonathan Rosenberg; Isomaki Markus (Nokia-TP/Espoo)
> >> Cc: sipping
> >> On 10/28/05 8:31 AM, "Jonathan Rosenberg" 
> <[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.
> >>> 
> >>> Well, thats debatable.
> >> 
> >> I like to point out that several of the commercially
> >> available SBCs do use
> >> things like STUN and ICE to do media optimization to remove
> >> themselves out
> >> of the media path when they are non needed for NAT traversal.
> >> This improves
> >> the voice quality, reduces the bandwidth the operator needs.
> >> Even when using
> >> SBCs, we still need STUN/ICE.
> >> 
> >> 
> >> 
>