[Home]

Summary:ASTERISK-19892: If Asterisk sends a 481 to an initial INVITE that contained a to-tag, then Asterisk will not recognize the ensuing ACK
Reporter:Mark Michelson (mmichelson)Labels:
Date Opened:2012-05-21 09:51:12Date Closed:2012-06-25 14:24:20
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.13.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Scenario is:
{noformat}
UAC           Asterisk

  INV w/to-tag
------------------>

       481
<------------------

       ACK
------------------>
{noformat}

Asterisk does not recognize the ACK for the 481, and will retransmit the 481 until the transaction eventually times out.

From Review https://reviewboard.asterisk.org/r/1918/:

"Asterisk thinks there is a to-tag mismatch in the ACK. The initial INVITE causes Asterisk to create a new sip_pvt. When Asterisk creates a sip_pvt, it generates a local tag and stores that in the sip_pvt. The problem is that when Asterisk sends the 481 response, rather than using this generated to-tag, Asterisk reuses the To header from the initial INVITE since the header had a tag present. This means that when your scenario properly sends an ACK with the same to-tag as the initial request and the 481, Asterisk sees that this to-tag does not match the generated local tag Asterisk created for the sip_pvt."
Comments:By: Walter Doekes (wdoekes) 2012-06-07 03:34:49.416-0500

@mark: Doesn't this move the retransmit burden to the UAC instead? If a phone does have a legitimate re-INVITE but asterisk has forgotten about the dialog (e.g. restart), will the phone understand that the 481 belongs to the dialog (with the other to-tag) and terminate the dialog?
By: Mark Michelson (mmichelson) 2012-06-07 08:59:16.418-0500

I suppose that could be an issue. Asterisk could crash and then be restarted. After the restart, a legitimate reinvite for a dialog belonging to the previous Asterisk instance could arrive. In such a case, I believe that the other UA will not make the connection that the 481 belongs with the dialog.

I had originally planned to make the change of having Asterisk's local tag match the one in the INVITE, but I had backed out when I saw that the 'tag' field of the sip_pvt is an 11 char buffer and not variably sized. This means that if the to-tag of the incoming INVITE were larger than 10 characters, we would not be able to match the to-tag entirely when the ACK arrived. I will investigate the possibility of changing the tag field of the sip_pvt struct to be one of the many string fields instead of a static buffer.
By: Walter Doekes (wdoekes) 2012-06-12 01:44:43.707-0500

http://lists.digium.com/pipermail/asterisk-commits/2012-June/055402.html re-closed it by accident.

https://reviewboard.asterisk.org/r/1977/ hasn't been committed yet though.