How can we help?
< All Topics
Print

2. char pmslink HTTPCNX API FOR PBX

22/07/2021.
Version for PBX based on general API.

Description

char pmslink is an intelligent middleware that allows the integration of different devices and hotel systems
(PBX, TV, Hotspot, multimedia, home automation, app guest access, minibar, etc.) with the property management
system (PMS).

www.charpmslink.com

This integration does not only transform links and protocols to connect every system. It goes further and adds
intelligence to those connections, controlling its status, apporting traceability, managing buffers, adapts the
default values of each single system, and uses a single PMS interface in order to integrate all the devices and
systems connected to it.

char pmslink adapts itself to any architecture, supports any kind of system such as cloud, remote, locals, monohotel, multi hotel, etc.

Normally equipment and systems are integrated with pmslink via their own API, which is implemented by char
and added to the library of integrated systems.

In cases where there is no appropriate API from the equipment / system to be integrated, or it does not provide
the required functionality, we offer the possibility of integration using one of pmslink’s standard APIs, which
cover different links, different flows of the information, different data format, and, in general, are versatile to
facilitate integration according to the design and architecture of the equipment to be integrated.

httpcnx is one of the standard pmslink APIs. In this case an API based on REST and JSON format.

httpcnx for PBX is an extract of the general API in which, in order to simplify the documentation, only the
methods and data that are commonly used in the management and integration of a PBX system in a hotel
environment are defined.

If necessary, it is possible to enhance the functionality offered by this API by adding methods and data covered
by the general API.

In the same way, the implementation of this API can be reduced to the minimum required.

Since the objective is to integrate and provide the functionality necessary for a PBX system to adapt to the needs
of a hotel, the methods and terms used refer to common hotel concepts: ‘checkin’, ‘guest data’,’ checkout’, etc.
In each case it is clarified what actions and configurations are involved for the PBX system in each of these
concepts.

This document describes:

  • The steps to be followed for the integration process.
  • The standard hotel functionality that a PBX system for a hotel is expected to provide.What functionality is related to each of the events and actions managed by pmslink.
  • The API details on connections, authentication, requirements, data structure and other details needed
  • for the implementation.

Development process, testing, certification and realease

This API is considered as public domain, but its use is restricted to char pmslink integrations and can’t be allowed
its use for direct integration with other systems.

char does not apply any economical charge to the system that creates the integration with char pmslink using
this API.

The basic steps in order to create the integration are the following ones:

  • The party interested to integrate with char pmslink should contact https://charpmslink.com/contact/ in order to start the process and obtain more extended information about the process itself and formalize a technical agreement (view template).
  • char and the system to be integrated will coordinate the features and functionality suitable for this integration, as well as those that are not offered directly but char pmslink can offer by its own means.
  • For example, wake-up functionality or code dialling via CTI, SIP, etc.
  • Once the functionality, endpoints and data involved have been defined, char will generate a specific
    driver for the system to be integrated, which will be the basis for testing, final validation and use in
    the hotels.
  • Throughout the development process, char will provide all the necessary support and assistance,
    through expert@char.es and any voice contacts that may be agreed in advance.
  • Once the development of the system to be integrated has been completed, the activation of a test
    environment will be coordinated by char, the first tests will be carried out jointly and the final
    validation will be done.
  • Once validated, it will be considered as an integrated system for all intents and purposes, being released
    to public, including it in the integrated systems list and notifying through the common news channels.
    The integrated system will be able to publish and advertise at its will the integration and the additional
    value that provides the integration itself.

Once the previous steps are done, char will have a fluid relationship with the integrated system to solve possible
issues with its installations, adjustments and updating its functionalities in the cases that is needed.


Data flow and basic functionalities

Basically, the functionality required for a PBX system to suit the needs of a hotel is related to the services offered
to the guest and the services required by the hotel staff to serve the guest.

It is understood that the actions and data are related to each of the extensions of the PBX system in a room. In
this context, rooms with several extensions will be managed by pmslink independently for each of them. For
example, if there is an extension (telephone) in the bedroom and in the bathroom, pmslink will handle them
independently.

