Delayed Paging

This document explains how to set up Delayed Paging – allowing users to record the message and then have it delivered as a page.

Created: January 2019

Updated: April 2023

Permalink: https://wildix.atlassian.net/wiki/x/xwbOAQ

Basic information on Paging feature: Paging - Admin Guide

Use Case 

Customers would like a paging solution that allows them to record a message, then have this message delivered as a page. If they do not like the recording that they have recorded, they would like an opportunity to record the message over again before it is sent out.

Paging on the Wildix system is by default real time, meaning that when a person is paging a page group, the paged parties hear what the paging party is saying in real time. There are cases where it would be preferred to record a message and have this recorded message delivered as a page. Specifically:

  1. If the latency in the environment is enough to be noticeable on an overhead paging system. Example, the paging party can hear the page being delivered slightly after they are saying it. This can be distracting to the paging party.
  2. If the paging party wants an opportunity to correct their paging message. Example, I am sending a page and I say “the work facility will close at 2pm today due to weather conditions. Sorry, correction … 3pm the facility will close”. In such a case, the paging party would like to start the message over rather than correcting it in real time.

Delayed Paging Setup. Version 1

Note: This version of delayed paging is newer and has a couple of significant advantages over the second version. Specifically the following two facts make this solution a lot more administrator friendly.

  1. No “service users” are required to do the delayed paging.  There is no need for additional extensions used as route points.
  2. You do not have to create the entire solution in multiple dial plans.  In this solution you simply import the Dialplan once and configure a couple of dial plan entries. 

Limitation

This configuration currently ONLY works for invite based paging. It does not work for multicast paging. This means that it is useful for Cloud PBX installations that do not utilize any local multicast paging solution such as a local HW PBX with WMS Network configured.

Note: Work around for this limitation is described in Step Workaround: Using SIP invite for paging more than 15 users

Configuration

Step 1. Import the Dialplan

Import the Dialplan provided below into your system. This Dialplan provides the origination functionality of the delayed paging.

Click to download Dialplan

Step 2. Configure the paging group

Configure the paging group that is going to be used. On the provided dial plan there is an entry called page:

For that entry, please configure the correct paging group.



Step 3. Configure pilot number

Configure a pilot number to access the feature. In our example, number 888 was used but any number will do:

In Jump to application: Jump to -> DelayedPaging (imported Dialplan) -> begin

That’s it. Every time someone dials 888, the user will be asked to record a message. The message will then be played using the page group already configured.

Workaround: Using SIP invite for paging more than 15 users

As mentioned above, this solution uses the default paging mechanism, which means that on a Cloud PBX only 15 users can be paged at the same time. In this section a workaround is provided for scenarios where more than 15 users need to be paged. Notice that the change is to simply replace the page application of the page entry in the Dialplan with a custom application.

Replace Step 2:

  • Custom application -> Page(Local/<user>@DelayedPaging&Local/<user>@DelayedPaging)

Example: Page(Local/102@DelayedPaging&Local/110@DelayedPaging&Local/111@DelayedPaging&Local/101@DelayedPaging)

Note: In brackets you need to specify all users to be paged using '&' as a delimiter.

Delayed Paging Setup. Version 2

Limitation

This configuration currently ONLY works for invite based paging.  It does not work for multicast paging. This means that it is useful for Cloud PBX installations that do not utilize any local multicast paging solution such as a local HW PBX with WMS Network configured.

Note: Work around for this limitation is described in Step 5 "Create a separate Dialplan procedure 'mypaging' with two entries".

Configuration

Step 1. Set up an entry in the "users" Dialplan to be used for this new “Delayed Paging”

Notice in the screenshot below that there we are using 888 for the number to be dialed by the user to perform the delayed paging. The applications in the Dialplan essentially prompt the caller using TTS to “record your page message and then press pound”, then set variables required to originate the page when done and ultimately originate a call to the paging system.

Note: Originate Extension is set to 444. This 444 is a “fake user” in the system exclusively used for call forwarding. This user does not need to be online. It is simply used to forward the call to a Dialplan entry that will playback the recorded announcement to the paging group.


