[Sip] Translate header in draft-ietf-sip-nat-00.txt

[Rohan Mahy <[e-mail]>]

Hi,

In draft-ietf-sip-nat-00.txt, Jonathan describes a new header called the 
Translate header that is used to translate the Contact in a REGISTER into 
the address received for that Contact in the received and rport Via parameters.

Based on my quick read of the draft, it seems that Registration Servers 
which are not co-located with the "first proxy", are unable to perform the 
proper Translate magic.

UA --- NAT --- Proxy ----Registration Server

To get around this problem (if it exists), and to avoid adding an extra 
header, I propose instead that the UA "lie" in its REGISTER.  The UA would 
generate a new Contact from its public IP address and port if it discovers 
received and rport parameters in its own Via header.  For example...

REGISTER domain.org SIP/2.0
Via: 10.1.1.1:5060;rport
To: [e-mail]
From: [e-mail]
Contact: user@10.1.1.1:5060

SIP/2.0 200 OK
Via: 10.1.1.1:5060;received=77.68.24.3;rport=8734
...

REGISTER domain.org SIP/2.0
Via: 10.1.1.1:5060;rport
To: [e-mail]
From: [e-mail]
Contact: user@77.68.24.3:8734

Unfortunately, if the first proxy after the NAT is actually a cluster of 
load-sharing proxies we have a problem.  (I believe this was part of the 
problem Translate attempts to solve). Consider a new INVITE coming from the 
world:
		

           /-- proxy 1
          /
UA -- NAT --- proxy 2    <---- INVITE [e-mail]    UA
          \
           \-- proxy 3

Depending on the type of NAT, three things may happen:

1) For a fully promiscuous cone NAT, the INVITE from any of the proxies 
will arrive safely at the UA.

2) For a partial cone NAT, the UA will only receive the INVITE if it is 
delivered by the proxy that last handled registrations.

The UA could insure that a cone mapping is open by sending an OPTIONS or 
other SIP request to each member of the cluster.  Discovering the cluster 
members is the tricky part.  DNS may provide enough information, but it is 
hard to determine topology and intent from DNS.

cluster.proxies.com	IN A	12.1.1.1
			IN A	12.1.1.2
			IN A	12.1.1.3

3) For a fully symetric NAT, the UA has several ugly choices:
a) keep a translation to each proxy and register from each translated address
b) register yourself to a specific proxy (if this even works):

	REGISTER sip:domain.org
	From: [e-mail]
	Contact: user@12.1.1.2:5060	

	REGISTER sip:12.1.1.2
	From: user@12.1.1.2
	Contact: user@77.68.24.3:8734

c) register yourself with a preloaded loose Route (illegal and YUCK!)

	REGISTER
	Contact: user@77.68.24.3:8734?Route=12.1.1.2:5060;route-type=loose

d) use some shared-IP address load-sharing device in front of the proxies.

Any thoughts?

thanks,
-rohan



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