Hello,
is there a way to change extension hint mapping at runtime? An example use for this is hot desking. For example, hint for extension 777 is mapped to PJSIP/777. If user 777 logs at the extension 888, the hint should be remapped to PJSIP/888.
Your basic problem is that the “user” you are referring to here is not something that Asterisk knows about.
Whilst hints lock the connection between either the device identity or its login credentials, and an extension number, if you authenticate by device name or SIP user name, that device doesn’t have to be the same physical device each time. I believe chan_sip can match an endpoint by login name, although I’ve never used that option in anger. I’m not sure about chan_pjsip.
Unfortunately, SIP phones don’t make it easy for you to specify account name and password when you sit down at a desk.
So, the mapping between device state and extension is locked at runtime. I guess my only option is to run an external script which would poll SIP device state and update Custom device state accordingly. Changing SIP credentials on the device is not a viable solution.
There are ways of changing dialplan at run time, e.g. from the CLI.
You could try using something like realtime or func_odbc to change where the hint points programmatically.
I don’t follow. How would you manipulate hint mapping via func_odbc?
You would need to store in a database what extension is mapped to what device, you an do this with an ODBC function in your login/logout dialplan
For the hint it’s as easy as :
exten => _XXXX,hint,${ODBC_HINT(${EXTEN})`
2 Likes
I wasn’t aware you could use functions in hint definition. Thanks. This is exactly what I needed.
Revisiting this topic, the function in hint exten is still only evaluated at subscription time. So, if the contents of the database changes after at least one device subscribed to specific hint, that change will not be reflected by that hint. There doesn’t seem to be a way to delete existing dynamic hints, as far as I can see.
Damn, I didn’t realize that.
Could a dialplan remove command remove the hint possibly?
…maybe…possibly…
I guess I could use:
System(asterisk -rx "dialplan add extension ... replace")
It’s ugly, but I’ll take it if it works. I’ll report after I test it thoroughly.
Why is ugly if works ? you could use AMI command action but at the end will be the result
I have tested this and I think changing the hint extension in dialplan works as expected. For example, on user logoff I do:
System(asterisk -rx "dialplan add extension ${user},hint,Custom:${user},CustomPresence:${user} into ${PHONE_CONTEXT} replace");
DEVICE_STATE(Custom:${user})=${STATE_UNAVAILABLE};
The problem is that the lamp on the phone does not go off when I set custom device state to unavailable, but I believe this is a different issue. For some reason, Asterisk sends exactly the same notify message for both NOT_INUSE and UNAVAILABLE states.
<--- Transmitting SIP request (784 bytes) to UDP:10.0.0.194:5062 --->
NOTIFY sip:999@10.0.0.194:5062 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.10:5060;rport;branch=z9hG4bKPj9b7fb4a0-5e88-4754-ba9a-df838813f59d
From: <sip:777@10.0.0.10>;tag=ae49bfeb-be15-4bd2-8de8-e441de76d00f
To: "999" <sip:999@10.0.0.10>;tag=304791455
Contact: <sip:10.0.0.10:5060>
Call-ID: 423247991@10.0.0.194
CSeq: 28841 NOTIFY
Event: dialog
Subscription-State: active;expires=670
Allow-Events: message-summary, presence, dialog, refer
Max-Forwards: 70
User-Agent: Asterisk PBX 15.1.5
Content-Type: application/dialog-info+xml
Content-Length: 227
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="32" state="full" entity="sip:777@10.0.0.10:5060">
<dialog id="777">
<state>terminated</state>
</dialog>
</dialog-info>
1 Like
You only provided the single notify but are you sure they are not different?
From memory
terminated means idle
confirmed means busy
early means ringing
proceeding means ringing
Yes, relevant parts are exactly the same. I’ve searched online and it appears this is normal. Dialog-info apparently does not support unavailable state. Anyway, my original issue is resolved. Thanks for the help, everybody.
1 Like