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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Nov 2001 12:33:36 -0500

I have revved this draft.

responses inline.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 9:03 PM
> To: [email-masked]
> Subject: [Sip] Translate header in draft-ietf-sip-nat-00.txt
> 
> 
> 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),

It does. 

 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: [email-masked]
> From: [email-masked]
> Contact: [email-masked]: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: [email-masked]
> From: [email-masked]
> Contact: [email-masked]: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 [email-masked]    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: [email-masked]
> 	Contact: [email-masked]:5060	
> 
> 	REGISTER sip:12.1.1.2
> 	From: [email-masked]
> 	Contact: [email-masked]:8734
> 
> c) register yourself with a preloaded loose Route (illegal and YUCK!)
> 
> 	REGISTER
> 	Contact: 
> [email-masked]: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?

My preference is a combination of the things you have proposed.

The Translate header remains, but instead, the registrar uses the rport and
received param from the bottom-most via header, rather than the source
IP/port. This will therefore work when there are proxies between the UA and
the registrar.

I prefer to keep the Translate header, since it then makes it explicit about
what the problem is. The network can implement a solution to handle the
symmetric case in any way it likes. Your solutions above all have the client
deciding how to force routing through its outbound proxy, but I think its a
server problem. Its a server problem since the solution depends on the
architecture and design of the network. One implementation might store the
outbound proxy IP as part of the user profile, and program their proxies to
route requests there. Another implementation might store a contact in a
loose route format, as you have suggested. In the case where only a single
IP address is provided, and a load balancer is used, entirely different
solutions may be required.

I do concede that Translate is definitely ugly. One of the interesting
problems it introduces is this: when there are multiple UA's registered, how
does a particular UA know which of the contact addresses in the 2xx is the
translated one? It needs to know for a variety of reasons (like, inserting
that contact into the contact in an INVITE or 2xx to INVITE). Therefore, I
think we will need the Translate header in the response to contain the
translated URL (it would also be in the contact header). Ugly also, but it
works. I welcome alternate suggestions.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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