more inline. Rohan Mahy wrote:
Hi, This draft is currently blocking on a number of other items. TheRight.
authors are aware that many changes are needed to the draft, but until
these other items are unblocked the draft is unlikely to get much
attention.
Specifically, some more work needs to be done on connection reuse, in addition to lots of changes due to the history of TURN/SPAN since the publication of this doc.
However, to address your particular question:
On Thursday, December 12, 2002, at 09:36 PM, Rahul Gulati wrote:Firstly, this text was contributed by one of my co-authors. I will admit that I am not fond of the solution, as it describes a lot of "proprietary" hacks, including this one.
Hi, All, I am again reposting this query as I didnt get reply to the previous
one. From draft-ietf-sipping-nat-scenarios-00, page 47-48: In the example configuration shown in Figure 22, the signaling path is
established when the SIP UA's register with the corresponding
Proxy/Register (Signaling server). *The SIP REGISTER message contains
an extension tag carried in the Proxy-Require header, indicating to
the Proxy that the client is behind a NAT* (Note: the client or the
Proxy does not care about the type of NAT, as the same solution
applies to all types). This packet is NAT-ed by the Enterprise NAT
with a new source IP address and port. If the Proxy supports the
extension tag, it creates an association between the IP address and
port from which the packet arrived and the actual address of the user.
The response to the Registration message is sent to this IP address
and port (not to the Contact address in the REGISTER). My question here is : *Why do we need this extension tag?*
The reason for this tag is bcause the registrar is doing something non-standard. Its looking at the source IP/port instead of the Contact header field.
That doesn't work. Third party registrations have this property, yet there, you don't want to use the source IP/port. This was the reason I had proposed the "contact cookie" in early versions of draft-ietf-sip-nat. Ultimately, this functionality will be provided by the connection reuse mechanism whose requirements are being spec'ed out in:--We can know if a UA is behind the NAT by verifying if the Src IP
address ( NATed incase of NAT ) is the same as the IP address
mentioned in the Contact header of the REGISTER message.
http://www.ietf.org/internet-drafts/draft-ietf-sipping-connect-reuse-reqs-00.txt
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