The functionality offered by the PBX system is, or may be, related to:

  • The PMS system, through Integration with it.
  • Additional tools for specialised services, such as Housekeeping or minibar systems.
  • pmslink’s own tools that complement other integrated systems.

So, in the Integration, pmslink will connect transparently with the PMS system and/or other systems that might
be involved according to each type of action or information.

Features provided by the PBX system to the hotel through the integration:

It will depend on the features of the PBX system, being considered

RELEVANTS:

  • When receiving a call from an occupied room, show the name of the main guest on the reception display and other hotel services, so that the guest can be identified and attended to in a personalized manner.
  • Provide voice guidance and messages in the language of the guest occupying the room.
  • Prevent outside calls from extensions in unoccupied rooms.
  • Allow outside calls from extensions in occupied rooms, with the possibility of limiting their scope or even restricting them completely depending on the type of guest.
  • Make wake-up calls at the scheduled wake-up time. This functionality can be provided directly by the PBX System or through pmslink tools, using the resources available in the PBX that make it possible (CTI, SIP extensions, etc).

ADDITIONALS:

  • In the case that the hotel reception and other services have terminals with a suitable size display, when receiving a call from an occupied Room, show, in addition to the name of the main guest, information about their language, stay and VIP level.
  • Visual indicator, by a LED or any other indicator on the room’s telephone, about the existence of a ‘message waiting’ pending to be consulted to the reception or other hotel services.
  • Activate/deactivate the ‘Do Not Disturb’ feature, to deny incoming calls when the feature is activated.

Data provided by the PBX system to the hotel through the integration:

It will depend on the features of the PBX system, being considered

RELEVANTS:

  • Cleaning codes / Room status. Maids, through the room’s telephone, by dialling different codes for each type of status (clean, inspected, dirty, blocked, out of order, …) will communicate their status so that Housekeepers, Reception, or other hotel services can carry out the appropriate actions according to their state of cleanliness and availability.
  • Wake-up result communication: Completed (call answered), not completed (call not answered, extension busy, extension disconnected).
  • The sending of records of outgoing calls made by guest with basic data for calculating their cost (destination, duration) and sending this information to the PMS (billing calls / call accounting).

ADDITIONALS:

  • Control of unanswered/missed calls from guests to reception and other hotel services to facilitate the
    communication with the guest at the time when the service can be provided, by sending a record of
    internal calls made. The processing of this information will be carried out in a specialised manner
    through pmslink and its call accounting tool.
  • Consumption of minibar items. The hotel staff in charge of minibar management will communicate the
    consumption of articles to the PMS to be included it in the guest’s invoice. This is done through the room’s telephone, by dialling different codes for each article consumed.
  • Sending a record of calls received from outside, basically for call accounting system controls.
  • Activation of ‘Do Not Disturb’ status by the guest to be broadcast to different hotel services. Usually
    by dialling codes on their terminal, using a specific table and/or using terminals with a multi-function
    display.
  • Programming / cancellation of the wake-up calls by the guest. Usually by dialling codes on their
    terminal or using terminals with a multi-function display.

API Methods and their relationship to PBX System features and data:

pmslink → PBX System

I. Action CHECKIN:

Guest arrival. Request sent at the moment of the occupation of a room and related to the features:

  • Assign main guest name to the extension, language, and other possible data.
  • Activate the making of outgoing calls at the level to be determined.
  • Cancellation of active wake-up calls associated to the extension, programmed in the previous stay, and not cancelled or carried out

II. Action UPDATE:

Modification of main guest or Stay data. Request sent in the case of data modification and related to
the features:

  • Assign guest name to extension, language, and other possible data.

III. Action MOVE:

Change of extension. Request sent in the case of a room change and related to the features:

  • Transfer basic configuration from source extension to destination extension: Name, language, other guest data, call restrictions.
  • Transfer of associate services from source extension to destination extension: Do Not Disturb, message waiting, wake-up calls.

IV. Action CHECKOUT:

Guest checkout. Request sent at the time of leaving a Room and related to the features:

  • Assigning the physical address of the extension as the name of the extension. Deleting of other associated data.
  • Restrict the making of outgoing calls.
  • Eliminate additional associated services: Message Waiting, Do Not Disturb

