/
PMS Setup

PMS Setup

All Voiceware to PMS configuration settings are controlled here. Voiceware can use either serial (preferred) or TCP/IP to connect to a PMS system. Note that because we can use TCP/IP the PMS can be hosted and does not need to reside onsite. The interface page is divided into three sections; the PBX interface (check-ins / check-outs), Call Accounting interface (call billing) and the debug window with command interface. Descriptions of the fields can be found below but the actual settings must be agreed between Voiceware and the PMS manufacture. When calling the PMS company make sure to have the property code (ask the hotels GM for it) as this is the only way most PMS companies will be able to look up the account.

Version: 4.3.0.4

New

Dropdown selection of the serial port.

Phonesuite Serial Simulator

Psip-PMS Version: 2.115

Upgrading to Voiceware version 4 on older hardware might change the serial port numbering from 0 and 1 to 1 and 2.

How to section

There are many commands that can be issued along with an example of each, they are:

  • Test Serial Areyouthere. Tests if we can send an ENQ and receive an ACK, generally means that the cables are good and the serial settings are correct.

    • Test Serial Areyouthere

  • Test Serial Dosynch. Requests a database dump from the PMS, note this command is ignored by the PMS about 50% of the time.

    • Test Serial Dosynch

  • Test Serial Status <room> 0|1|2|…|9

    • Test Serial Status 101 1

  • Test Serial Message <room> 0|1

    • Test Serial Message 101 0

  • Test Call. Sends a billable call event to check call posting. If the call needs to be posted to a specific room enter the room number twice.

    • Test Call

    • Test Call 101 101

  • TRACE (issue command again to turn off). Displays normally non-printable characters (like ACK/NAK).

    • TRACE

  • Test XMLRPC Areyouthere. All XMLRPC messages are sent to Voiceware like we had gotten and translated a command from the PMS, used to ensure Voiceware is working.

    • Test XMLRPC Areyouthere

  • Test XMLRPC Sync [0|1]

    • Test XMLRPC Sync 1

  • Test XMLRPC Checkin <room> <[name]>

    • Test XMLRPC checkin 101 Emma Frost

  • Test XMLRPC Checkout <room>

    • Test XMLRPC Checkout 101

  • Test XMLRPC Name <room> NAM0|NAM1|NAM2|NAM3 <name>

    • Test XMLRPC Name 101 NAM2 Frost, Emma

  • Test XMLRPC Move <room> <newroom>

    • Test XMLRPC Move 101 205

  • Test XMLRPC MWI <room> [0|1]

    • Test XMLRPC MWI 101 1

  • Test XMLRPC Dnd <room> 0|1

    • Test XMLRPC Dnd 101 0

  • Test XMLRPC Restrict <room> 0|1|2|...|9

    • Test XMLRPC Restrict 101 2

  • Test XMLRPC Wakeup <room> <time>|9999

    • Test XMLRPC Wakeup 101 0830

Note that for common commands just the first letter of each command needs to be entered. For example, a test call can be created by typing “t c”, an are you there by typing “t s a”. It’s recommended to spell out the more complex commands fully.

ACK/NAK Messages

Serial communications use a strict set of messages to communicate known as ACK/NAK. Using the trace command all ACK/NAK messages can be displayed. Note that only the ASCII numbers for the messages are displayed.

Message

ASCII

Meaning

Message

ASCII

Meaning

STS

2

Start of Text

ETX

3

End of Text

ENQ

5

Enquiry

ACK

6

Acknowledgement

Sender

ENQ (5)

 

STX (2)[Message]ETX (3)

 

Receiver

 

ACK (6)

 

ACK (6)

 

Normal Check In Message

Below is what a working check in message looks like. Note in this example there is a / between the last name and first name.

 

Check In with Wrong Name Delimiter

Next is the same check in message but this time the PMS used a comma between the first and last name. The result is that the guests first and last name get placed into the first name column.

 

Check In with Invalid Room Number

In this example we see the PMS tried to check a guest into room 7101, however there was no room 7101 and thus there was an XMLRPC error and the result of the XML call was -1.

 

CA Whoops Error

Here we see what happens if we get a message on the CA interface. If this happens it normally means that the CA and PBX serial cables are swapped.

When Psip starts up it dumps about 50 lines of logs on the screen at once. These log files have some helpful info in them including:

Version

Here we see that Psip-PMS is on version 2.115.

Message Formatting Check

When Psip reads in a line of code, like that telling Psip what format to expect a check in message, Psip will return a code if the message was accepted or rejected.

