Dialogic PowerMedia XMS Message Session Relay Protocol User guide

Brand: Dialogic

Model: PowerMedia XMS Message Session Relay Protocol

Type: User guide

Dialogic® PowerMedia™ XMS

Message Session Relay Protocol Feature Guide

November 2022

4.0

www.dialogic.com

document in whole or in part without permission in writing from Enghouse at the address provided below.

All contents of this document are furnished for informational use only and are subject to change without notice and

do not represent a commitment on the part of Enghouse and its affiliates or subsidiaries ("Enghouse"). Reasonable

effort is made to ensure the accuracy of the information contained in the document. However, Enghouse does not

warrant the accuracy of this information and cannot accept responsibility for errors, inaccuracies or omissions that

may be contained in this document.

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE,

EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY

THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND ENGHOUSE, ENGHOUSE

ASSUMES NO LIABILITY WHATSOEVER, AND ENGHOUSE DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY,

RELATING TO SALE AND/OR USE OF ENGHOUSE PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO

FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY

RIGHT OF A THIRD PARTY.

Enghouse products are not intended for use in certain safety-affecting situations.

Due to differing national regulations and approval requirements, certain Enghouse products may be suitable for use

only in specific countries, and thus may not function properly in other countries. You are responsible for ensuring

that your use of such products occurs only in the countries where such use is suitable. For information on specific

products, contact Enghouse at legal.operations@enghouse.com

It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this

document, in marketing collateral produced by or on web pages maintained by Enghouse may infringe one or more

patents or other intellectual property rights owned by third parties. Enghouse does not provide any intellectual

property licenses with the sale of Enghouse products other than a license to use such product in accordance with

intellectual property owned or validly licensed by Enghouse and no such licenses are provided except pursuant to a

signed agreement with Enghouse. More detailed information about such intellectual property is available from

Enghouse's legal department at 80 Tiverton Court, Suite 800 Markham, Ontario L3R 0G4.

Enghouse encourages all users of its products to procure all necessary intellectual property licenses required to

implement any concepts or applications and does not condone or encourage any intellectual property infringement

and disclaims any responsibility related thereto. These intellectual property licenses may differ from country to

country and it is the responsibility of those who develop the concepts or applications to be aware of and comply

with different national license requirements.

Dialogic, Dialogic Pro, DialogicOne, Dialogic Buzz, Brooktrout, BorderNet, PowerMedia, PowerVille, PowerNova,

ControlSwitch, I-Gate, Veraz, Cantata, TruFax, and NMS Communications, among others as well as related logos,

are either registered trademarks or trademarks of Enghouse and its affiliates or subsidiaries. Enghouse's

trademarks may be used publicly only with permission from Enghouse. Such permission may only be granted by

Enghouse legal department at 80 Tiverton Court, Suite 800 Markham, Ontario L3R 0G4. Any authorized use

of Enghouse's trademarks will be subject to full respect of the trademark guidelines published by Enghouse from

time to time and any use of Enghouse's trademarks requires proper acknowledgement.

The names of actual companies and products mentioned herein are the trademarks of their respective owners.

This document discusses one or more open source products, systems and/or releases. Enghouse is not responsible

for your decision to use open source in connection with Enghouse products (including without limitation those

referred to herein), nor is Enghouse responsible for any present or future effects such usage might have, including

without limitation effects on your products, your business, or your intellectual property rights.

 
3 
Table of Contents 
Dialogic® PowerMedia™ XMS ................................................................................. 1 
1. Overview ....................................................................................................... 5 
MSRP Capabilities............................................................................................ 5 
2. Using Message Session Relay Protocol (MSRP) .............................................. 6 
Message Flow ................................................................................................. 6 
Session Support .............................................................................................. 7 
Limitations and Requirements ........................................................................... 8 
Customer Use Cases ........................................................................................ 8 
Voice Mail Application and Delivery Solution .................................................... 8 
Next Generation Emergency 911 Service ....................................................... 11 
 
 
   
 

Revision History

Revision

Release

Date

Notes

4.0

November

2022

