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.

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.

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.

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 disadvantage 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?


[1] https://asterisk-dev.digium.narkive.com/ehCW4yGI/asterisk-support-for-as-feature-event-package

-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

Reply via email to