Subject: RE: [Sip] RE: Was the Translate header used?

From: "Victor Paulsamy" <[email-masked]>
Date: Tue, 4 Jun 2002 10:59:11 -0700

I'm re-posting to get some response:

 > Victor Paulsamy wrote:
 > >
 > > 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).
 >
 > > Jonathan Rosenberg wrote:
 > 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.
 >
Victor Paulsamy wrote:
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.
 
 > > 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.
 >
> Jonathan Rosenberg wrote:
> > Since the source port is different than the Contact port, the contact
> > would be rewritten and the client would know.
> >
Victor Paulsamy wrote:

 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!

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: Wed, 19 Jun 2002 02:23:38 -0400

inline.

Victor Paulsamy wrote:
>>>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).
> 

Hmm. Don't know why I thought it was sent over TCP. That is a valid mode 
of operation, but it doesn't appear to be whats here.

>>>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
> replaced with the sent-by field from the Via (which in this case, is
> same as
> entire Contact header is rewritten, it results in the very same value it
> has
> already been carrying!

Right. But, the STUN Agent can know whether the proxy translated the 
contact by the mere presence of the Translate header. If the proxy 
didn't support the extension, there would be no translate header.

To be honest, looking back at this flow, the Translate header is not 
needed here at all. STUN provides an alternative. I'm not sure what I 
was thinking.....

-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