Updates to support PowerMedia XMS

Release 5.1

Enghouse logo was added to the header

along with a new Enghouse copyright

section as per legal.

3.0

March 2016

Updates to support PowerMedia XMS

Release 3.1.

2.0

October 2014

Updates to support PowerMedia XMS

Release 2.3.

1.0

July 2014

Initial version of this document.

Refer to www.dialogic.com for product updates and for information about support policies,

warranty information, and service offerings.

1. Overview

Dialogic® PowerMedia™ Extended Media Server (also referred to herein as "PowerMedia

XMS" or "XMS") supports session-oriented instant messaging protocol called Message

Session Relay Protocol (MSRP). These sessions are used to provide peer-to-peer file or text

transfer, photo sharing, or chat services, and can be negotiated with an offer or answer

model using the Session Description Protocol (SDP). The exchange is carried over a Session

Initiation Protocol (SIP) signaling protocol. This feature allows PowerMedia XMS to offer a

messaging session as one of the possible media-types in a session dialog.

MSRP Capabilities

MSRP uses a connection-based transport called Transmission Control Protocol (TCP) to

transport messages or files. This feature enables PowerMedia XMS to create MSRP

connections and sessions that deliver arbitrary (binary) MIME content payloads. Some

content can include plain text, images, video clips, and binary file transfers over peer-to-

peer TCP connections.

MSRP can also assist applications that wish to use PowerMedia XMS for Short Message

Services (SMS) and Voice Mail Delivery Services in Next Generation Networks that utilize IP

Multimedia System (IMS) Core Network infrastructure.

MSRP protocol works by separating messages or files into chunks and sequencing the end to

end transfer. MSRP has mechanisms to handle chunk by chunk acknowledgements and

retransmissions to assure that data is transferred successfully.

PowerMedia XMS supports establishment of MSRP peer-to-peer instant messaging sessions

with the RESTful API. MSRP session file transfer is supported by MSML and the RESTful API.

For more information, refer to the Dialogic® PowerMedia™ XMS MSML Media Server

Software User's Guide and Dialogic® PowerMedia™ XMS RESTful API User's Guide.

2. Using Message Session Relay Protocol (MSRP)

Message Flow

Figure 1 shows the basic message flow between PowerMedia XMS and a remote MSRP

endpoint. The message flow results in the creation of a TCP connection and a MSRP session.

A SIP dialog is initially established with the remote MSRP endpoint to negotiate session

characteristics and create a TCP connection between the two entities (steps 1-3). In this

example, the message or file is rather long and must be divided or chunked.

Note: The chunks are sent in sequential order without having to wait for a response from

the remote end.

Once the message has been successfully sent and acknowledged (step 7), the session is

terminated and the connection may be dropped if no other sessions are active (steps 8-9).

Figure 1: Basic MSRP Message Flow

(1) (SIP) INVITE

(2) (SIP) 200 OK

(3) (SIP) ACK

(4) (MSRP) SEND (chunk1)

(5) (MSRP) SEND (chunk2)

(6) (MSRP) 200 OK (chunk1)

(7) (MSRP) 200 OK (chunk2)

(8) (SIP) BYE

(9) (SIP) 200 OK

MSRP

Session

Connection/

Session

Establishment

Connection

Tear-down

XMS MSRP

Endpoint

Example 1. Script File Transfer

<dialogstart name="12345" target="conn:f18ae5d8-77c9892-13c4-50022-1ab2-2ba2849-1ab2"

type="application/moml+xml">

<fileobj append="false" contenttype="audio/amr" delete="true" dest="xmsrp://?

offerer=sip:[email protected];answerer=sip:[email protected];

file=/testing/mxm/recordings/RECORD_VMD4_1.amr" objid="transfer"

src="file:///testing/mxml/recordings/RECORD_VMD4_1.amr"/>

<send event="transfer.objectdone" namelist="transfer.objid transfer.duration"

target="source"/>

</transferobjdone>

</transferexit>

</transfer>

</dialogstart>

</msml>

Session Support

MSRP supports multiple sessions to be established over a single TCP connection. Although

MSRP allows one TCP connection per session, this method is not preferred when connecting

to the same MSRP endpoint.

MSRP provides a non-blocking algorithm that reduces inactivity when using a multi-session

per connection model. Additionally, MSRP supports multiple connections to the same

endpoint, with each TCP connection hosting multiple sessions. This is beneficial for solutions

that project high volumes of MSRP sessions. MSRP also supports single TCP connections

hosting multiple sessions to different endpoints.

Figure 2 illustrates single and multi-connection models with multiple MSRP sessions per TCP

connection.

Figure 2: Multi-session per TCP Connection Model

XMS

MSRP

Endpoint 1

MSRP Session1

MSRP Session2

MSRP Session3

MSRP Session4

MSRP Session5

TCP

connection

MSRP

Endpoint 2

TCP

connection

MSRP

Endpoint N

TCP

connection

MSRP Session1

MSRP Session2

MSRP Session3

MSRP Session4

MSRP Session5

MSRP SessionN

MSRP Session1

MSRP Session2

MSRP Session3

MSRP Session4

MSRP Session5

MSRP SessionN

MSRP Session1

MSRP Session2

MSRP Session3

MSRP Session4

MSRP Session5

TCP

connection

TCP

connection

TCP

connection

TCP

connection

TCP

connection

Limitations and Requirements

Some MSRP solutions only require PowerMedia XMS to support a Client implementation, in

which case PowerMedia XMS will only send content to peer endpoints. These solutions are

fully supported by PowerMedia XMS. Other solutions requiring PowerMedia XMS to interface

with intermediate relay entities, as defined in RFC 4976, are not supported by PowerMedia

XMS at the time of this document's publication.

MSRP solutions that require interaction with PowerMedia XMS using an interface other than

MSML or RESTful are not supported.

Customer Use Cases

There are examples of two specific customer configurations and use cases that MSRP

supports: Voice Mail Application and Delivery (VM AD) Solution and Next Generation

Emergency 911 (NGN E911) Service.

Voice Mail Application and Delivery Solution

The first use case MSRP supports is a Voice Mail Application and Delivery (VM AD) Solution.

PowerMedia XMS can function as an IP Multimedia Subsystem Media Resource Function

(MRF) entity that provides media processing services for a VM AD. VM playback and record

operations are controlled by a Voice Mail Application Server (VM AS) over a SIP/MSML

connection.

For this solution, PowerMedia XMS retrieves prompts and messages for playback from the

Voice Mail Storage (VM Storage) entity via HTTP as instructed through MSML control. When

a voicemail is recorded, the VM AS can instruct PowerMedia XMS to transfer the recorded

VM to the Voice Mail Delivery Server (VM DS) via a MSRP session. This results in

PowerMedia XMS constructing and sending a MSRP SIP INVITE to the VM DS.

The MSRP SIP INVITE is then sent to the Internet Protocol Multimedia Subsystem (IMS) for

subscriber Location Information inquiries and is eventually forwarded to the intended VM

DS. Upon receiving an answer from the VM DS, PowerMedia XMS establishes a TCP

connection with the VM DS and transfers the voicemail file via a MSRP session.

When the transfer has successfully completed, PowerMedia XMS will terminate the MSRP

session and delete the local file. Upon receiving the voicemail file, the VM DS forwards it to

the designated subscriber as specified in the "To" header of the SIP INVITE. The VM DS can

also send the recorded voice mail to a VM Storage server for future playback or editing by

subscribers. In the solution example shown in Figure 3, Internet Message Access Protocol

(IMAP) is used for this purpose.

Figure 3 illustrates a sample solution configuration with a Media Resource Broker (MRB)

providing load balancing and high availability to the pool of PowerMedia XMS MRFs.

Figure 3: Voice Mail Application and Delivery Solution Configuration

MSRP Session

HTTP

IMAP4

IMS

Core Network

HTTP

SIP

SIP/MSML

MRB

XMS

Storage

HTTP

IMAP4

MSRP Session

SIP/MSML Cntl

Status

Monitoring

File Transfer

File retrieve

store

File

retrieve

store

SIP

IMS Core

(S-CSCF, P-CSCF)

SIP/MSRP

XMS

Smartphone

Tablet

Laptop

VM AS: Voice Mail App Server

MRB: Media Resource Broker

VM Storage: Media Storage Server

VM DS: Voice Mail Delivery Server

S-CSCF: Serving Call Session

Control Function

P-CSCF: Proxy Call Session

Control Function

Note: Solutions can be supported by XMS that terminate MSRP sessions to endpoints

directly where the endpoints support MSRP and SIP protocols.

Figure 4 illustrates an example of a basic message flow through an IMS network providing a

Voice Mail Application and Delivery Service.

Figure 4: Voice Mail Application and Delivery Service Message Flow

MRF Sending Recorded VM via RCS File Transfer

VM AS MRF I-CSCF S-CSCF RMS

200 OK

[SDP]

INVITE tel:<VM#>;cause=xxx

[SDP m=audio/video]

HSS

ACK

MSML transactions for prompts, DTMF

events, recording, etc. (not shown)

RTP (AMR / AMR-WB)

...

Record media

BYE

200 OK

Send recorded file via RCS file

transfer procedures

INVITE tel URI

[SDP body with FT attributes]

[MIME body with transparent data] LIR

LIA

INVITE

Terminating iFCs

INVITE

183

200 OK

[SDP setup:passive]

ACK

BYE

200 OK

MSRP SEND

200 OK

TCP SYN

TCP SYN-ACK

TCP ACK

INFO

[MSML body with <transfer>]

[MIME body with transparent data]

200 OK

File sent in one or

more MSRP chunks

Next Generation Emergency 911 Service

The second use case MSRP supports is Next Generation Emergency 911 (NGN E911)

Service. Figure 5 illustrates the solution architecture for SMS text messaging to 9-1-1

emergency service. NGN E911 Service will mainly be used with the SMS capabilities of

native wireless operators that utilize existing generation and next generation (NG911) Public

Safety Answering Point (PSAP).

Figure 5: Next Generation Emergency 911 Service

ESI net

ESRP

PSAP

NENA i3

TCP/MSRP Sessions

SIP/MSRP

TCCSMSC SMPP

SIPwithMSRP

MSRP

Messaging

Engine

(XMS)

SIP/MSRP

TCP/MSRP Sessions

Restful

CMSP

SMSC Short Message Service Center

CMSP Commercial Mobile Service Provider

TCC Text Control Center

PSAP Public Safety Answering Point

ESRP Emergency Service Relay Proxy

RestFul Restful control Interface

3PCC

Model

PSAP

NENA i3

MSRP

Messaging

Engine

(XMS)

Restful

1PCC

Model

SIPwithMSRP

For this solution use case, PowerMedia XMS establishes TCP connections and receives E911

content from an Emergency Service Relay Proxy (ESRP). As shown above in Figure 5, the

solution may require support in either 1PCC or 3PCC signaling modes. When the feature is

fully implemented, PowerMedia XMS will be capable of supporting either call control model.

In 1PCC mode, the SIP signaling is sent directly to PowerMedia XMS. PowerMedia XMS

notifies the PSAP that an E911 call has been received and is ready for processing. All of the

signaling is handled by PowerMedia XMS with only notification events and message content

sent to the PSAP via the RESTful interface. In 3PCC mode, the PSAP is responsible for

managing the signaling and instructs PowerMedia XMS to establish a connection and MSRP

session for receiving an E911 message. When the message is delivered, notification is sent

to the PSAP for processing. The PSAP then instructs PowerMedia XMS to terminate the MSRP

session.

These are a few applications use case solutions that leverage MSRP technology in

PowerMedia XMS. Please contact our product management representatives to discuss how

this feature can apply to your solution.

Dialogic PowerMedia XMS Message Session Relay Protocol User guide

Dialogic PowerMedia XMS Message Session Relay Protocol User guide

Dialogic PowerMedia XMS Message Session Relay Protocol User guide

Related papers

Other documents