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
--
_____________________________________________________________________
-- 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
