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

reviewboard at asterisk.org reviewboard at asterisk.org
Tue Nov 9 12:33:45 CST 2010


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


I think it's very dangerous to disable the verification of the auth. There has to be another way of fixing this. The retransmit should hit the same dialog and we still have the nonce. Why does the auth fail?

- Olle E


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/20101109/ca6d37d8/attachment.htm 


More information about the asterisk-dev mailing list