[SIPForum-discussion] What is the utility of Contact header field?

Dale R. Worley worley at ariadne.com
Wed Dec 30 18:47:27 UTC 2015


Rodrigo Pimenta Carvalho <pimenta at inatel.br> writes:
> Use case 2:
>
> The softphone A is located in another network, somewhere on
> Internet. So, from the A's point of view, B and the SIP Prpxy are
> behind a NAT.

Of course, they need not be behind a NAT.  If they aren't behind a NAT,
then there is no problem.

If there is a NAT, the fundamental problem is, "What part of the SIP
system understands that a NAT is present and corrects the SIP messages
for the presence of the NAT?  For instance, UA A could know that there
is a NAT between it and the proxy and it could correct for the NAT.  In
most cases, the proxy is responsible for dealing with the NAT, and is
often configured with knowledge of any NATs between itself and the wider
Internet.

> Use case 3:
>
> The softphone A is still located in another network, somewhere on
> Internet. When A calls B, but no one answers from B, the SIP Proxy
> sends a SIP message to A. Such message doesn't have a Contact header
> filed. In this case, A sends its SIP ACK, but using the same value
> found in the 'To' header field. That is why it seems that when
> 'Contact' is not present, the value from 'To' is used in this case.
> Is the 'Contact' header filed optional? If yes, when it must be
> present?

The difference is that the ACK to a failure response is not handled the
same way as an ACK to a success response.  ACK to a success response is
(or acts very much like) a separate transaction within the dialog
established by the success response, and as such there must be one ACK
sent within each dialog which is established (there is one dialog for
each 2xx response received).  These ACKs use the route set established
by the Record-Route and Contact headers in the 2xx response.

ACK to a failure response is handled on a hop-by-hop basis, with each
intermediate proxy being responsible for routing the ACK onward on the
same path which the original request traveled.  This ACK is formulated
much like the INVITE that it follows.

The difference between these is specified in sections 13 and 17 in RFC
3261.  (Search for occurrences of "Contact" and "ACK" to locate the
details.)

Dale



More information about the discussion mailing list