> On July 17, 2014, 4:49 p.m., Mark Michelson wrote:
> > /trunk/res/res_pjsip_publish_asterisk.c, lines 428-430
> > <https://reviewboard.asterisk.org/r/3780/diff/1/?file=63304#file63304line428>
> >
> > Is there some sort of stasis cache removal you could perform here?
>
> Joshua Colp wrote:
> So the best I could do is:
>
> 1. For device state do a full cache dump, run the regex against, and set
> everything it matches to unknown.
> 2. For mailbox state do a full cache dump, run the regex against, and set
> every mailbox to 0/0
>
> I would also need to extend things to store a bit of state information
> about the publisher we are receiving updates from (specifically the eid).
>
> Thoughts?
>
> Mark Michelson wrote:
> I wasn't thinking of simply marking devstates to unknown and mailboxes to
> 0/0. I was thinking of actually removing the items from the cache entirely.
>
> Does a single publication convey the state of multiple resources? In
> other words, is the same publication used to transmit the state of
> PJSIP/Alice at eid 12345 and PJSIP/bob at eid 67890? If so, then I don't
> necessarily see how you could actually remove cache items on a publication
> expiration, since you could presumably still be getting those states
> published from a separate publisher entirely. However, if a publisher is
> guaranteed to only publish a single resource or just resources that are local
> to its eid, then upon publication expiration, you could remove the specific
> resource from the cache or remove all resources from that particular eid.
>
> Joshua Colp wrote:
> A single publication currently conveys only a single resource (device or
> mailbox). A PUBLISH will only be sent for updates from the originating
> system, it does not act as a relay and thus has one eid. As it is I don't
> think I can safely manipulate the cache to produce the desired result. I can
> only change them to some unknown values.
>
> Matt - Thoughts?
This is a tricky problem.
Internally, the states of all devices/MWI are already stored according to the
system's eid:
struct stasis_cache_entry {
struct cache_entry_key key;
/*! Aggregate snapshot of the stasis cache. */
struct stasis_message *aggregate;
/*! Local entity snapshot of the stasis event. */
struct stasis_message *local;
/*! Remote entity snapshots of the stasis event. */
AST_VECTOR(, struct stasis_message *) remote;
};
A local update (where eid == this system's eid) is stored in local; remote
updates are stored in the remote vector. The aggregate is computed if the thing
being stored has an aggregate function (which only device state has).
stasis_cache_dump_by_eid/stasis_cache_dump_all gives you a mechanism to get a
particular remote system's updates and/or all updates from all systems (which,
as you might imagine, is not the most performant thing to do in the world). We
could conceivably use similar mechanisms to remove a particular system's update
from the cache, or set all entries from a system to a particular value, etc.
The problem is, I'm not sure we should be doing that unless a remote system
explicitly tells us to wipe themselves from our cache.
If a PUBLISH request times out, you may want to keep the device state from that
system in the cache. If the system is truly down, endpoints from that system
may be falling back to you, and you may want to keep the aggregate state
computed from what they were on that system. Likewise, we may simply have run
into network lag (or a dropped packet) and the remote system may be "fine" - in
which case, purging the state may cause some rather odd behaviour.
This feels like something we solve once we know it is causing a problem.
- Matt
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3780/#review12723
-----------------------------------------------------------
On July 21, 2014, 7:14 a.m., Joshua Colp wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3780/
> -----------------------------------------------------------
>
> (Updated July 21, 2014, 7:14 a.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Repository: Asterisk
>
>
> Description
> -------
>
> This adds two PJSIP modules which add outbound PUBLISH support and an
> 'asterisk' event type.
>
> The res_pjsip_outbound_publish module is a common module which provides basic
> logic for setting up outbound PUBLISH clients, handling authentication
> requests, handling configuration, and lifetime. Extra modules implement
> specific event types which are registered with res_pjsip_outbound_publish.
> Since it takes care of configuration when an outbound PUBLISH is configured
> extra configuration can be passed to the event type implementation to further
> configure itself.
>
> The res_pjsip_publish_asterisk module implements inbound and outbound support
> for an 'asterisk' event type. This event type conveys device and mailbox
> state between Asterisk instances using a JSON content body. As internal
> device or mailbox state changes the module sends a PUBLISH message to other
> configured instances. When a PUBLISH is received the contents are examined
> and a device or mailbox state change queued up within Asterisk. To restrict
> what is sent and received filtering is available using regular expressions
> which can reduce SIP traffic.
>
> A wiki page is available at
> https://wiki.asterisk.org/wiki/display/~jcolp/Exchanging+Device+and+Mailbox+State+Using+PJSIP
> which has some configuration details with some examples. This should also be
> reviewed.
>
>
> Diffs
> -----
>
> /trunk/res/res_pjsip_pubsub.exports.in 419075
> /trunk/res/res_pjsip_pubsub.c 419075
> /trunk/res/res_pjsip_publish_asterisk.c PRE-CREATION
> /trunk/res/res_pjsip_outbound_publish.exports.in PRE-CREATION
> /trunk/res/res_pjsip_outbound_publish.c PRE-CREATION
> /trunk/include/asterisk/res_pjsip_pubsub.h 419075
> /trunk/include/asterisk/res_pjsip_outbound_publish.h PRE-CREATION
>
> Diff: https://reviewboard.asterisk.org/r/3780/diff/
>
>
> Testing
> -------
>
> Set up two Asterisk instances, configured both sides to publish to eachother,
> made calls and manipulated voicemail. Watched PUBLISH messages go between
> them and state change.
>
>
> Thanks,
>
> Joshua Colp
>
>
--
_____________________________________________________________________
-- 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