An accepted message returns code 01

A failed message returns the code of 201.

In the above case we have a typo in our additional parameters box and Psip has rejected the message.

Its important to check the response codes when using additional parameters to ensure your messages are understood by Psip.

Most PMS systems use a comma to separate guest first and last names. However some PMS systems will use a slash or space. When this happens Psip does not know how to split the guests name and the result is the entire first and last name along with the slash or space being placed into the guest last name field.

Below are the lines of code that can be added to the additional parameters field to correct this.

[pbx-masks]

chkdelim=11 20 MASK_LITERAL /

namdelim=6 20 MASK_LITERAL /

 

If a space is being used add the following.

[pbx-masks]

chkdelim=11 20 MASK_LITERAL SPACE

namdelim=6 20 MASK_LITERAL SPACE

When using a hosted system with an onsite proxy system it is helpful to be able to connect the PMS to the proxy box but have the hosted system be the main Psip and simply have the proxy also be the proxy for the serial ports. To accomplish this there are three things to do/setup.

Proxy System Setup - Setup both the PBX and CA interfaces with the correct serial interface information. - In the Additional Parameters box enter:

[xmlrpc] server=http://<hosted IP>/phonesuite/xml-rpc.php?action=PMS

Replace the IP address listed with the IP address of the Hosted system

  • Enter the below two commands via SSH replacing the IP listed with the Hosted system's IP address

iptables -I trusted -s <hosted IP> -j ACCEPT

/etc/init.d/iptables save

For Voiceware 4.1 run these commands:

firewall-cmd --permanent --new-zone=pms

firewall-cmd --permanent --zone=pms --add-port xxxx/tcp

firewall-cmd --permanent --zone=pms --add-source=x.x.x.x

firewall-cmd --reload

To test you can also run these commands:

firewall-cmd --get-active-zones

firewall-cmd --list-all

firewall-cmd --list-all-zones

  • Make sure the PMS interface is enabled on the settings page - Click Save/Restart for the PMS interface

 

Local Firewall Setup - Add a rule to accept traffic from port 8080 and direct it do the Proxy Voiceware system.

 

Hosted System Setup - Edit the file /etc/asgi/settings.ini (4.1 /data/asgi/settings.ini) - Under the section "[PMS]" change the IP address from 127.0.0.1 to the public IP address of the Proxy (not hosted) system - Disable both PBX and CA interfaces - Make sure the PMS interface is enabled on the settings page - Click Save/Restart for the PMS interface.

 

Testing To test that everything has been setup correctly issue the SSH command "telnet <Proxy IP> 8080" from the hosted system using the IP of the proxy system. If everything has been setup correctly you should see:

telnet 12.34.56.78 8080

Trying 12.34.56.78...

Connected to 12.34.56.78.

If it does not work you should see:

telnet 12.34.56.78 8085

Trying 12.34.56.78...

Visual Overview

 

Line by Line Explanation

Please note some fields are have a bracket containing TCP/IP. These fields are only needed if the corresponding method is selected.

This is set to either Serial or TCP/IP. When selecting TCP/IP the options available to you will be automatically limited to what is needed in a TCP/IP connection. Note for this to work you must whitelist the port and IP within Voiceware’s built in firewall.

Instructions for opening ports in the Voiceware Firewall are below.

This drop-down allows the selection of the serial interfaces, normally ttyS0 and 1.

If a USB to Serial converter is installed reload the page to see it in the drop down list.

If upgrading from an older version of Voiceware the serial ports can change numbering from 0 and 1 to 1 and 2.

Baud rates can be between 19200 to 300, most commonly this baud rate will be set to either 1200 or 9600.

This is the size of the data packets sent, most commonly 8 will be used.

Parity is an error checking algorithm used on Serial interfaces. Options here are Odd, Even and None with None being the most common.

Stop bits are used to indicate the message end, similar to a period at the end of a sentence. Normally 1 stop bit is used but 0 and 2 are available.

This drop-down lists contains all the pre-written interface files Voiceware has to communicate with different PMS systems. Note that in some cases such as Opera there are standard opera interface files and then a secondary one marked with a “#2”. These second (and sometimes third) protocol files are used to correct for differences in how PMS companies send guest check-in records. Normally the standard file works fine and the secondary file should only be used if guest names are not appearing correctly or the guest check-in record is being missed completely. Below is a list of the different files and what the differences between them are. Lastly note that the order of the files is not guaranteed to be the same in every system.

Protocol File Description

CHOICE – Choice advantage protocol on serial interface: Standard interface for Choice.