Since there may be cases of CHECKOUT prior to the guest’s departure, normally in the early hours of the morning
and to facilitate mass departures, possible active wake-up calls should NOT be cancelled.

V. Action WAKE:

Setting / cancellation of wake-up calls.

  • Activate / cancel wake-up call. Normally, given the purpose of this service, only one wake-up call is allowed to be activated per extension, so the activation of a new wake-up call would cancel possible active wake-up calls previously done.
  • Usually, the activation / cancellation of a wake-up call generates a specific message from the PBX system, as confirmation of the action.

VI. Action DND:

Activation / cancellation of ‘Do Not Disturb’ status.

  • Activate / cancel the status.

VII. Action WMSG:

Activation / cancellation of message waiting.

  • Activate / cancel the message waiting’s indicator.

VIII. Action COS:

Assignment of call making restriction level (Class Of Service).

  • Assigns level to the extension.

IX. Action SMDR:

Request for messages and data to be sent by the PBX system (Station Message Detail Recording).

Because the PBX system assumes only the role of http server (by default), the data to be transmitted to pmslink
must be stored temporally until pmslink makes a request to obtain it.

Hereby the PBX system will have to:

  • Store internally and temporarily the data to be sent.
  • Attend the GET requests made by pmslink, returning the pending data since the last request.
  • Update the internal control of data already sent, deleting the temporary storage of each request.

Data that can be sent:

  • Dialling of cleaning codes (housekeeping).
  • Dialling of article codes consumed in the minibar.
  • Wake-up calls results.
  • Records of calls made to the outside (outgoing calls).
  • Records of internal calls (Internal calls).
  • Records of calls received from outside (incoming calls).
  • Records of wake-up activation / cancellation.
  • Records of ‘Do Not Disturb’ activation / cancellation.

Connection Methods

Protocol:

HTTP o HTTPS as supported by the PBX system server.

HTTPS is recommended in all cases and especially in the case of Cloud PBX systems

URLs:

The HTTP/HTTPS server of the PBX system shall provide endpoints for the different actions and data requested
by pmslink. These endpoints may be:

  • Common for all requirements. The details of the action and data needed shall be included in the body
    of the request. Example: https://pbx.api.com.
  • Specific for each requirement: Each action or request must be directed to a specific endpoint. Example:
    https://pbx.api.com/checkin, https://pbx.api.com/move.

In all cases the detail of the action and necessary data will be included in the body of the request.

Data formatting:

JSON in all cases.

The real formatting will be using ‘integer’ + separation (‘.’) + ‘decimal’ using two digits. Example: 123.50.

Date values will be expressed in format “YYYY/MM/DDTHH:MM:SS” and will refer to the local time (and time
zone) for each installation. Ex: 01/01/2050 at 10:30 = 20500101103000.

The language codes used will be the ones according to ISO 639-1.

Authentication:

HTTP BASIC AUTHENTICATION: authentication done using user / password according to RFC 7617 specifications.

Note: Exists other possibilities to authenticate if it is needed. Please contact us.

HTTP commands:

POST in all cases, indicating in the body the necessary parameters for its execution in JSON format.

Confirmations and replies:

  • 400 – Bad Request. – The information cannot be processed due to a syntax error.
  • 401 – Unauthorized. – Authentication error.
  • 403- Forbidden. – Error with the data received.
  • 500 – Internal Server Error. – Process cannot be done due to an internal error.
  • 200 – OK in the rest of the cases. JSON structure will be returned with details of the execution of the request, with the following parameters:
NameTypeValue
codeintegerResult code to be defined by the PBX system. The code ‘0’ will indicate request made.Codes greater than 99 will indicate that the action could not be performed dueto temporary causes and pmslink must retry the sending. E.g.: system busy.Codes between 0 and 99 indicate that the action is not possible in any case and the request will be rejected indefinitely under the current circumstances. E.g.: Extension does not exist.
descriptionstringResult description.In case of an error, it must be descriptive enough to be interpreted correctly by pmslink technical support in order to resolve or communicate with the PBX system for the resolution.

EXAMPLE: POST

{"code": 0, "description": "success"}

Connection control:

