[asterisk-dev] [Code Review] Fix issue of unrecognized inbound ACK when Asterisk responds to an INVITE with a 481

[wdoekes]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1977/#review6477
-----------------------------------------------------------

Ship it!


Sorry for the delay.

- wdoekes


On June 12, 2012, 8:32 a.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1977/
> -----------------------------------------------------------
> 
> (Updated June 12, 2012, 8:32 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> When Asterisk receives what it believes to be a dialog-starting INVITE with a to-tag, Asterisk will reply with a 481. There was an issue where Asterisk would not recognize the incoming ACK of the 481 because Asterisk's internally generated to-tag did not match the actual to-tag used in the transaction. My initial fix for this was to make Asterisk send its generated to-tag in the 481 to essentially "change" the to-tag of the transaction. This way, the UA would respond with an ACK with a matching to-tag and all would be happy.
> 
> Unfortunately, it was pointed out to me that just because Asterisk thinks that an INVITE is out-of-dialog doesn't make it so. For instance, Asterisk could crash with a SIP dialog up, be restarted, and then receive a reinvite for that dialog. The new Asterisk instance would have no knowledge of the dialog, so it would think the INVITE was out-of-dialog with an illegitimate to-tag. In this case, the sender of the reinvite would not recognize the 481 as being in-dialog and would thus continue retransmitting the reinvite until the transaction timed out.
> 
> The new approach here is to update Asterisk's local tag to be the to-tag present in the INVITE in the case that Asterisk will be transmitting a 481 response. Taking this approach meant having to change the local tag to be a string field instead of a static buffer and rewriting the make_our_tag() method.
> 
> 
> This addresses bug ASTERISK-19892.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19892
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 368625 
>   /branches/1.8/channels/sip/include/sip.h 368624 
> 
> Diff: https://reviewboard.asterisk.org/r/1977/diff
> 
> 
> Testing
> -------
> 
> I have tested using Walter Doekes's 481 test. The 481 that Asterisk sends has the same to-tag as the INVITE, and Asterisk properly recognizes the inbound ACK.
> 
> 
> Thanks,
> 
> Mark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120615/710c2846/attachment.htm>