CHOICE2 – Choice advantage protocol #2 on serial interface: This file corrects an issue where the guest change name message was longer than expected resulting in the name not getting updated. Use this file if the rooms are getting checked in with a blank guest name.

COMTROL – Comtrol uses an interface translator called UHLL, this middleware will translate PBX messages into messages understood by Voiceware. In most cases if Comtro is in use only the PBX interface needs to be set to Comtrol and the Call Accounting interface will be set to Disabled. This is done because both the PBX and CA messages are sent using the same cable. As of 10/22/14 only IQWare PMS is using the Comtrol interface.

DEBUG – Debug protocol for PBX interface. This protocol disregards the normal ACK/NAK requirements for messages and simply displays all information that arrives over the interface. This info might be background noise or complete garbage messages. As the name implies this protol is used only to debug interface issues and does not have any ability to send or receive normal PBX messages.

DEFAULT – Default pbx-pms interface from factory: This interface type emulates a MiTell system and can be used when the interfacing PMS does not have a PhoneSuite setting but has a MiTel option.

DEFAULT2 - Default pbx-pms interface from factory: This file corrects an issue where the guest change name message was longer than expected resulting in the name not getting updated. Use this file if the rooms are getting checked in with a blank guest name.

EPIT-HIT – Default Epitome Hitachi Emulation interface. This interface emulates an Hitachi machine for use with the Epitome system used a Navy NGIS and Navy Lodge locations.

EPIT-HIT2 – This interface corrects an issue where the room number and name don’t appear where expected. Use this interface if normal check-ins completely fail (no guest is checked in, even one with a blank name).

FIAS – Mircos Opera FIAL protocol on TCP/IP interface: Standard interface for FIAS using TCP/IP.

FIAS2 – Mrico FIAS Defero 3 Mimic Interface: This protocol emulates a Defero system. Use this if the connection PMS does not have a PhoneSuite interface option but has a Defero 3 option.

FIAS-Official – This interface is our officially approved interface for use with FIAS/Oracle systems. Our part number is IO-5001-394 for product ID IFC_VPS. It is for use with OPERA 5.0.04.01 and above, FIAS 2.20, and IFC8.8.2.2 and above.

FOSSE – FOSSE protocol on serial interface: Standard interface for FOSSE approved by Fosse 12/28/2017.

FOSSE2 – FOSSE protocol #2 on serial interface: This file corrects an issue where the guest change name message was longer than expected resulting in the name not getting updated. Use this file if the rooms are getting checked in with a blank guest name. Approved by Fosse 12/28/2017.

GALAXY – Galaxy/Lightspped protocol on serial interface: Standard interface for Galaxy.

GALAXY2 – GALAXY protocol #2 on serial interface: This file corrects an issue where the guest change name message was longer than expected resulting in the name not getting updated. Use this file if the rooms are getting checked in with a blank guest name.

Marriott-MS-Official – This is the officially approved interface for Marriott mid-scale hotels.

ONQ – OnQ protocol on serial interface: Standard interface for OnQ using serial.

ONQ2 – OnQ Protocol #2 on Serial Interface: This file corrects an issue where the guest change name message was longer than expected resulting in the name not getting updated. Use this file if the rooms are getting checked in with a blank guest name.

OPERA – Micros Opera protocol on serial interface: Standard interface for Opera.

OPERA2 – Micros Opera protocol #2 on serial interface: This file corrects an issue where the guest change name message was longer than expected resulting in the name not getting updated. Use this file if the rooms are getting checked in with a blank guest name.

OPERAIP – Micros Opera protocol on TCP/IP interface: This is the standard interface when connecting to opera via a TCP/IP connection. Normally the interface file is the same regardless of the connection method selected however Opera requires a slightly different communication protocol when using TCP/IP.

RDP – RDP protocol on serial interface: Standard interface for RDP.

RDP Official – An officially tested and approved interface for RDP Win Interface Monitor V 5.3.002.05. Note only Check in / out, Name change, Room status, and Wakeup call messages work.

SkyTalk – Sky Talk protocol on serial interface: Standard interface for Sky Talk. Note Sky Talk is simply the hosted version of Choice Advantage.

SkyTalk2 – Sky Talk protocol #2 on serial interface: This file corrects an issue where the guest change name message was longer than expected resulting in the name not getting updated. Use this file if the rooms are getting checked in with a blank guest name.

