[asterisk-dev] PJSIP Device Feature Key Synchronization architecture

[asterisk at phreaknet.org]

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?

  NA

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