Note: Originate Channel is set with 555 as being the user part. This user 555 is another “fake user” which forwards the call to a Dialplan entry that will route to the paging group. Again, it does not need to be an online user, it is simply used for call forwarding to the paging group.

Below are the applications used in the corresponding order:

  • Set -> ORIGINATE_VARIABLES -> QUEUENAME=Notification,QUEUEPOSITION=1

  • Set -> ORIGINATE_TIMEOUT -> 3600

  • Set -> ORIGINATE_PRIORITY -> 1

  • Set -> ORIGINATE_EXTEN -> 444

  • Set -> ORIGINATE_CONTEXT -> internalcalls

  • Set -> ORIGINATE_CALLERID -> ${CALLERID(num)}

  • Set -> ORIGINATE_CHANNEL -> Local/555@internalcalls/n

  • Set -> ORIGINATE_ASYNC -> true

  • Custom application -> Originate()

Step 2. Add “forwarding users” 444 and 555  

Preferences for user 444:



Note: Call forward all is selected and sends all calls destined to this user record to 445.


Preferences for user 555:


Note: Call forward all is selected and sends all calls destined to this user record to 556.

Step 3. Build your paging group

Build a standard paging group that you want to send the page to. In this example, we built a paging group called “TestPage”. See 556 entry Step 4 below. More information on how to create a Paging group: Paging - Admin Guide.

Step 4. Add "users" Dialplan entries for digits 445 and 556

Workaround: Using SIP invite for paging more than 15 users

Replace Step 4.



  • Custom application -> Page(Local/<user>@mypaging&Local/<user>@mypaging)

Example: Page(Local/502@mypaging&Local/503@mypaging)

Note: In brackets you need to specify all users to be paged using '&' as a delimiter.

Step 5.  Create a separate Dialplan procedure 'mypaging' with two entries


Applications used for X.

  • Jump to if -> "${DEVICE_STATE(SIP/${EXTEN})}"="INUSE" -> Procedure mypaging -> Number hangup
  • Custom application -> SipAddHeader("Call-Info: sip:wildixgw;answer-after=0;force")
  • Custom application -> Page(SIP/${EXTEN})

Applications for hangup

  • Hangup -> Reason

    Side note: if you want paging to interrupt current call, disregard this custom app

  • Jump to if -> "${DEVICE_STATE(SIP/${EXTEN})}"="INUSE" -> Procedure mypaging -> Number hangup

How it works

A user dials 888. They are prompted to record a message and press pound. If they do not like the message they recorded, they can simply hang up. In this case, the recording will not be delivered as a page. If they are satisfied with the recorded message they press #. The system then hangs up on this party and originates a new call. This call is originated TO the paging group and is connected to the application that plays back the recorded message.

Additional Information

In this example we used:

  • Users 444 and 555
  • Dialplan entries for call forwards of 445 and 556

These are arbitrary values and can be changed to anything that you would like.  However, if you do use different values, be sure to change ALL references for it to the value of you choice.  

Example: If you want to have the user as 321 instead of 444, you must of course build a user 321 instead of 444, and you must change the reference to 444  in the 888 Dialplan entry to 321 as well. This one! Set -> ORIGINATE_EXTEN -> 444

Also note that in this example we have added everything to the user dial-plan since the originating call is expected to come from an internal user dialing 888. However, this example could be tweaked to use for some other purpose that perhaps has a triggering event of a call arriving on a trunk. If you reuse this example in such a way you would want to be sure to add the originate application steps into the Dialplan associated with the trunk that the call will be arriving on.  For that matter, if a user that is to dial 888 is NOT assigned the users Dialplan but rather some other Dialplan, the configuration must be added to the Dialplan that this user is assigned.

In our example we have created a recording called mymessage. It is possible that if multiple people are using delayed paging at the same time that one user's message would overwrite another user's recording. This is of course highly unlikely in a normal environment but in such a case you could setup different paging codes using different filenames to avoid such an edge case.