Windguest – Windguest no ENQ/ACK Protocol. This protocol is the same as Default2 with the exception that it does not expect to see an ENQ before the start of text sent over on a check in, check out, etc… message. It is hard to understate the oddity of Windguest behaving in the manner as serial connection protocols are well established and used by every other PMS vender PhoneSuite has had experience with.

BLIND – Call Accounting HOBIS/Holidex Blind Send: This protocol will generate send a costed call as a blind send and will not expect to receive a ACK/NAK message.

CheckIn – Call Accounting CheckIn PMS format. This protocol is very similar to HOBIS with only a few changes. This is a ACK/NAK protocol.

COMTROL – Comtrol Call Accounting Ack-Nak Protocol. Normally this interface type will not need to be selected because the Comtrol PBX interface handles both PBX and CA messages. If a joined interface is being used set the CA interface to disabled.

DEBUG – Debug Call Accounting Protocol. This protocol disregards the normal ACK/NAK requirements for messages and simply displays all information that arrives over the interface. This info might be background noise or complete garbage messages. As the name implies this protol is used only to debug interface issues and does not have any ability to send or receive normal CA messages.

FIAS – Because the CA and PBX interfaces are both built into the PBX FIAS interface the CA interface is not needed. Normally its best to simply disable the CA interface. This protocol, if selected, will simply disable the interface. This was done simply to work around errors where the CA interface would be turned on when using FIAS and thus cause problems.

Fossie – Default ACK/NAK Fossie protocol. Approved by Fosse 12/28/2017.

Hansen – Default CA ACK/NAK protocol for the Hansen PMS system.

HOBIS – Call Accounting HOBIS/Holidex ACK/NAK Protocol: This is by far the most common type of costed call record format. Unlike the PBX interface most PMS companies have standardized on HOBIS-A and expect to see it in most cases.

HOBIS2 – Much like normal HOBIS but adjusted to account for five digit extension numbers. ACK/NAK protocol.

INFORMXL – Call Accounting InformXL ACK/NAK Protocol: This protocol will emulate an Inform XL call accounting setup and send “TEL” as the property code (see HOBIS interface information below).

LegacyRAW - Raw SMDR in the Legacy format. This is a different type of raw call record format to deal with older systems that need legacy formatted raw call records.

MICROS – Call Accounting HOBIS/Holidex ACK/NAK Protocol: This is a version of the HOBIS-A specifically designed for MICROS. Use only if requested by MICROS.

Microscopic - Default CA ACK/NAK protocol for the Microscopic PMS system.

Navy – Blind send interface for Navy PMS systems.

ProfitWatch – Raw SMDR to Profit Watch: Profit Watch is a call billing system that will apply charges to a call based on its own data tables. As such they simply want the raw data of calling room number, called number, and call length. They then take this data and apply a cost to the call. If this system is being used the Outbound Routes in Voiceware can be ignored.

Prophet – Default H3 version CA ACK/NAK protocol for the Hansen PMS system.

RAWPS – Default raw SMDR protocol used for the Genesis PMS system.

RBS Mimic – Protocol designed to mimic the RBS PBX system/interface type. Used only for Navy installations.

RDP – RDP Call Accounting ACK/NAK Protocol: This is the standard call records formatting for RDP, used only for their system. Deprecated, use HOBIS.

RoomKey – Call Accounting RoomKey Ack_Nak Protocol: Designed specifically for the Room Key PMS System. Call records are formatted the same as HOBIS save the extension number starts one space sooner (at 16 and not 17) and the call duration is sent over in the format of MMSS as opposed to just the MMMM format of the normal HOBIS record.

SummaFour – Default CA ACK/NAK protocol for the SummaFour PMS system.

SummaFour2 – Alternate version one of the SummaFour PMS CA interface. Use only if SummaFour does not work.

SummaFour4 – Alternate version two of the SummaFour PMS CA interface. Use only if SummaFour does not work.

SummaFourOfficial – The official protocol for CA interfaces to Marriott mid-scale hotels. Officially approved by Marriott.

Teletronics - Default CA ACK/NAK protocol for TelEtronics emulation.

ValuePlace - CA Remco RAW for Value Place. Standard blind send for use with ValuePlace installations. Also known as the blind send default for the 112e.

 

HOBIS-A Call Record Format

The HOBIS call record is a standard format that has been in use for many years and is supported by most older PMS systems. A full description can be found here PMS Interface | PMSInterface Call Accounting

 

Additional Parameters

There are several lines that can be added to the additional parameters box to change the way Psip sends data to the PMS. A full write up can be found here PMS Interface | PMSInterface Special Flags

 

 

Related content