[asterisk-dev] [Code Review] Fix possible misshandling of an incoming SIP response as an Options response

[David Vossel]

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

Ship it!


Yep, I see exactly what is going on here.  This should fix the issue.  Great work!

- David


On Dec. 13, 2011, 8:09 a.m., schmidts wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1620/
> -----------------------------------------------------------
> 
> (Updated Dec. 13, 2011, 8:09 a.m.)
> 
> 
> Review request for Asterisk Developers, David Vossel and Matt Jordan.
> 
> 
> Summary
> -------
> 
> i have heard it two times in irc that people complains about peers getting lagged during a sip dialog and as described in the linked issue this even happens when qualify is turned off for this peer.
> 
> after looking at the code i have seen that in the handle_response function checking for an OPTIONS message is the only type which is compared against the p->method and not against the sipmethod var. This sipmethod var is directly taken from the Cseq header of this packet.
> 
> the sip debug attached to the issue shows that even when qualify is turned off an incoming message is handled as an OPTIONS response and the peer is set to lagged. 
> 
> after searching the code of chan_sip there is only one function which can set a peer to lagged state and this function is only called from one place. There is this compare against the p->method and not directly against the Method in the Cseq header.
> 
> 
> This addresses bug ASTERISK-18940.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18940
> 
> 
> Diffs
> -----
> 
>   branches/1.8/channels/chan_sip.c 348047 
> 
> Diff: https://reviewboard.asterisk.org/r/1620/diff
> 
> 
> Testing
> -------
> 
> tested by vitaly the reporter of this bug.
> normal qualify still works like expected.
> 
> 
> Thanks,
> 
> schmidts
> 
>

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