5. Advanced Configuration

5.1. Voicemail Redirection

Voicemail Redirection is a capability that allows users to forward calls directed at them to their respective voice mailboxes. In a way, following a somewhat similar and common behavior when an incoming cell phone call is rejected by the destination.

To support Voicemail Redirection, three things need to be addressed:

  • The [extensions] section needs to be reviewed by adding a voicemail context to each supported extension.
  • The voicemail setting needs to be enabled in the [pbx-features] section.
  • The Asterisk dialplan must include a context whose extensions go directly to the respective extension mailbox.

 

A simple dialplan such as the following is enough:

[prpt-voicemail]
exten => _X.,1,Answer()
exten => _X.,n,VoiceMail(${EXTEN})
exten => _X.,n,Hangup()

 

With this in place, the revised [extensions] section for the example in the previous section, becomes:

[extensions]

2201 = national, prpt-voicemail
2202 = national, prpt-voicemail

Finally, review the [pbx-features] section, enabling the voicemail setting:

[pbx-features]
...
voicemail = yes

5.2. Providing additional data to Promptar Server

The Promptar AMI Connector can extract additional data from Asterisk and deliver it to Promptar Server. Such data will become available in additional data items which can then be used in the server’s templates and rules.

Examples of usage include:

  • IVR collected information.
  • Dialled Number Identification.
  • Queue information.

To achieve such behavior the Asterisk dialplan needs customization. Promptar AMI Connector collects any channel variable starting with PRPT_ and delivers it to Promptar Server.

 

EXAMPLE

Consider the following Asterisk dialplan snippet:

[prpt-sample-context]

exten => 2201,1,Answer()
exten => 2201,n,Set(PRPT_customItem=TEST)
exten => 2201,n,Dial(SIP/0004f2e7a359)
exten => 2201,n,Hangup()

When this dialplan section is triggered, assuming the sample configuration in the previous section, a data item named {call.data.customItem} will be available with the value TEST.

Note: Depending on the use case, prefixing the PRPT_customItem dialplan variable with one or two underscores ensures that it is inherited by child channels; this may be needed, depending on the existing dialplan.

5.3. Experimental Features

SIP Phone Auto-Answer

When user initiates a call from their Promptar Desktop Client, the standard behavior is as follows:

  • The users' phone rings.
  • The user answers the phone.
  • The call to the destination is initiated.
  • Promptar Desktop Client displays the outgoing call window.

Within Asterisk based environments supporting extensions based on SIP phones - whether software or hardware based - the connector can be configured to request the sending of particular SIP Headers on the first request directed at the user’s phone. Given that many phones support auto-answering specific calls depending on the SIP Headers, it is possible to configure the Promptar AMI Connector to completely avoid the first two steps above. In these cases, after requesting the call initiation from the desktop, the behavior becomes:

  • The user’s phone automatically initiates a call to the destination.
  • Promptar Desktop Client displays the outgoing call window.

To do that, a line formatted like the one below should be added to the [channels] section of the configuration file:

variable.<channel> = <value>

In Asterisk terms, this will lead the connector to include the given value in the variables argument of the AMI Originate action sent to Asterisk. In the particular case of SIP based extensions, defining the SIPADDHEADER variable will have Asterisk send such headers to the device on initial SIP invite.

Example for a Cisco SPA series device:

variable.SIP/000e08d63cda = SIPADDHEADER=Call-Info:\;answer-after=0

Refer to the sample configuration file for other examples.

Multiple extensions per channel

Promptar AMI Connector supports sharing one physical device, as defined in the [channels] section, with multiple extensions and the associated users.

For that, one would build the [extensions] and [channels] section as:

[extensions]

2201 = national
2202 = national

[channels]

SIP/0004f2e7a359           = 2201, 2201
multiple.SIP/0004f2e7a359  = 2201

What the above lines mean is:

  • If any of the users associated to extensions 2201 or 2202 initiates a call from within Promptar Desktop Client, the correct desktop signaling will be delivered.
  • Whenever a call is directed at that physical device (channel) one of the following happens:

    • If the dialed number matches one extension, the desktop signaling will be delivered to the correct user.
    • Otherwise, it will default to signaling the user associated with extension 2201, as per the last line in the example above.

Hot-Desking

Promptar AMI Connector experimentally supports hot-desking which, in the general case, implies that the extension/channel association expressed in the configuration file needs to change dynamically.

To achieve that, again, the Asterisk dialplan needs adjustments. In general, whichever dialplan details are in place to implement hot-desking, one will need to force Asterisk to tell Promptar AMI Connector that a given extension/channel association has changed. For that, an AMI UserEvent must be generated as shown in the following example:

[prpt-sample-hot-desking]

...
exten => ...,n,UserEvent(prpt_SetChann2Exten,
                         Chann:<new-channel>,
                         Exten:<existing-extension>,
                         CallContext:<new-call-context>,
                         VoiceMailContext:<new-voicemail-context>)
...