Subject: Re: [Sip] Symmetric NAT issue

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Sep 2004 21:08:47 -0400

Christian Stredicke wrote:

> IMVHO SBC that use ICE are a smart alternative to using TURN. 

I don't really understand what this means. I would not expect an SBC to 
implement ICE, in the sense that it would do the p2p STUN pings, 
connectivity checks, etc., or are you proposing that it does?

Also, ICE makes use of TURN, to deal with the symmetric NAT case. SO I 
don't understand what you mean when you say ICE is an alternative to 
TURN. Can you explain?

UA that
> are not aware of ICE, STUN, TURN or NAT will run media through the B2BUA
> while ICE-aware devices can bypass them.

That I agree with.

> IMEHO ist much easier to
> implement STUN/ICE than TURN (well, we did/tried it) and it solves the
> problem with the "dumb" devices.

ICE without TURN will not help in the symmetric NAT case.

> Paired with DNS SRV and STUN its
> possible to automatically detect the nearest SBC, in case the SBC is
> necessary to relay media for symmetrical NAT.

Detect an SBC? I don't follow.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christian Stredicke" <[email-masked]>
Date: Fri, 1 Oct 2004 08:53:25 +0200

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> 

In ICE we are talking about possible communication addresses, right? One
possible address is the private address, another adress that has been
allocated via a STUN packet sent out to a STUN server. The trick is that
AFTER the UA has created the SDP with these possible addresses and sent
them to the SBC, the SBC ADDS another communication address:

UA sends SDP:

v=0
o=17187614121 8000 8000 IN IP4 <private ip address> 
s=SIP Call 
c=IN IP4 <private ip address> 
t=0 0 
m=audio 49242 RTP/AVP 0 
a=rtpmap:0 PCMU/8000
a=alt: <private ip address>
a=alt: <stun ip address>

The SBC allocates RTP relay ports and MODIFIES the SDP:

v=0
o=17187614121 8000 8000 IN IP4 <SBC ip address> 
s=SIP Call 
c=IN IP4 <SBC ip address> 
t=0 0 
m=audio 49242 RTP/AVP 0 
a=rtpmap:0 PCMU/8000
a=alt: <private ip address>
a=alt: <stun ip address>
a=alt: <SBC ip address>

The STUN packets and everything else is just forwarded, the SBC does not
implemenent any logic for that. That means when ICE tries the
connections, it will give a realistic picture of the delay. If the RTP
has not started yet and the SBC could not get the IP/port of the
symmetrical NAT, it will not relay that packet. But thats no problem as
the primary contact is the SBC allocated port (c-line).

> don't understand what you mean when you say ICE is an alternative to 
Tried to explain above.
> ICE without TURN will not help in the symmetric NAT case.

See above.

> Detect an SBC? I don't follow.

Assume that you are a global operator with customers in USA, Australia,
Europe and China. Customers in China expect that the delay when talking
in China is reasonable (no relaying via USA). That means the UA must use
the China SBC for communication. You can detect that by probing the
possible SBC with STUN packets, the addresses are listed in DNS SRV. You
just send a packet to all of them and pick the one with the shortest
delay.

This is necessary because you cannot for the INVITE to all DNS SRV
listed SBC. Here TURN would be better, cause you can allocate ports on
all TURN servers and ICE will then find the shortest delay.

Take a look at http://snom.com/download/natf_205.pdf. Henry forbid me to
use the three bad letters S-B-C... 

Keep smiling, CS