char pmslink will keep a buffer (FIFO method) as a queue for pending information to be sent in the following
cases:

  • Physical linking errors with the integrated system server.
  • Actions that return the following codes: 400, 401 and/or 500. Those are addressed as one-time errors. Which will be assumed that will be recovered by the server or settings adjustments that will allow the process.

In case of connection errors, char pmslink will retry to resend in a programmed frequency all the information on that queue.


PMS > PBX System

Checkin Action

Sent by the PMS through char pmslink to the PBX system integrated during the guest’s arrival.

DataMandatoryTypeNameValue
Action IDYESstringactionCHKI
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX ExtensionYESstringextension_idIdentifier of the extension in the PBX system. May or may not match the room.
Extension nameYESstringextension_nameValue to be assigned as the name of the extension to be shown literally on the display of the terminal that answers the guest calls
Guest’s namestringnameName of the main guest to be shown literally on the display of the terminal handling guest calls.
Guest’s surnamestringsurnameSurname of the main guest to be shown literally on the display of the terminal handling guest calls.
LanguagestringlanguageLanguage code (ISO 639-1):
* For use in voice guides and messages
* To be shown on the display of the terminal handling guest calls.
VIP levelstringlevelVIP level to be shown literally on the display of the terminal handling guest calls.
Arrival DatestringarrivalArrival Date and Time using the format YYYY/MM/DDTHH:MM:SS to be shown in standard format on the display of the terminal handling guest calls.
Departure DatestringdepartureDeparture Date and Time using the format YYYY/MM/DDTHH:MM:SS to be shown in standard format on the display of the terminal handling guest calls.
Class Of ServicestringcosRestriction level for making telephone calls according to the PBX system configuration.

Example: POST

Request
{
    "action": "CHKI",
    "hotel_id": "myhotel",
    "extension_id": "1001",
    "extension_name": "John Doe",
    "name": "John",
    "surname": "Doe",
    "language": "EN",
    "level": "VIP",
    "arrival": "2050/21/09T15:00:00",
    "departure": "2050/30/09T12:00:00",
    "cos": "1"
}
Response
{
    "code": 0,
    "description": "success"
}

Update Action

Sent by the PMS through char pmslink to the PBX system during a guest data modification.

DataMandatoryTypeNameValue
Action IDYESstringactionUPDATE
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX ExtensionYESstringextension_idIdentifier of the extension in the PBX system. May or may not match the room.
Extension nameYESstringextension_nameValue to be assigned as the name of the extension to be shown literally on the display of the terminal that answers the guest calls
Guest’s namestringnameName of the main guest to be shown literally on the display of the terminal handling guest calls.
Guest’s surnamestringsurnameSurname of the main guest to be shown literally on the display of the terminal handling guest calls.
LanguagestringlanguageLanguage code (ISO 639-1):
* For use in voice guides and messages
* To be shown on the display of the terminal handling guest calls.
VIP levelstringlevelVIP level to be shown literally on the display of the terminal handling guest calls.
Arrival DatestringarrivalArrival Date and Time using the format YYYY/MM/DDTHH:MM:SS to be shown in standard format on the display of the terminal handling guest calls.
Departure DatestringdepartureDeparture Date and Time using the format YYYY/MM/DDTHH:MM:SS to be shown in standard format on the display of the terminal handling guest calls.
Class Of ServicestringcosRestriction level for making telephone calls according to the PBX system configuration.

Example: POST

Request
{
    "action": "UPDATE",
    "hotel_id": "myhotel",
    "extension_id": "1001",
    "extension_name": "John Doe",
    "name": "John",
    "surname": "Doe",
    "language": "EN",
    "level": "VIP",
    "arrival": "2050/21/09T15:00:00",
    "departure": "2050/30/09T12:00:00",
    "cos": "1"
}
Response
{
    "code": 0,
    "description": "success"
}

Move Action

Sent by the PMS through char pmslink to the PBX system during a room change.

DataMandatoryTypeNameValue
Action IDYESstringactionMOVE
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
Origin PBX
extension
YESstringextension_idOrigin extension in the PBX system. May or may not match the room.
Destination PBX extensionYESstringdestination_idDestination extension in the PBX system. May
or may not match the room.

Example: POST

