[asterisk-dev] [Code Review] 2869: Fix Realtime Peer Update Problem When Un-registering And Expires Header In 200 OK

Matt Jordan reviewboard at asterisk.org
Mon Sep 23 09:05:41 CDT 2013


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

Ship it!


Ship It!

- Matt Jordan


On Sept. 18, 2013, 6:57 p.m., Michael Young wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2869/
> -----------------------------------------------------------
> 
> (Updated Sept. 18, 2013, 6:57 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22428
>     https://issues.asterisk.org/jira/browse/ASTERISK-22428
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> 1st Issue
> When a realtime peer sends an un-REGISTER request, Asterisk un-registers the peer but the database table record still has regseconds and fullcontact for the peer.  This results in calls attempting to be routed to the peer which is no longer registered.  The expected behavior is to get busy/congested when attempting to call an un-registered peer through the dial plan.
> 
> What was discovered is that we are clearing out the peer's registration in the database in parse_register_contact() when calling expire_register() but then upon returning from parse_register_contact(), update_peer() is run which stores back in the database table regseconds and fullcontact.
> 
> 2nd Issue
> The 200 ok being returned by Asterisk after un-registering a peer contains a Contact header with ;expires= and the Expires header is not set to 0.
> 
> Tests were created for this second issue (ASTERISK-22548).  The tests have been reviewed and a Ship It! was received on those tests.
> 
> Patch
> * Do not ignore the Expires header value even when it is set to 0.  The patch sets the pvt->expiry earlier on in the function so that it is set properly and used.
> * If pvt->expiry is 0, do not call update_peer since that means the peer has already been un-registered and there is no need to update the database record again since nothing has changed.
> 
> 
> Diffs
> -----
> 
>   /branches/11/channels/chan_sip.c 399258 
> 
> Diff: https://reviewboard.asterisk.org/r/2869/diff/
> 
> 
> Testing
> -------
> 
> The reporter has tested this latest patch.  He also helped to point out the Expires header problem.
> 
> Tested this on my local dev machines as well.
> 
> 
> Thanks,
> 
> Michael Young
> 
>

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


More information about the asterisk-dev mailing list