Sangoma Phones when used with DPMA
SIP Configuration
Configuration of a phone via the Desk Phone module for Asterisk alone is not enough to enable calling between the phone and Asterisk. As with any SIP device that connects to Asterisk, each Sangoma phone needs a corresponding entry in Asterisk's SIP configuration. Further, use of DPMA assumes that out-of-call MESSAGE support has been enabled, and will require some specific "general" section parameters.
...
Example Device State provider mapped to extension.
| Code Block |
|---|
A hint for extension 1111 is mapped to the PJSIP endpoint 1111 device state provider. In this example, endpoints subscribing to hint 1111 will receive a device state update anytime the device state changes for PJSIP endpoint 1111.
exten => 1111,hint,PJSIP/1111
exten => 1111,1,Dial(PJSIP/1111) |
|
Using the same pattern, user presence is changed by a CustomPresence user presence provider. A CustomPresence provider works in the same way a Custom device state provider does. CustomPresence providers are both defined and updated using a dialplan function, PRESENCE_STATE().
Example Device State and Presence State providers mapped to a single extension.
| Code Block |
|---|
A hint for extension 1111 is mapped to both the PJSIP endpoint 1111 device state provider and the CustomerPresence:1111 user presence provider. Endpoints subscribing to hint 1111 will receive both device state and user presence notifications for extension 1111.
exten => 1111,hint,PJSIP/1111,CustomPresence:1111
exten => 1111,1,Dial(PJSIP/1111) |
|
Manipulating User Presence through Dialplan and AMI
...
User presence information is modified through the use of the PRESENCE_STATE() dialplan function. This function allows a custom user presence provider's information to be both read and written via the dialplan and AMI.
Write Syntax
| Code Block |
|---|
PRESENCE_STATE(<presence state provider>)=value[,subtype[,message[,options]]] |
|
Valid State Values for Digium Phones
| Code Block |
|---|
"available"
"away"
"xa"
"chat"
"dnd"
"unavailable" |
|
Valid Options
| Code Block |
|---|
e: Both subtype and message fields are base64 encoded. This is necessary for complex strings containing commas and newline characters. When this option is used, the PRESENCE_STATE function knows it must first base64 decode the subtype and message fields before setting them on the CustomPresence provider. |
|
Read Syntax
| Code Block |
|---|
STATE_VALUE = ${PRESENCE_STATE(<presence state provider>,field[,options])} |
|
Valid read fields arguments
| Code Block |
|---|
value
subtype
message |
|
Valid read options
| Code Block |
|---|
e: Base64 encode the return value when the field argument is subtype or message. |
|
Dialplan Examples
Dialplan Write Examples
Example1: Set Batman's state to "Away" with the subtype "In the batcave" with the message, "Making a new batch of batarangs".
| Code Block |
|---|
Set(PRESENCE_STATE(CustomPresence:Batman)=away,In the batcave, Making a new batch of batarangs) |
|
Example2: Building on example1, now set Batman's state to "Extended Away" (xa) with no subtype while maintaining the message "Making a new batch of batarangs"
| Code Block |
|---|
Set(PRESENCE_STATE(CustomPresence:Batman)=xa,,Making a new batch of batarangs) |
|
Example3: Setting the state as available without providing a subtype or message string. This will clear any previous message strings.
| Code Block |
|---|
Set(PRESENCE_STATE(CustomPresence:Batman)=avaliable) |
|
Example4: Set complex subtype and message strings using base64 encoding.
| Code Block |
|---|
Set(PRESENCE_STATE(CustomPresence:Blah)=away,${BASE64_ENCODE(business)},${BASE64_ENCODE(I will visiting clients in the San Diego area.\nI will be returning on Oct 11th.\nCall Josh for emergencies)}) |
|
PRESENCE_STATE Read Examples
...
Example1: Setting both the user state and message using SetVar action in conjunction with PRESENCE_STATE() dialplan function.
| Code Block |
|---|
Action: Setvar
ActionID:1234
Variable: PRESENCE_STATE(CustomPresence:Batman)
Value:away,In the batcave, Making a new batch of batarangs |
|
Example2: Setting state information that must be base64 encoded because it contains newlines and/or commas.
| Code Block |
|---|
Action: Setvar
ActionID:1234
Variable: PRESENCE_STATE(CustomPresence:Batman)
Value:away,ISDW982KLJ90==,20DJKL23JK==,e |
|
Example3: Reading user state and message using GetVar action.
| Code Block |
|---|
Action: Getvar
ActionID:1234
Variable: PRESENCE_STATE(CustomPresence:Batman,value)
Action: Getvar
ActionID:1234
Variable: PRESENCE_STATE(CustomPresence:Batman,subtype)
Action: Getvar
ActionID:1234
Variable: PRESENCE_STATE(CustomPresence:Batman,message) |
|
Example4: Reading subtype and message fields as base64 values.
| Code Block |
|---|
Action: Getvar
ActionID:1234
Variable: PRESENCE_STATE(CustomPresence:Batman,subtype,e)
Action: Getvar
ActionID:1234
Variable: PRESENCE_STATE(CustomPresence:Batman,message,e) |
|
User Presence in DPMA
DPMA does all of the user presence manipulation of the CustomPresence providers behind the scenes. Phones subscribe to a set of user extensions to receive both device state and user presence updates. DPMA is in change of defining the hints the phones subscribe to, and mapping those hints to the correct device state and presence state providers. When a phone user updates their user presence, DPMA internally updates that user's CustomPresence provider to reflect the change using the PRESENCE_STATE() dialplan function. This results in any watcher of the hint mapped to that CustomPresence provider receiving an update indicating the new user presence.
...