Simplified Message Desk Interface (SMDI) Primer
- Nathaniel Halbrooks
Introduction
The SMDI protocol is an integration protocol that uses a serial connection as its transport and was designed specifically to act as an out of band data path between PBX systems and voice mail/IVR systems. This protocol is an open standard that is used across a wide range of PBX systems from Central office PBXs like the DMS100 and 5ESS series to smaller on premise systems.
Â
The protocol is a very compact delimited stream of ASCII characters that carries the following information as a payload:
Â
Tenant Number (Message Desk Number)
Line Number (Logicial Terminal Number / Logical Extension Number)
Called Party
Calling Party
Call Reason
Here is a diagram showing a typical layout using a 1000 or 2000 series Dialogic Media Gateway with a serial SMDI link connecting to either a PBX or a Central Offce connection.Â
Â
The protocol also allows for requests to be sent back to the PBX to activate message waiting mechanisms such as lights, phone set display prompts or stutter dial tone.
Protocol Details
The SMDI protocol is comprised of 3 dfferent packet types for call integration data and 3 different types for MWI requests.
Call Integration Packets
NOTE
These packets are only sent from the source (PBX or Central Office) to the gateway serial port.
Type #1 - Two party call with call data available for both parties
<cr><lf>MDNNNMMMRXXXXXXXXXX<sp>YYYYYYYYYY<sp><cr><lf><^y>
Â
Type #2 - Two party call with no calling party data available
<cr><lf>MDNNNMMMMRXXXXXXXXXX<sp><sp><cr><lf><^y>
Â
Type #3 - Direct call
<cr><lf>MDNNNMMMMR<sp>YYYYYYYYYY<sp><cr><lf><^y>
Parameter DefinitionsÂ
Symbol | Definition | Hex Value | Valid Value Range |
<cr> | Carriage Return | 0D | Â |
<sp> | Space | 20 | Â |
<lf> | Line Feed | 0A | Â |
<^y> | Control Y | 19 | Â |
MD | Delimiter | 4D 44 | Â |
NNN | Message Desk Number | Â | Â |
MMMM | Logical Terminal Number | 30 - 39 | 0000-9999 (must be a complete 4 character string) |
R | Call Reason | 41 | A = forward all calls |
XXXXXXXXXX | Called Party (forwarding) | 30 - 39 | This parameter can be 7-digit, 10-digit, or 1-10 variable length digit. It is shown in the default of 10-digits |
YYYYYYYYYY | Calling Party | 30 - 39 | This parameter can be 7-digit, 10-digit, or 1-10 variable length digit. It is shown in the default of 10-digits |
Message Waiting Packets
NOTE
These packets will flow in both directions between the PBX or Central Offcie and the gateway. Each packet description will denote its direction.
Â
Type #1 - Activate an Indicator (gateway sends packet out to set a light)
OP:MWI<sp>XXXXXXXXXX!<^d>
Â
Type #2 - Deactivate an Indicator (gateway send packet out to clear a light)
RMV:MWI<sp>XXXXXXXXXX!<^d>
Â
Type #3 - Invalid Station Number Packet (sent to gateway in response to a request that cannot be processed)
<cr><lf>MWIXXXXXXXXXX<sp>INV<cr><lf><dl><dl><^y>
Â
Parameter Definitions
Symbol | Definition | Hex Value | Valid Value Range |
<cr> | Carriage Return | 0D | Â |
<sp> | Space | 20 | Â |
<lf> | Line Feed | 0A | Â |
<^y> | Control Y | 19 | Â |
<^D> | Control D | 04 | Â |
<dl> | Delete | FFÂ | Â |
! | Delimiter | 21 | Â |
XXXXXXXXXX | Notification Party | 30 - 39 | This parameter can be 7-digit, 10-digit, or 1-10 variable length digit. It is shown in the default of 10-digits |
Relevant Trace Data
To properly diagnose issues related to serial data you should be reviewing the debug emitted by the SI trace keys. The 'prot' and 'code' levels provide key information in troubleshooting problems related to this serial protocol. See the product documentation or additional technical notes on how to enable and read this trace data.
Â
When using multiple gateways in a cluster you can use the SI trace key to monitor all the raw serial data sent to the gateway designated as the serial master. You can view this data as it is sent out to the serial slave gateways by enabling the SIIP key on those gateways.
NOTE
This specification is very standardized and has been in use for a large number of years. The formatting of the packets is critical to the gateways ability to properly judge a packets integrity so if you are receiving data packets that have characters outside the allowed ranges or in the improper order the gateway firmware may not be able to interpret them properly. The firmware has been optimized to allow for a certain amount of data corruption while still maintaining data integrity but if you suspect problems contact Dialogic support with a sample of your serial data and we can help you determine where the is and what may be able to be done about it.
Some PBX vendors may specify that they are SMDI Compliant but unless they follow this rigid standard they may not be truly compliant and may not work properly.
The tenant number (Message Desk Number) part of the message is ignored by the gateway firmware when it arrives so the data in the message itself has no relevance to the integration, only the fact that it contains the characters 'MD' and is followed by 3 other characters.
The line number (Logical Terminal Number / Logical Extension Number) part of the message is critical as it is the part of the message that allows the gateway application to attach a specific integration packet to a specific physical port number. The source of the SMDI data may send you a physical extension number (ie: 0123, 0700, 5000, etc...) or it may send you a logical index number (ie: 0001, 0002, etc...) that shows the ports order in the distribution group assigned to this serial interface. Whatever you are getting you need to make certain that the proper numbers are entered in to the gateway and that the numbers align in the proper order with how they are physically connected to the gateway. Errors here can result in calls without any integration or calls with incorrect integration.
In the case where you need to use multiple gateways together, one must be designated as the serial master and that is the gateway that manages the physical connection between the source of the SMDI data and your cluster of gateways. The remianing gateways in the cluster are then desingated as serial slaves and register with the master gateway to receive thier serial data over a secondary IP communications link.