Request
{
    "action": "MOVE",
    "hotel_id": "myhotel",
    "extension_id": "1001",
    "destination_id": "2003"
}
Response
{
    "code": 0,
    "description": "success"
}

Checkout Action

Sent by the PMS through char pmslink to the PBX system at guest’s departure.

DataMandatoryTypeNameValue
Action IDYESstringactionCHKO
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX ExtensionYESstringextension_idIdentifier of the extension in the PBX system.
May or may not match the room.

Example: POST

Request
{
    "action": "CHKO",
    "hotel_id": "myhotel",
    "extension_id": "1001"
}
Response
{
    "code": 0,
    "description": "success"
}

Cos Action

Sent by the PMS through char pmslink to the PBX system in order to apply a Class of Service.

COS action is to restrict or allow calls on the PBX’s extension.

DataMandatoryTypeNameValue
Action IDYESstringactionCOS
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX ExtensionYESstringextension_idIdentifier of the extension in the PBX system.
May or may not match the room.
Class Of ServiceYESstringcosClass of Service to be assigned, according with
PBX system.

Example: POST

Request
{
    "action": "COS",
    "hotelid": "myhotel",
    "extension_id": "1001",
    "cos": "3"
}
Response
{
    "code": 0,
    "description": "success"
}

DND Action

Sent by the PMS through char pmslink to the PBX system indicating that the guest would like/would not like
to receive communications, for example phone calls or hotel services.

DataMandatoryTypeNameValue
Action IDYESstringactionDND
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX ExtensionYESstringextension_idIdentifier of the extension in the PBX system.
May or may not match the room.
Do Not Disturb statusYESbooleanactiveActivated (true), Deactivated (false).

Example: POST

Request
{
    "action": "DND",
    "hotel_id": "myhotel",
    "extension_id": "1001",
    "active": true
}
Response
{
    "code": 0,
    "description": "success"
}

WMSG Action

Sent by the PMS through char pmslink to the PBX system reporting that there are messages to be
transmitted/sent to the guest.

DataMandatoryTypeNameValue
Action IDYESstringactionWMSG
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX ExtensionYESstringextension_idIdentifier of the extension in the PBX system.
May or may not match the room.
Waiting message statusYESbooleanactiveActivated (true) Deactivated (false).

Example: POST

Request
{
    "acrion": "WMSG",
    "hotel_id": "myhotel",
    "extension_id" : "1001",
    "active": true
}
Response
{
    "code": 0,
    "description": "success"
}

Wake Action

Sent by the PMS through char pmslink to the PBX system in order to setup/cancel a wakeup call.

DataMandatoryTypeNameValue
Action IDYESstringactionWAKE
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX ExtensionYESstringextension_idIdentifier of the extension in the PBX system.
May or may not match the room.
Wake up actionYESstringwake_actionS: Setting up.
C: Cancellation.
Wake IDstringwake_uidWake up unique ID.
Wake up timeYESYstringwake_timeWake up date-time (YYYY/MM/DDTHH:MM:SS)

Example: POST

Request
{
    "action": "WAKE",
    "hotelid": "myhotel",
    "extension_id": "1001",
    "wake_action":"S"
    "wake_uid": "12345",
    "wake_time": "2050/09/21T09:00:00"
}
Response
{
    "code": 0,
    "description": "success"
}

GET_SMDR Action

Sent by char pmslink as request to the PBX system regarding pending actions and data to be sent to the PMS
(stored on queue such as phone calls, charges, status.).

In the case of having messages to be processed, the PBX system will provide (maximum) 100 messages per
request and will delete them from its queue list.

In the case of having and empty list, it will confirm the processing using the code HTTP 200 (OK) with its result,
without including data into the reply.

Request
DataMandatoryTypeNameValue
Action IDYESstringactionGET_SMDR
Hotel ID(YES)stringhotel_idHotel’s ID for each installation. Mandatory on multi – hotel scenarios.
Reply
DataMandatoryTypeNameValue
Result codeYESintegercodeResult code
Result descriptionYESstringdescriptionDescription of the result. Example: “data” o “no
data”.
SMDR listYESstringSMDRIdentifier of the array of objects containing the
different data records.
Data typeYESstringsmdr_typeC: Phone call
P: Charge mini bar
S: Room status code
W: Wake up message
D: Do Not Disturb status
Date – timeYESstringdatetimeDate – Time of record creation in format
YYYY/MM/DDTHH:MM:SS
PBX ExtensionYESstringextension_idIdentifier of the extension in the PBX system.
May or may not match the room.
Specific data
according to Data Type
YESstringdataIdentifier of the object containing the specified
data according to Data type.

