| CONTACT | DEVELOPER CENTER | PARTNERS | SITEMAP
GO
Useful Links
  • Search Helpweb
    
    

Dialogic Support Helpweb

Dialogic® 1000 and 2000 Media Gateways (DMG series)

Simplified Message Desk Interface (SMDI) Primer

Summary
This document provides basic information about the structure of the Simplified Message Desk Interface (SMDI) integration protocol.

Introduction
The Simplified Message Desk Interface (SMDI) protocol is an integration protocol that uses a serial connection as its transport and that was designed 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:

Below is a diagram showing a typical layout using a Dialogic® 1000 Media Gateway Series or Dialogic® 2000 Media Gateway Series gateway with a serial SMDI link connecting to either a PBX or a Central Office 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
42
44
4E
55
A = forward all calls
B = Busy
D = Direct (only valid for a Type 3 packet)
N = No Answer
U = Unknown
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 (Serial Integration over IP) key on those gateways.

Notes
  1. This specification is standardized and has been in use for many years. The formatting of the packets is critical to a gateway’s ability to properly judge the integrity of packets. Thus, if you are receiving data packets that have characters outside the allowed ranges or that are 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 for help in determining where the problem is and what may be able to be done about it.
  2. Some PBX vendors may specify that they are SMDI Compliant but unless they follow this rigid standard they may not be truly compliant and integration may not work properly.
  3. 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.
  4. 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 (i.e.: 0123, 0700, 5000, etc...) or it may send you a logical index number (i.e.: 0001, 0002, etc...) that shows the order of the ports in the distribution group assigned to this serial interface. Whatever numbers you receive, be sure to enter the proper numbers into the gateway and to align the numbers 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.
  5. In the case where you need to use multiple gateways together, one gateway 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 remaining gateway(s) in the cluster are then designated as serial slaves and register with the master gateway to receive their serial data over a secondary IP communications link.


Feedback

Please rate the usefulness of this page:  

0 - not useful at all
1 - potentially useful
2 - quite useful
3 - very useful
4 - exactly the information I needed     

Please enter a comment about this page: