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

From: [email-masked]
Date: Tue, 1 Nov 2005 22:40:46 +0200

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

> -----Original Message-----
> From: ext Cullen Jennings [mailto:[email-masked]]
> Sent: 29 October, 2005 08:19
> To: Jonathan Rosenberg; Isomaki Markus (Nokia-TP/Espoo)
> Cc: sipping
> Subject: Re: [Sipping] Making SBCs more transparent for NAT traversal
> 
> 
> 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.
> 
> 
> 

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Sun, 27 Nov 2005 22:37:06 -0800

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.

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.

Both ICE and SIP Identity work well for SBC though I often hear that they
don't work. 

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
>