AdminGuide:Service:Paging

Da Kalliope Wiki.
Versione del 27 feb 2018 alle 08:17 di Silvia (discussione | contributi) (Creata pagina con "Specifically: * If the paging group is configured not to send additional header (and therefore uses terminals dedicated to making announcements), automatic answer must be enab...")
Jump to navigation Jump to search
Altre lingue:

Paging service

  • Introduced with firmware version 4.3.1

Description

The paging service lets a user simultaneously send a live or prerecorded audio message to multiple destinations, with the option of having devices answer automatically when they receive the message. This service is used to make informative or emergency announcements.

KalliopePBX lets you define an arbitrary number of "paging groups". Each one is independent from the others and is fully configurable when it comes to permissions, choice of destinations, mode of operation, and messages.

An extension can make a call to a selection comprised of a paging service prefix (set when enabling the service in the numbering plan, by defoult *53) followed by the paging group number (set in the configuration page for the group). If authentication is necessary, KalliopePBX will play the "Password" audio file and the user will need to input a PIN (the one set in the group configuration or their personal one) followed by #. If authentication is successful the paging group will be activated according to its configuration, detailed in the following section.

Configuration

Paging groups can be created and edited in the PBX -> Paging groups page. The configurable settings for each group are:

  • Name: an identifier for the paging group.
  • Number: the selection that is appended to the paging service prefix (set in the numbering plan).
  • The 'caller identifier: this is used as the Display name for calls to the destination terminals.
  • The operating mode of the paging groups: can be set as either "Live" or "Unattended".
    • Live: the extension making the call to the paging group will remain on call as the sole speaker; at the end of the call, they will hang up, and the calls to all destinations will themselves end.
    • Unattended: the PBX hangs up the call made from the extension to the paging group and, after a few moments, proceeds to contact all destinations and play the message set under the "Audio file" item.
  • Audio file: the prerecorded message that is played to the group. It will be used differently depending on whether the mode is set to "Live" or "Unattended":
    • Live: the message is played before the caller begins communication with the group. This can be used to mark the beginning of an announcement.
    • Unattended: the message is played to all destination in the paging group. Depending on the following setting (Number of repetitions), the message can be played once or multiple times.
  • Number of repetitions: this setting is only configurable when the mode is set to "Unattended" and controls the number if times the prerecorded message is played before the PBX automatically ends the call. Setting this to 0 means the message is played indefinitely. In "Unattended" mode, a second call to the group will stop playback regardless of this setting. N.B.: the second call does not need to be made from the extension that activated the service as long as it is enabled according to the rules detailed below.
  • Automatic answer method: this setting controls which header, if any, is added to calls made to the destination terminals in order to specify the automatic response request. The choice of header depends on the terminals themselves, as different terminals may require different notification modes. There are three options:
    • Manual: the PBX does not specify any header, and the configuration for automatic response must be made statically on the individual terminals.
    • Header Call-Info: the header "Call-Info: <sip:127.0.0.1>;answer-after=0" is added.
    • Header Alert-Info: the header "Alert-Info: <http://127.0.0.1>;info=alert-autoanswer;delay=0" is added.
  • Accounts: list of destination terminals in the paging group. N.B.: destinations are individual SIP accounts, so for extensions linked to multiple accounts you can choose to which of these the call is made.
  • Access control: the permissions necessary to use the service. You can specify one or more access rules of the form:
    • Extension: the calling extension, or "Any extension"
    • Type of PIN: the required authentication. The possible values are:
      • None: no PIN is required.
      • Custom: a specific PIN is required. This can be set in the following column (PIN value). This PIN can be the same or different ones for each extension.
      • Extension service PIN: The service PIN for the extension is required.

An example of ACL is:

Extension Type of PIN Value of PIN
101 (Extension 101) None
102 (Extension 102) Extension service PIN
Any Custom 123123

In this example, extension 101 can activate the service (or deactivate it if it is set to "Unattended") without needing to input any PIN. Extension 102 can use the service after dialing their service PIN, while all other extensions need to dial 123123.


Interoperability

The configuration of the automatic answer is tied to the terminals, as different devices might require different ways of signaling requests. The service has been tested with SNOM (firmware 8.7.5.13) and Yealink (firmware v80) terminals and requires the phone to be configured to accept requests. Other models are currently being tested and new headers will be added in the future if necessary.

Specifically:

  • If the paging group is configured not to send additional header (and therefore uses terminals dedicated to making announcements), automatic answer must be enabled on all phones. This can be done either through provisioning or through the web GUI of each phone. The relevant settings for each tested phone are:
  • For non-dedicated terminals, it is necessary to send a header to request automatic answer. The terminals must be configured to accept the directions given by the header, otherwise it will be ignored the user will need to answer manually.
    • SNOM: edit the "Intercom Policy" setting in the "Advanced -> Behavior" page (disabled by default). See http://wiki.snom.com/Settings/answer_after_policy for the configuration. Both headers were tested with positive outcome. N.B.: upon automatic answer, the phone will, by default, emit an announcement tone; this can be disabled by editing the "Auto Connect Indication" setting (http://wiki.snom.com/Settings/auto_connect_indication).
    • Yealink: automatic answer headers (and announcement tones) can be enabled or disabled in the "Features -> Intercom" page.
    • Grandstream: automatic answer headers can be enabled in the "Accounts -> AccountX -> CallSettings -> Allow Auto Answer by Call-Info" page. Header Call-Info requests are required.