Routed SDMP (Softdial Message Protocol)

As of release of Version 10, SDMP2 framing is fully supported by

• Softdial CallGem™
• Softdial Campaign Manager™ Server
• Softdial Scripter™ 2 Engine.

RouterNET, our high level API component, offers SDMP2 Interfaces to

• Softdial CallGem™
• Softdial Campaign Manager™ Server

The functional changes to the protocol are small. Firstly, the current framing format

CC\P1[]\P2...

is still supported so there is no need for integrators to change code. This type of framing will be referred to as SDMP.

Message framing for SDMP2 messages is as follows:

AA:BB:CC\P1[]\P2...

where

• AA is a Type of Service indicator
• BB is an Interface ID indicator
• CC is a message code

The Type of Service and Interface ID indicators provide some information about which service the message is sent to, or event message is sent from. For example, the Softdial CallGem™ Open Campaign [OC] message is framed as follows using SDMP2:

CG:CA:OC\TDdefault\CNHello

Possible Types of Service and their permitted Interface IDs are as follows:

Type of Service	Interface ID
CG - Softdial CallGem™	AG - Agent CA - Campaign CT - CTI MA - Management
CM - Softdial Campaign Manager™	DE - default
NS - Namespace
RI - Routing Information

The reason for making this extension is to allow other services within Softdial Contact Center™ to process messages conforming to SDMP protocol framing. This theoretically enables Sytel to provide published APIs to all services.

This framing change also means that log files for Softdial CallGem™ and Softdial Campaign Manager™ Server show the new framing on messages sent using that framing. If you have a home grown log parser application you would need to edit it to take the new framing into account.

From the message framing and body of a message, it is possible to work out exactly which service it ought to be sent to. With some exchange of information between services that support SDMP2, it is possible to set up return routes for events relating to a message or class of message that a client is interested in.

For the exchange of routing information, there is the RI (Routing information) Type of Service (with its associated DE (default) Interface ID). Softdial services that support routing of SDMP2 traffic implement the RI set of messages.

A full discussion of the detail implementation of message routing is beyond the scope of this help document. If a third party integrator has a need to support SDMP2 message routing (unlikely unless you are a network infrastructure provider) then Sytel will provide technical assistance.

Softdial CallGem™ can process SDMP and SDMP2 framing interchangeably. On a given socket connection, it is possible (but not advisable) to mix both types of framing. In order to bring some predictability to the framing of messages Softdial CallGem™ monitors the framing type of messages sent to it from each connection. After 20 consecutive messages with the same framing, Softdial CallGem™ 'hardens' the socket to support only that type of framing. This ensures that applications that are written to deal with only one frame type for event messages will work reliably.

An SDMP2 message that is sent to a service (e.g. Softdial Campaign Manager™) via Softdial CallGem™, must have an Originator ID (OI) parameter attached. This provides message routing detail such that there is a recorded path in all supporting SDMP2 services between the sender and the destination service, i.e.

application <-> callgem <-> campaign manager

The rules for generating Originator ID (OI) are similar to that for a Token (TK). The Originator ID (OI) value must be a string that uniquely identifies the originator of the message for the duration of the message exchange across all activity for the tenant at any given time.

Some requests may result in a single response, e.g. the Get Columns [GC] request (CM:DE:GC)

Other requests may result in multiple responses until cancellation, e.g. the enumeration messages or Softdial Campaign Manager™ Status Broadcast [SB].

If communicating directly with Softdial CallGem™, APIs that belong to Softdial CallGem™ (CG: prefixed messages), do not strictly require Originator ID (OI), since the message is going directly to Softdial CallGem™ and Softdial CallGem™ coordinates the message routing. In this situation, adding an Originator ID (OI) parameter is still valid, though not necessary.

However, if sending a request that belongs to another service, e.g. Softdial Campaign Manager™ (CM: prefix), then the Originator ID (OI) parameter is mandatory.

To construct a unique Originator ID (OI) value, you can use some combination (but not all) of

• the application name
• the machine name
• a tenant name
• a GUID
• a sequential count

See also RouterNET Integration.

The Softdial Campaign Manager™ Status Request [SR] and the Status Broadcast [SB] response (CM:DE:SB) works in one of 2 ways as shown below

The values for Originator ID (OI) and Token (TK) presented here are not good examples (not very unique), but sufficient to demonstrate it working.

A sample C# project and compiled application (showing basic use of the new messages included with V10.0.0.55 and above) can be found at C:\Softdial\Samples\CS\SDMPSample.

You will need to repair the references to the RouterNet and SytelMdn2 dlls, both of which can be found in the root Softdial folder (C:\Softdial).

See also RouterNET Integration.