Subject: [Sip] Was the Translate heade used?

From: "Victor Paulsamy" <[email-masked]>
Date: Fri, 17 May 2002 15:43:16 -0700

In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph last but
one reads, "... From this 200 OK, the STUN agent knows whether or not the
Translate header was used or not."

In the example shown, the STUN agent learnt the public IP by querying STUN
sever and changed the outgoing REGISTER appropriately to reflect this. When
this request reaches the proxy, it checks the sent-by value against the
received address; they are same in this case (hence no received= param).
Say, the proxy supports SIP extensions for NAT. The proxy then rewrites the
Translate header with sent-by value (in this case) which is same as the
original value it carried in it. When returned in the 200 OK response, the
STUN agent sees that, the Translate header has the same value that it put
in, yet, the proxy supports the extension for NAT.

So, the Translate header will be different in the response only when the
client does not rewrite the private IPs with public ones in the request.
Will it not be wrong, per the quoted string, to think that the proxy didn't
use the Translate header?

Regards,

--victor

Victor Paulsamy               E-mail: [email-masked]
Senior Software Engineer      Phone : 650.930.1339 (Direct)
Zapex Technologies, Inc.      Phone : 650.930.1300 (Main)
Mountain View, CA 94043       Fax   : 650.930.1399

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Sat, 18 May 2002 16:04:17 -0400

> received address; they are same in this case (hence no received= param).

No, they wouldn't be the same. The registration is sent over TCP, and
uses a different port than was used to communicate with the STUN server. 

> in, yet, the proxy supports the extension for NAT.

Since the source port is different than the Contact port, the contact
would be rewritten and the client would know.

-Jonathan R.

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

---

From: "Victor Paulsamy" <[email-masked]>
Date: Mon, 20 May 2002 13:55:10 -0700

> uses a different port than was used to communicate with the STUN server.
The example message corresponding to the text is:

   REGISTER sip:provider.com SIP/2.0
   Via: SIP/2.0/UDP 1.2.3.4:5678
   From: sip:[email-masked]
   To: sip:[email-masked]
   Call-ID: 88sdasdlasd0
   Contact: sip:[email-masked]:5678
   Translate: sip:[email-masked]:5678
   CSeq: 88790 REGISTER

Here, the request is indeed, sent using UDP.

> would be rewritten and the client would know.
The source port (10) has been natted to 5678 (hence the port in Contact
holds 5678). The original request sent by the client:

   REGISTER sip:provider.com SIP/2.0
   Via: SIP/2.0/UDP 10.0.1.1
   From: sip:[email-masked]
   To: sip:[email-masked]
   Call-ID: 99asdasd98hnn
   Contact: sip:[email-masked]:5060
   CSeq: 88790 REGISTER

The STUN agent finds out the address and port (as seen by the proxy) by
querying the STUN server; rewrites the message to:

   REGISTER sip:provider.com SIP/2.0
   Via: SIP/2.0/UDP 1.2.3.4:5678
   From: sip:[email-masked]
   To: sip:[email-masked]
   Call-ID: 88sdasdlasd0
   Contact: sip:[email-masked]:5678
   Translate: sip:[email-masked]:5678
   CSeq: 88790 REGISTER

When sent out, the NAT rewrites the source address and port (to
1.2.3.4:5678), finally reached the proxy. At the proxy, it sees a Translate
header hence, finds out a matching Contact header. The host value is
replaced with the sent-by field from the Via (which in this case, is same as
the value that's already present). The port number is replaced with the
sent-by field (again, the same value that's carried in it). Though, the
entire Contact header is rewritten, it results in the very same value it has
already been carrying!