[asterisk-dev] [Code Review] Don't re-auth subscriptions that are just re-transmissions (not re-subscriptions)

[David Vossel]

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

Ship it!


I understand this is a scary looking patch, but after reviewing all the code paths involved this appears to be a safe solution.  This logic is already set in place in other key request processing functions and while it is a poor substitute to a proper transaction layer, it works and is the solution we can implement now.  Great work Terry.

- David


On 2010-11-09 12:21:48, Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1005/
> -----------------------------------------------------------
> 
> (Updated 2010-11-09 12:21:48)
> 
> 
> Review request for Asterisk Developers and David Vossel.
> 
> 
> Summary
> -------
> 
> From the issue:
> 0018075: Asterisk fails to recognize SUBSCRIBE retransmissions and tries to re-authenticate them, which breaks presence on polycom phones
> Description	 Here's what happens from asterisk point of view:
> -> SUBSCRIBE
> <- 401 Unauthorized
> -> SUBSCRIBE with auth
> <- 200 OK (lost)
> <- NOTIFY
> -> 200 OK for NOTIFY
> -> SUBSCRIBE with auth retransmission
> <- 401 Unauthorized
> At this point polycom phone received 2 "401 Unauthorized" in a row and it completely gives up on resubscribing to this hint until reboot. While polycom behavior is questionable, I believe asterisk should recognize retransmission and resubmit 200OK in this case
> 
> 
> This addresses bug 18075.
>     https://issues.asterisk.org/view.php?id=18075
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 294120 
> 
> Diff: https://reviewboard.asterisk.org/r/1005/diff
> 
> 
> Testing
> -------
> 
> I created a sipp scenario mimicking the issue, it now re-sends a 200 OK when an authed retransmission occurs. I also tested a scenario that sent a retransmission without authentication to ensure that we didn't accept un-authed retransmissions.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101213/49f7485d/attachment-0001.htm