Subject: Re: [Sip] Simple procedure for NAT traversal for a UA (fwd)

From: Aymeric Moizard <[email-masked]>
Date: Thu, 1 Feb 2007 11:47:38 +0100 (CET)

On Wed, 31 Jan 2007, Frank W. Miller wrote:

> NAT Traversal Procedure for User Agents
> 
> 
> I've implemented a fairly simple but general mechanism for doing NAT
> traversal with a User Agent.
> 
> 1) Open a UDP port for SIP on port number 5060
> 2) Open a UDP port for RTP on port number 5004
> 3) Send a STUN binding request out the SIP port
> 4) Send a STUN binding request out the RTP port
> 5) Record the IP address and UDP port number returned in the MAPPED-ADDRESS
> attribute of the binding request response received on the SIP port (call
> this the visible SIP endpoint analagous the the ICE server reflexive address)
> 6) Record the IP address and UDP port number returned in the MAPPED-ADDRESS
> attribute of the binding request response received on the RTP port (call
> this the visible RTP endpoint)
> 7) Use the visible SIP endpoint addresses in things like the Contact
> header address and the Via header line in outbound requests
> 8) Use the visible RTP endpoint addresses in the SDP offer for session
> establishments
> 
> This procedure seems really simple to me and seems to work well with the
> limited testing I've done.  It does require the UA to multiplex STUN on
> both the SIP and RTP ports but it only requires binding requests so,
> again its pretty simple.  This procedure is certainly a lot simpler than
> ICE but does not take into account relay servers.

The procedure you are describing does not provide a 100% reliable way to
get media connection established.

ICE is needed for many reasons:
* your MAPPED-ADDRESS/STUN will often provide wrong "port" number.
* it's very usefull to provide many options for direct media connection.
* ICE allow to exchange a media-relay address: this is helpfull when
   no direct connection is found because you know that when direct
   connection is not possible, 100% of calls will have media connection
   anyway.

> I would be curious on anyone else's experience with a procedure similar
> to this.  It sort of seems to take bits and pieces from things in various 
> drafts.

ICE is the only reliable way to build an *optimized* service: ie a service 
which not provide media relay if not needed.

Aymeric MOIZARD / ANTISIP
amsip - http://www.antisip.com
osip2 - http://www.osip.org
eXosip2 - http://savannah.nongnu.org/projects/exosip/

> Thanks,
> FM
> 
> 
> 
> _______________________________________________
> 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
> 
>

_______________________________________________
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