That is an interesting, but nonstandard (and incorrect), registrar  
behavior. Are you actually encountering that somewhere?

If the UA wants a contact bound to its address as it appears on the  
other side of a NAT, it needs to use
STUN to discover it and place it in the Contact in the Register request.

RjS

On Jun 21, 2007, at 9:07 PM, Richard wrote:

>
> Suppose UA1, which is behind NAT, is registering a public SIP server.
> UA1
> (only necessary headers are shown)
> REGISTER sip:serviceprovider.com
> To: <sip:[EMAIL PROTECTED]>
> From: <sip:[EMAIL PROTECTED]>
> Contact: <sip:[EMAIL PROTECTED];expires=3600>
>
> Then UA1 receives the 200 OK response:
> 200 OK
> Contact: <sip:[EMAIL PROTECTED]:15060;expires=3600>
>
> Then UA2, which is located in other machine and is also behind NAT,
> registers to the same public SIP server using the same AOR.
>
> REGISTER sip:serviceprovider.com
> To: <sip:[EMAIL PROTECTED]>
> From: <sip:[EMAIL PROTECTED]>
> Contact: <sip:[EMAIL PROTECTED];expires=3600>
>
> Then UA2 receives the 200 OK response:
> 200 OK
> Contact: <sip:[EMAIL PROTECTED]:15060;expires=3500>
> Contact: <sip:[EMAIL PROTECTED]:25060;expires=3600>
>
>> From UA2 point of view, it does not know which contact header it is
> belong to.
>
> Another question is: would I use the contact header (with mapped  
> public
> address) from the register 200 OK response to put in creating INVITE
> message instead of consulting the STUN server if the UA is behind NAT?
>
> Richard
> Senior Engineer
> ASTRI
>
>
>
> This message (including any attachments) is for the named addressee 
> (s)'s use only. It may contain
> sensitive, confidential, private proprietary or legally privileged  
> information intended for a
> specific individual and purpose, and is protected by law. If you  
> are not the intended recipient,
> please immediately delete it and all copies of it from your system,  
> destroy any hard copies of it
> and notify the sender. Any use, disclosure, copying, or  
> distribution of this message and/or any
> attachments is strictly prohibited.
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to