Data and structure will depend according to the Data Type

Example: POST

Request
{
    "action": "GET_SMDR",
    "hotelid": "myhotel"
}
Response
{
    "code": 0,
     "description": "data",
     "SMDR":
    [
        {
            "smdr_type": "C",
            "datetime": "2050/09/21T14:29:34",
            "extension_id": "1001",
            "data":
                {
                    "call_type": "O",
                    "line": "SIP_ 12345",
                    "connected": "90985630987642",
                    "response": 4,
                    "duration": 98,
                    "units": 25,
                    "cost": 14.23
                 }
        },
        {
            "smdr_type": "P",
            "datetime": "2050/09/21T14:41:12",
            "extension_id": "1002",
            "data":
                 {
                    "post_type": "M",
                    "article": "32"
                 }
        },
        {
            "smdr_type": "S",
            "datetime": "2050/09/21T14:42:21",
            "extension_id": "1002",
            "data":
                {
                    "room_status": "2",
                    "maid": "45"
                }
        },
        {
            "smdr_type": "W",
            "datetime": "2050/09/21T14:44:32",
            "extension_id": "2002",
            "data":
                {
                    "wake_type": "E",
                    "wake_uid": "28390405872567384747",
                    "wake_time" : "2050/09/22T09:00:00"
                }
        },
        {
            "smdr_type": "D",
            "datetime": "2050/09/21T14:49:20",
            "extension_id": "2009",
            "data":
                {
                    "active": false
                }
        }
    ]
}

Specific data according to Data Type

‘C’ – PHONE CALL data

Phone call data and structure (for charging and/or communication’s registry) received as part of the reply for
Action GET_SMDR (Data Type ‘C’).

DataMandatoryTypeNameValue
Phone call typeYESintegercall_typeO: Outgoing call
I: Incoming call
L: Internal outgoing call
LinestringlineType of Phone’s link used
Phone NumberYESstringconnectedOutbound: Called, external destination
Inbound: Caller, external origin
Internal: Called, internal destination
Response timeintegerresponseResponse time in seconds
Call durationYESintegerdurationCall duration in seconds (0 = not
answered)
Call accounting
units
integerunitsCharge units (outgoing call).
Phone call costrealcostPhone call cost (outgoing call).The assignment of the cost of a call will be made:1. Assigning the value ‘price’2. Calculating ‘units’ x Price per unit configured in pmslink3. According to tariffs configured in pmslink based on call destination (connected) and call duration.

‘P’ – CHARGE data

Charge Minibar received as part of the response for Action GET_SMDR. (Data Type ‘P’).

DataMandatoryTypeNameValue
Charge typeYESpost_typeactionM: Minibar
ArticleYESstringarticleArticle code dialled on the room’s telephone for the service

‘S’ – ROOM STATUS data

Room status data and structure received as part of the response for Action GET_SMDR. (Data Type ‘S’).

DataMandatoryTypeNameValue
Room statusYESstringroom_statusRoom status code dialled on the room’ telephone for the service.
Worker/MaidstringmaidWorker/Maid ID code.

‘W’ – WAKE UP data

Wake Up data and structure received as part of the response for Action GET_SMDR. (Data Type ‘W’).

DataMandatoryTypeNameValue
Message typeYESstringwake_typeS: Setting up
C: Cancellation
E: Executed
F: Not answered/failure
Wake up UIDstringwake_uidWake up unique ID.
Wake up TimeYESstringwake_timeWake up Date-Time in format YYYY/MM/DDTHH:MM:SS

‘D’ – DO NOT DISTURB (DND) data

Do Not Disturb (DND) data and structure received as part of the response for Action GET_SMDR. (Data Type e “D”).

DataMandatoryTypeNameValue
Do Not Disturb statusYESbooleanactviveActivated (true), deactivated (false).

 

Table of Contents