[asterisk-dev] PJSIP Device Feature Key Synchronization architecture

[Joshua C. Colp]

On Thu, Oct 20, 2022 at 8:23 PM <asterisk at phreaknet.org> wrote:

> Hi, all,
>
>      Something I have been working on recently is adding support to
> PJSIP for device feature key synchronization (the as-feature-event
> Broadworks spec that many common IP phones, e.g. Polycom support) to
> control server-side features from endpoints. It's using the PJSIP
> pub/sub capabilities; I had to add the ability to execute a custom
> module callback when a SUBSCRIBE is refreshed, but with that addition,
> it works as it's supposed to.
>

You should further elaborate on all of the server-side features you expect
to implement, if it extends beyond DND.


>
> I wanted to solicit some input on what an ideal way of triggering
> updates should be. Currently we have hints, which actually work
> reasonably all right for Do Not Disturb, which is simply a boolean
> on/off, easily represented with a hint and custom device state for DND.
> The PJSIP module emits an AMI event, the user can process it and change
> the device state if needed, which will trigger a NOTIFY to go out to the
> endpoint.
>

What user? An outside AMI application? An internal consumer in Asterisk?


>
> This sort of came up about 12 years ago[1]. The actual SIP stuff is not
> complicated; it's the user interface to it that requires more thought.
> For call forwarding, there are more moving pieces and abusing
> hints/custom device state for that is super clunky. You can't
> communicate the call forwarding target, # of rings, etc. in a device
> state, so additional hints are then needed for that. It works but it's
> super clunky and I don't think this is a great pipeline.
>

Okay, so this covers call forwarding as well.


>
> I'm wondering if people have thoughts on what an ideal mechanism would
> be for users, once they process a request to enable/disable a feature
> from the phone, to communicate that to the PJSIP module. The problem
> with abusing hints, especially for call forwarding, is it's not a good
> way to communicate details into the module. One option perhaps is to
> have dialplan extensions, setup in a manner similar to use with
> EVAL_EXTEN, where it returns the current value needed, as any relevant
> function, DB, ODBC, CURL, custom function, etc. could be used to
> retrieve the current feature value. The clunky part is more signaling to
> the PJSIP module that it needs to send the phone the updated status (by
> checking those extensions, for example). The device state callback
> happens to be convenient for this kind of signaling but not really
> appropriate here. It would be better to push the info into the module
> directly rather than the signaling it and making it retrieve the updated
> data in some arbitrary way.
>
> So with this in mind, I'm currently leaning in the direction of a
> dialplan function/AMI action that could be used to set the appropriate
> info for a subscription, which would trigger the NOTIFY, and then
> nothing would actually need to be added to the dialplan at all (inasmuch
> as hints and things of that nature). One d I think starting purely from
> that perspective

isadvantage of this is that
> for every single update, unlike callbacks, we have to traverse the
> entire list of subscriptions (though maybe that's not a big deal). The
> bigger problem is this is push only and the PJSIP module still needs to
> be able to "pull" feature statuses on demand, which is where the
> hint/lookup model is useful. A potential middle ground solution is use
> the dialplan function/AMI action to push only, but cache all of this in
> AstDB (as subscriptions themselves are), so that we can retrieve the
> latest/most current value at any point if needed. Then we don't need to
> be concerned at all with how the user is managing state as that is fully
> decoupled, although obviously this would lead to a little
> duplication/redundancy. Any thoughts?
>

You've thrown a lot of lower level implementation details at us and to be
quite honest it's overwhelming. There's no full user facing examples of how
it would all work, beyond the bits and pieces in your text that we'd then
have to deduce and after reading a few times it doesn't feel very friendly.
To start off with: Is this a developer API and interface, or is this also
meant for the common everyday user? I would hope it's for the common
everyday user, in which case it should be approached from that perspective
first with implementation details following.

As an everyday user I'd expect not to have to deal with AMI or complex
dialplan. I'd expect to be able to set and get the information from the
dialplan using dialplan functions (or a single function) so I could use
that in the dialplan, and have it "just work" with my phones that support
the feature. I'd expect it to persist across Asterisk restarts. For example
${EXTENSION_DND(alice)} for retrieving DND status of Alice, and if Asterisk
restarted then that should stay the same.

For developers the same thing could apply except having AMI actions to set
and get.

Functionally this is a simple storage mechanism of data. The AstDB is used
to persist such information. It could use sorcery to then be backed by a
real database. The manipulation could be like I said previously, using
dialplan functions with also AMI actions. To get the information to
consumers it would be a defined API to allow
setting/getting/subscribing/anything else, and for pushing to consumers it
would use stasis which would also give AMI events when things changed. It's
sorta like device state, but with persistent data and simpler.

This would also need explicit configuration to ensure that stale data
doesn't persist in the persistent storage.

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20221021/6bd65ecf/attachment.html>