Digium phones used with or without DPMA
users.conf as a means of configuration of Asterisk for use with Digium phones is not supported.
Send To, Transfer To and Dial Voicemail
Digium phones, when configured, have specific "to Voicemail" functionality that appears on a dedicated softkey during incoming calls.
For DPMA, this functionality is controlled by the "send_to_vm" phone configuration option in res_digium_phone.conf. This option is enabled by default by DPMA. It is disabled by default for phones provisioned manually. To enable manually-provisioned phones to use this functionality, the send_to_vmail keymap must be enabled. Further, the Send and Transfer capability require the use of Asterisk 11, Certified Asterisk 1.8 or the 10-digiumphones branch - due to the DIVERSION header support requirement.
On an incoming call, Digium phones present four softkeys to the user:
- Answer - which causes the phone to answer the incoming call
- Ignore - which causes the phone to send a 603 REJECT back to Asterisk
- Transfer - which allows the callee to transfer the caller to a different extension
- Send VM - which allows the callee to transfer the caller directly to the callee's voicemail box.
When the Send VM softkey is pressed, the phone sends a DIVERSION header to Asterisk that contains a REDIRECTING reason "send_to_vm."
The following presents a dialplan example of using the DIVERSION header and the X-Digium-Call-Feature header to handle Send to VM, Transfer to VM, and Direct VM dial.
The first step in this example performs no operation.
The second step in this example performs a GotoIf. If true, it jumps to the "vm" priority label. If false, it jumps to the "notvm" priority label. Two cases are evaluated. The first case:
checks for the presence of the "send_to_vm" DIVERSION header. This occurs when the phone user performs a Send To or a Transfer to Voicemail. The second case:
checks for the presence of the "feature_send_to_vm" X-Digium-Call-Feature header. This occurs when the phone user directly dials a contact's voicemail from the Contacts application.
If either case is true, meaning that the phone user wanted to either Send To, Transfer To, or directly dial another user's voicemail box, then the dialplan will jump to the "vm" priority. If both cases are false, the dialplan will jump to the "notvm" priority.
The third step is the "vm" priority label. It calls voicemail box 301.
The fourth step follows the vm priority label. If the vm priority label is reached, because the call was supposed to go to a destination, and we've completed the voicemail application from the third step, this step explicitly hangs up the call - not normally necessary, but included for the sake of completion.
The fifth step is the "notvm" priority label. It calls SIP peer 301.
The sixth step in this example, the Dialing of SIP peer 301home, will be reached if the callee, on an incoming call, presses the "Ignore" softkey. In that case, the caller has called extension 301 without a DIVERSION or X-Digium-Call-Feature header, so the dialplan has proceeded to Dial SIP peer 301. Asterisk receives a 603 REJECT when the callee presses the Ignore softkey. Asterisk then continues in the dialplan to the next step, which in this case is dialing a different SIP peer, 301home.
The seventh step calls the voicemail application, but only after the call has also completed the sixth step of dialing SIP peer 301home.
Intercom and Monitor
The Intercom and Monitor softkeys inside a contacts details have been replaced by the use of defined Smart BLF <action>s. The older behavior of defining can_monitor and / or can_intercom has been deprecated. For more information about using <action>s to achieve this functionality, please read the Smart BLF examples.
The following presents a dialplan example of using the X-Digium-Call-Feature headers to handle Intercom and Monitor functionality.
Connected Line Updates
Digium phones support connected line updates using the P-Asserted Identity method. Connected line updates allow for dynamic caller id updates during call transfers. To enable Digium phones to receive and send updates, the SIP peer for the Digium phone must be setup using the trustrpid and sendrpid configuration options. Further, unless you are taking advantage of the Connected Line function, you will need to explicitly set a Caller ID for the sip peer. Here is a basic example:
Alternate Host / Failover
Digium phones, beginning with phone firmware 1.1 and DPMA 1.3, support simultaneous registration to two hosts. In the event that the primary host is unreachable, calls are be placed to the secondary host instead. When the primary host is down, only call services are supported on the alternate system; status, voicemail, parking, queues, etc. are not functional. Registration to the alternate host is done over normal SIP registration, not via DPMA, so no res_digium_phone entry for the phone is required, only SIP (sip.conf) configuration.
When the primary host is unavailable, the phone will display a failover icon in 20-30 seconds. When the primary host becomes available again, the phone will switch back to it once the phone detects its availability. In DPMA, registration to this alternate host is controlled via the alternate_registration_address and alternate_registration_port network options. If those options are present, the phone will apply that alternate host to all internal lines. For phones manually provisioned via XML, see the host_alternate XML configuration parameter.
Ringtones loaded onto Digium phones using DPMA or using XML provisioning should be 16-bit, 16kHz raw signed linear audio files. .wav files are not acceptable. If a .wav file is used, distortion may be heard in the audio as the phone plays back the ringtone. In order to generate a raw signed linear audio file from a .wav file, the sox utility, or any other audio manipulation utility that can handle .wav and raw signed linear files can be used.
To convert a .wav file into an appropriate signed linear file, using the sox utility, the following command-line example should be used: