[asterisk-dev] [Code Review] 2996: allow uncached realtime sip peers to be queue members

[wdoekes]

> On Nov. 7, 2013, 3:37 p.m., Joshua Colp wrote:
> > To make sure I better understand the situation...
> > 
> > Is it caching an old stale entry without address?
> > 
> > Then when device state is queried it uses that old stale entry instead of requerying realtime... so it thinks it has no address when in realtime there really is an address?
> 
> Joshua Colp wrote:
>     Well, no, cause your title says uncached... I'm more confused about how it's returning a peer because devicestate purposely doesn't check realtime.
> 
> wdoekes wrote:
>     Thanks for the review. We are indeed talking about uncached:
>     
>       rtcachefriends=no
>     
>     The relevant code:
>     
>       sip_devicestate(...)
>       sip_find_peer(host, NULL, realtime=FALSE, FINDALLDEVICES, devstate_only=TRUE, 0)
>     
>         if (!p && (realtime || devstate_only)) {
>            p = realtime_peer(peer, addr, devstate_only, which_objects);
>     
>       realtime_peer(...)
>     
>         if (ast_test_flag(&global_flags[1], SIP_PAGE2_RTCACHEFRIENDS) && !devstate_only) {
>           ...
>           ao2_t_link(peers, peer, "link peer into peers table");
>     
>     So, the devstate_only=TRUE initiates a realtime lookup anyway, but ensures that the found peer isn't linked in the peers table (if rtcachefriends were to be true).
>     
>     The comments in sip_devicestate could probably use some clarification.
>     
>     
>     
>     As for your question:
>     
>     > Is it caching an old stale entry without address?
>     
>     No, it's returning the freshly loaded peer, but it will never have an p->addr (unless it is currently in a call); the proxy takes care of that stuff. So I need the devicestate to return what it knows, which is *nothing* (unknown), not *unavailable*.
> 
> Joshua Colp wrote:
>     Proxy? An outbound proxy?

Indeed. A dialog-based one. The peer doesn't know it has one until I hit Dial.


- wdoekes


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


On Nov. 5, 2013, 2:41 p.m., wdoekes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2996/
> -----------------------------------------------------------
> 
> (Updated Nov. 5, 2013, 2:41 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> When using realtime SIP peers as queue members, the device state as returned by sip_devicestate() is AST_DEVICE_UNAVAILABLE when the peer is not loaded into memory.
> 
> For uncached realtime SIP peers, this is practically always. That means that my queue doesn't have any available members.
> 
> This patch changes all p->realtime peers with a null p->addr to return AST_DEVICE_UNKNOWN instead. If we set the queue to accept unknown members, the queue correctly copes with devices with this UNKNOWN state:
> 
>     static int member_status_available(int status)
>     {
>         return status == AST_DEVICE_NOT_INUSE || status == AST_DEVICE_UNKNOWN;
>     }
> 
> 
> A different approach would have been to set the p->defaddr to non-null, but that would put the device in NOT_INUSE state which is not entirely correct, since I don't know if the device *is* available. And I haven't checked what other side-effects setting the p->defaddr has.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 402467 
> 
> Diff: https://reviewboard.asterisk.org/r/2996/diff/
> 
> 
> Testing
> -------
> 
> Tested on asterisk 10 and 11 with the SIP-devices in the state_interface column. Without the patch, the device state is unavailable, and the queue will report the members as unavailable. With the patch, the members have the unknown state and things work properly. 
> 
> 
> Thanks,
> 
> wdoekes
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131110/6aec4cf1/attachment.html>