[Home]

Summary:ASTERISK-22946: Local From tag regression with sipgate.de
Reporter:Stephan Eisvogel (eisvogel)Labels:
Date Opened:2013-12-07 15:11:42.000-0600Date Closed:2014-01-14 12:12:01.000-0600
Priority:CriticalRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:SVN Frequency of
Occurrence
Constant
Related
Issues:
is caused byASTERISK-12117 chan_sip creates a new local tag (from-tag) for every register message
Environment:Ubuntu 12.04 x64; sipgate.de basicAttachments:( 0) ast11-crypto-override.patch
( 1) ASTERISK-22946.patch
( 2) sipgate.pcap
Description:Commit r402605 (chan_sip: keep same local (from) tag for outgoing register requests) causes registration with German sipgate.de to fail with these errors on console:

[Dec  7 21:10:12] NOTICE[11773]: chan_sip.c:15135 sip_reg_timeout:    -- Registration for 'xxxxxxx@sipgate.de' timed out, trying again (Attempt #2)
[Dec  7 21:10:18] WARNING[11773]: chan_sip.c:4176 retrans_pkt: Retransmission timeout reached on transmission 30152ad126372ebf6305891d1c567c01@sipgate.de for seqno 105 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[Dec  7 21:10:32] NOTICE[11773]: chan_sip.c:15135 sip_reg_timeout:    -- Registration for 'xxxxxxx@sipgate.de' timed out, trying again (Attempt #3)
[Dec  7 21:10:38] WARNING[11773]: chan_sip.c:4176 retrans_pkt: Retransmission timeout reached on transmission 30152ad126372ebf6305891d1c567c01@sipgate.de for seqno 106 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response

Reverting commit takes Asterisk-11 SVN back to tranquility.
Comments:By: Stephan Eisvogel (eisvogel) 2013-12-07 15:14:44.195-0600

Most likely unrelated (private) patch I am using to force AES_CM_128_HMAC_SHA1_80 instead of AES_CM_128_HMAC_SHA1_32, which is usually offered first.

By: Matt Jordan (mjordan) 2013-12-07 17:03:38.392-0600

Can you provide a SIP debug trace showing what messages sipgate.de is sending and/or a pcap?

By: Stephan Eisvogel (eisvogel) 2013-12-07 22:20:30.283-0600

Packet trace enclosed. Messages on console appear after a minute or two.

By: Matt Jordan (mjordan) 2013-12-27 07:17:12.696-0600

It looks like sipgate.de is doing the "right thing" here, as it is replying back to each REGISTER request with the same from tag we sent to it with successful responses. It adds a To tag in the 200 OK, which is fine:

{quote}
8.2.6.2 Headers and Tags

  The From field of the response MUST equal the From header field of
  the request.  The Call-ID header field of the response MUST equal the
  Call-ID header field of the request.  The CSeq header field of the
  response MUST equal the CSeq field of the request.  The Via header
  field values in the response MUST equal the Via header field values
  in the request and MUST maintain the same ordering.

  If a request contained a To tag in the request, the To header field
  in the response MUST equal that of the request.  However, if the To
  header field in the request did not contain a tag, the URI in the To
  header field in the response MUST equal the URI in the To header
  field; additionally, the UAS MUST add a tag to the To header field in
  the response (with the exception of the 100 (Trying) response, in
  which a tag MAY be present).  This serves to identify the UAS that is
  responding, possibly resulting in a component of a dialog ID.  The
  same tag MUST be used for all responses to that request, both final
  and provisional (again excepting the 100 (Trying)).  Procedures for
  the generation of tags are defined in Section 19.3.
{quote}



By: Scott Griepentrog (sgriepentrog) 2014-01-08 09:30:15.309-0600

Patch to correct this issue.  Please test and advise.

By: Stephan Eisvogel (eisvogel) 2014-01-09 09:48:15.483-0600

Tested for 20 hours on latest 11-SVN, problem is gone. Thanks!
I suggest more testing by 2-3 others, though, before commit.