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

Rodrigo Pimenta Carvalho pimenta at inatel.br
Wed Dec 30 20:58:24 UTC 2015


Thanks all of you!

I saw this message just now. Now I'm leaving for the day. But I will check these answers next monday.

Happy new year!

Inatel Competence Center
Ph: +55 35 3471 9200 RAMAL 979

De: Jeff Poole <korvus at korvus.net>
Enviado: quarta-feira, 30 de dezembro de 2015 18:20
Para: Rodrigo Pimenta Carvalho; discussion at sipforum.org
Assunto: Re: [SIPForum-discussion] What is the utility of Contact header field?

The Contact header is used in none of these cases -- it is used for routing new, out-of-dialog messages to the same endpoint (and is often rewritten by hosted VoIP providers since it usually involves an address that isn't publicly routable).  Responses to a request follow Via headers, in-dialog requests follow the Route headers set up in the Record-Route headers of the initial request/response, and the ACK is the first message to test that Route (the ACK is routed like a new in-dialog request, so if that doesn't make it to the other side, the Route headers are probably a problem).

If the endpoints are in different networks, you'll want the proxy to stick Via and Record-Route headers in the messages so future messages (responses and in-dialog requests) get routed through the proxy.  If the proxy can handle it, it would be valuable for it to modify the Contact header as well so any out-of-dialog requests will go to the proxy which knows how to talk to each device.

On Wed, Dec 30, 2015 at 10:30 AM Rodrigo Pimenta Carvalho <pimenta at inatel.br<mailto:pimenta at inatel.br>> wrote:


I have a question about the utility of Contact header field, from the point of view of an UAC that needs to answer with SIP ACK after receiving a SIP 200 OK.

Use case 1:

I have a SIP Proxy and 2 softphones registered in such proxy. Softphones and proxy are all located in the same domain (they are directly connected to the same router). So they are in the same local network.

When softphone A calls softpohone B, B answers with SIP 200 OK. When A receives SIP 200 OK, it sends SIP ACK to B. Every thing is ok!

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. When A calls B, B receives the SIP INVITE normally and sends SIP 200 OK to A. In this case, the Contact header field in SIP 200 OK message contains an IP that can't be reached from A. Such IP is the one of softphone B, valid only in the local network. (There is no Stun service being used here).  Every time A receives a SIP message having the Contact header field with a invalid IP, such UAC can't send messages to B, let's say a SIP Bye, or SIP ACK. That is why I suspect the field Contact, sometimes, is read by the UAC when such agent needs to send some message to the other peer. Obviously, in this case, the call fails.

So, is the Contact filed really used/read by an UAC that wants to send a message to the other peer, like a SIP ACK? If not, what is the utility of such field?

Why a SIP ACK can't simply be sent to the same address found in the 'To' header filed?

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?

Any hint will be very helpful!

Thanks alot.

Inatel Competence Center
Ph: +55 35 3471 9200 RAMAL 979
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org<mailto:discussion at sipforum.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20151230/a9a49165/attachment-0002.html>

More information about the discussion mailing list