> 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?
>
> wdoekes wrote:
> Indeed. A dialog-based one. The peer doesn't know it has one until I hit
> Dial.
Yeah... that is the underlying problem here, which is why I'm uncomfortable
with the change. Every other realtime user who isn't doing what you are doing
loses out on knowing if the peer is available or not in a more granular
fashion, since in their case the check is valid.
- Joshua
-----------------------------------------------------------
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
>
>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
