[asterisk-bugs] [JIRA] (ASTERISK-14870) Asterisk does not use the “expires=” from the SIP contact header during registration

Sat Feb 23 22:28:18 CST 2013

    [ https://issues.asterisk.org/jira/browse/ASTERISK-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203408#comment-203408 ] 

Matt Jordan edited comment on ASTERISK-14870 at 2/23/13 10:26 PM:
------------------------------------------------------------------

So, this issue is rather old, but - there actually isn't a bug here.

First, {{chan_sip}} does not support multiple contacts. When it sends a register request to an external registrar, it appends a Contact header with the contact corresponding to its registration. So a registration of:

{noformat}
register => asterisk at registrar.com
{noformat}

will have a contact header of {{ <sip:s@[local_ip]:5060> }}.

If you specify a specific extension to contact, then the contact header will use that:

{noformat}
register => asterisk at registrar.com/1234
{noformat}

will have a contact header of {{ <sip:1234@[local_ip]:5060> }}.

So how does this map to the response?

RFC 3261 states that the 200 OK response to a REGISTER request MUST contain the Contact headers from the request with the expiry that the registrar decided upon. Since we only support a single Contact header, we search through the Contact headers in the response for our Contact header. If we find it, we parse out the expiry; if not, we use what our default was.

The key here is that we take our Contact header that we sent out and look for a Contact header that contains *at least* that value (that is, a substring match). If it differs, we won't use it.

The following log from SVN 1.8 shows this working:

{noformat}
[Feb 23 22:14:55] VERBOSE[522] chan_sip.c: Retransmitting #1 (NAT) to 127.0.0.1:5062:
REGISTER sip:127.0.0.1:5062 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK3e26585c;rport
Max-Forwards: 70
From: <sip:asterisk at 127.0.0.1>;tag=as40b4a36d
To: <sip:asterisk at 127.0.0.1>
Call-ID: 5f707f217a4b90300a384fd735187226 at 10.24.251.166
CSeq: 102 REGISTER
User-Agent: Asterisk PBX SVN-branch-1.8-r381847
Expires: 120
Contact: <sip:1234 at 127.0.0.1:5060>
Content-Length: 0

---
[Feb 23 22:14:55] DEBUG[522] chan_sip.c: Trying to put 'REGISTER si' onto UDP socket destined for 127.0.0.1:5062
[Feb 23 22:14:55] VERBOSE[522] chan_sip.c: 
<--- SIP read from UDP:127.0.0.1:5062 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK3e26585c;rport
From: <sip:asterisk at 127.0.0.1>;tag=as40b4a36d
To: <sip:asterisk at 127.0.0.1>;tag=542SIPpTag011
Call-ID: 5f707f217a4b90300a384fd735187226 at 10.24.251.166
CSeq: 102 REGISTER
Contact: <sip:1234 at 127.0.0.1:5060>;expires=90
Content-Type: application/sdp
Content-Length: 0

<------------->
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  0 [ 14]: SIP/2.0 200 OK
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  1 [ 60]: Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK3e26585c;rport
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  2 [ 45]: From: <sip:asterisk at 127.0.0.1>;tag=as40b4a36d
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  3 [ 46]: To: <sip:asterisk at 127.0.0.1>;tag=542SIPpTag011
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  4 [ 55]: Call-ID: 5f707f217a4b90300a384fd735187226 at 10.24.251.166
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  5 [ 18]: CSeq: 102 REGISTER
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  6 [ 45]: Contact: <sip:1234 at 127.0.0.1:5060>;expires=90
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  7 [ 29]: Content-Type: application/sdp
[Feb 23 22:14:55] DEBUG[522] chan_sip.c:  Header  8 [ 17]: Content-Length: 0
[Feb 23 22:14:55] VERBOSE[522] chan_sip.c: --- (9 headers 0 lines) ---
[Feb 23 22:14:55] DEBUG[522] chan_sip.c: = Looking for  Call ID: 5f707f217a4b90300a384fd735187226 at 10.24.251.166 (Checking To) --From tag as40b4a36d --To-tag 542SIPpTag011  
[Feb 23 22:14:55] DEBUG[522] chan_sip.c: ** SIP TIMER: Cancelling retransmit of packet (reply received) Retransid #3
[Feb 23 22:14:55] DEBUG[522] chan_sip.c: Stopping retransmission on '5f707f217a4b90300a384fd735187226 at 10.24.251.166' of Request 102: Match Found
[Feb 23 22:14:55] DEBUG[522] chan_sip.c: Registration successful
[Feb 23 22:14:55] DEBUG[522] chan_sip.c: Cancelling timeout 2
[Feb 23 22:14:55] DEBUG[522] chan_sip.c: SIP Registry 127.0.0.1: refcount now 2
[Feb 23 22:14:55] DEBUG[522] chan_sip.c: SIP Registry 127.0.0.1: refcount now 1
[Feb 23 22:14:55] VERBOSE[522] chan_sip.c: Scheduling destruction of SIP dialog '5f707f217a4b90300a384fd735187226 at 10.24.251.166' in 32000 ms (Method: REGISTER)
[Feb 23 22:14:55] NOTICE[522] chan_sip.c: Outbound Registration: Expiry for 127.0.0.1 is 90 sec (Scheduling reregistration in 75 s)
{noformat}

This code is pretty ancient. As in, r5841 by kpfleming :-)  So it's actually been working for quite some time.

So what happened in the log attached to this issue?

Well, compare the request and response contact headers:

*Our Request*:
{noformat}
[Sep 22 22:33:11] DEBUG[3602] chan_sip.c:  Header 10 [ 40]: Contact: <sip:uxxxxxxxxx at ax.xx.xxx.xxx>
{noformat}

*Registrar Response*:
{noformat}
[Sep 22 22:33:11] DEBUG[3602] chan_sip.c:  Header  1 [ 50]: Contact:sip:uxxxxxxxxx at ax.xx.xxx.xxx;expires=3170
{noformat}

The registrar response is missing {{<}} and {{>}}. We care about those. (The lack of a space after the header's {{:}} may or may not be problematic as well).

Closing this out, but hopefully this will be helpful to anyone else who runs into this problem.

      was (Author: mjordan):
    So, this issue is rather old, but - there actually isn't a bug here.