SDMP API Update

Message	Description
Make Call [MC]	This message has a new parameter Call Expiry (CE). Formatting is same as the Planned Time (PT) parameter, and is treated as local time (as per PT parameter). If calls are not dialed by the expiry time, Softdial CallGem™ returns the call undialed with Reason Code (RE) of 0 (Number Back [NB] message). If the PT parameter is specified, any CE parameter is ignored.

The functional changes to the protocol are small. 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 SDMP 2.0:

CG:CA:OC\TDdefault\CNHello

Type of Service may be:

• CG - CallGem
• CM - Campaign Manager
• NS - Namespace
• RI - Routing Information

Interface ID is implementation dependent as described below:

Application	Implements...	Description
Softdial CallGem™	AG CA CT MA	Softdial CallGem™'s four logical interfaces: Agent Campaign CTI Management
Softdial Campaign Manager™	DE	Default
Namespace	DE	Default
Routing Information	DE	Default

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.

From V10, SDMP2 framing is fully supported by

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

RouterNET, our high level API component offers Interfaces to

• Softdial CallGem™
• Softdial Campaign Manager™ Server

These interfaces are implemented using SDMP2 framing.

It is possible to work out from the message framing and body of a message, 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.

There is a Type of Service, RI (Routing information) and Interface ID, DE (default) that implements a set of messages and event messages to deal with exchanging routing information. Softdial services that support routing of SDMP2 traffic implement this set of messages.

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

Also affected by this framing change are log files for Softdial CallGem™ and Softdial Campaign Manager™ Server, which 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.

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 <-> dialer <-> campaign manager

The rules for generating OI are similar to that for a Token (TK). The 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. e.g. Some requests may result in a single response, e.g. the Get Columns [GC] request; other requests may result in multiple responses until cancellation, e.g. the enumeration messages (Enumerate Agents [EA], Enumerate Campaigns [EC], etc) or Softdial Campaign Manager™ Status Broadcast [SB].

If communicating directly with Softdial CallGem™, APIs that belongs to Softdial CallGem™ (CG: prefixed messages) do not strictly require OI parameter, since the message is going directly to Softdial CallGem™ and Softdial CallGem™ coordinates the message routing. In this situation, adding an 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 OI param is mandatory. You can use some combination (but not all) of the following to construct a unique OI value:

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

Softdial Campaign Manager™ Status Request [SR] and the Status Broadcast [SB] response works in one of 2 ways as shown below.

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

Included with the GA V10 installer (V10.0.0.55 and above) is a sample C# project and compiled application showing basic use of the new messages . This can be found in 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).

For more information, see the Softdial Campaign Manager™ RouterNET Integration.