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>
This is incorrect. The expires parameter is a *header* parameter, not a
URI parameter. It ought to be:
Contact: <sip:[EMAIL PROTECTED]>;expires=3600
> Then UA1 receives the 200 OK response:
> 200 OK
> Contact: <sip:[EMAIL PROTECTED];expires=3600>
This is incorrect. It indicates that a middlebox (e.g. an SBC) has been
messing with the contact value in the REGISTER. The Contact in the
response should be the same as the one in the request.
If an SBC is going to interfere in this way, then it also has the
responsibility to make a corresponding adjustment to the response,
reversing the damage it has done. So the response ought to again be:
200 OK
Contact: <sip:[EMAIL PROTECTED]>;expires=3600
This kind of broken behavior by an SBC will break a number of things.
If there is a NAT, then the correct solution is for UA1 to use ICE, or
at least STUN, to discover its NATed address. Then UA1 can put the
correct NATed value in the REGISTER, and so will recognize it in the
response. E.g.
REGISTER sip:serviceprovider.com
To: <sip:[EMAIL PROTECTED]>
From: <sip:[EMAIL PROTECTED]>
Contact: <sip:[EMAIL PROTECTED]>;expires=3600
200 OK
Contact: <sip:[EMAIL PROTECTED]>;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>
Same story here.
If there was a "correct" SBC in the path it would fixup one or both
contacts in the response:
200 OK
Contact: <sip:[EMAIL PROTECTED]:15060>;expires=3500
Contact: <sip:[EMAIL PROTECTED]>;expires=3600
OR
200 OK
Contact: <sip:[EMAIL PROTECTED]>;expires=3500
Contact: <sip:[EMAIL PROTECTED]>;expires=3600
I put "correct" in quotes because there really is no well defined
"correct" behavior here.
>>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?
If you use a contact behind a NAT, and an SBC fixes it up, and the SBC
acts as I describe, then both values are the same, and you use your own.
If the situation is as you describe above then you should still use your
own. (The SBC should hopefully fix it up again.) But you are screwed
because you can't recognize your own entry in the register response and
so don't know when your registration will expire.
If you use ICE or just STUN to discover your address on the other side
of the NAT, and you use that in the REGISTER, then you should also use
that in the Contacts of your requests.
Paul
> 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
