This document details basic procedures for system administrators managing, maintaining, configuring, and deploying OpenCloud’s R-IM-SSF Module — for protocol translation from INAP and CAP to SIP — with the Service Interaction SLEE (SIS).

Topics

This document includes the following topics:

  • About the R-IM-SSF — R-IM-SSF features and how it works

  • Installing the R-IM-SSF — prerequisites, installation procedures, licenses and activation, SIS instances, and the CDR resource adaptor entity

  • Configuring the R-IM-SSF — configuring general properties, subscription information, and user interface

  • R-IM-SSF Behaviour — how R-IM-SSF is triggered, makes contact, and deals with messages

  • R-IM-SSF Statistics —  parameter sets for statistics with R-IM-SSF

  • R-IM-SSF Alarms  — alarm types and descriptions

  • Using the R-IM-SSF — how to include the R-IM-SSF in a service composition, support more than one R-IM-SSF use in a service composition, and use rate limiting with the R-IM-SSF.

  • Changelog — the changelog for R-IM-SSF Protocol Translator version releases.

Intended Audience

This document is for system administrators (and anyone else responsible for) deploying, managing and maintaining the R-IM-SSF.

This document assumes a basic knowledge of core concepts about Rhino, SIS, JAIN SLEE and Java Management Extensions (JMX).

Scope

This document covers procedures for deploying and administering the OpenCloud R-IM-SSF Module.

This document does not focus on:

About the R-IM-SSF

The R-IM-SSF is a protocol translator that mediates between a CAP or INAP session with the SIS and a SIP session with an external SIP application server.

R-IM-SSF module features

The table below outlines the features of the R-IM-SSF.

Feature supported Description

INAP, CAP

Supports GSM CAP v1, v2, and v3; ETSI INAP CS1; Ericsson INAP CS1 (optional); and Ericsson INAP CS1+ (optional).

Tip A version of R-IM-SSF that supports other proprietary vendor variants of INAP is available on request. Please contact your OpenCloud sales representative for more information.

Call Control

Supports messages such as InitialDP, RequestReportBCSM, EventReport, Connect, Continue

Multiple Trigger Types

Supports triggering from the IN with InitialDP and from the SIP network with INVITE (network initiated call).

User Interaction

Supports playing announcements by mapping an INVITE from the SIP application server (with a special prefix or a play-url) to Tone or Message announcements provided by a node in the IN. The R-IM-SSF can use direct or assisting modes for user interaction.

Customisation options for SIP

There are a number of options that allow the makeup of the SIP signalling to the SIP application server. The operator can influence the headers includes in the SIP INVITE and the makeup of the SDP portion.

R-IM-SSF in action

The R-IM-SSF module provides support for protocol translation from INAP and CAP to SIP. The R-IM-SSF processes a call by acting as a B2BUA to the SIP-AS and by acting as an SCP to the SIS. The R-IM-SSF is invoked by a SIS composition, which may include other IN services to run. For example, in the following diagram we see that a service composition is using the R-IM-SSF to run SIP-based VPN services, in a composition with an IN-based OCS.

rimssf

Installing the R-IM-SSF

Below are prerequisites and instructions for installing R-IM-SSF, with details for entering licenses and activation, and details for the SIS and the CDR resource adaptor entity.

Before you install …​

Before installing the R-IM-SSF, make sure you have:

  • CDR RA — The R-IM-SSF uses the Metaswitch Rhino CDR RA to write a Call Detail Record per trigger. You must download and install the CDR pack, if you do not already have it, before you install the R-IM-SSF module. To install, uncompress the install archive in your <rhino-home>.

Note The R-IM-SSF requires CDR RA v 3.0.0.
  • SIS — The R-IM-SSF requires both a SIS for SIP instance and a SIS for IN instance. Before it can be installed, you need to create a SIS instance that supports these protocols. The R-IM-SSF install only needs the name of the SIS instances it should bind to.

Installing …​

To install R-IM-SSF:

1

Unzip the module archive from <sis-in-home> (after you have installed SIS IN and SIS SIP!)

$ cd sis/in/3.0.0.0
$ unzip rimssf-sis-module-3.0.0.0.zip
Archive:  rimssf-sis-module-3.0.0.0.zip
OpenCloud SIS Module R-IM-SSF
 creating: admin/
 creating: admin/lib/
 creating: admin/lib/extensions/
inflating: admin/lib/extensions/rimssf-client-3.0.0.0.jar
inflating: admin/remove-rimssf-3.0.0.script
 creating: modules/
 creating: modules/rimssf/
 creating: modules/rimssf/3.0.0/
 creating: modules/rimssf/3.0.0/install/
 creating: modules/rimssf/3.0.0/install/etc/
 creating: modules/rimssf/3.0.0/install/lib/
 creating: modules/rimssf/3.0.0/install/units/
inflating: modules/rimssf/3.0.0/install/CHANGELOG
inflating: modules/rimssf/3.0.0/install/etc/rimssf.properties
inflating: modules/rimssf/3.0.0/install/install-module.bat
inflating: modules/rimssf/3.0.0/install/lib/rimssf-installer_3.0.0.jar
inflating: modules/rimssf/3.0.0/install/units/nist-sdp-library-3.0.0.0.du.jar
inflating: modules/rimssf/3.0.0/install/units/rimssf-mng-ra-3.0.0.0.du.jar
inflating: modules/rimssf/3.0.0/install/units/rimssf-profile-3.0.0.0.du.jar
inflating: modules/rimssf/3.0.0/install/units/rimssf-translator-service-3.0.0.0.du.jar
inflating: modules/rimssf/3.0.0/install/units/state-machine-runtime-1.1.0.6.du.jar
inflating: modules/rimssf/3.0.0/install/install-module.sh

2

Change into the module install directory (modules/rimssf/3.0.0/install)

$ cd modules/rimssf/3.0.0/install

3

Run install-module.sh

$ ./install-module.sh
R-IM-SSF (version=3.0, release=00, build=20130129100554, revision=62832)
========================================================================

R-IM-SSF settings

RIM-SSF license file to install
-------------------------------
The R-IM-SSF 'right-to-use' license file.  A license may already be
installed, or you can install a license at a later point in time.  If no
license is present during install, however, the IM-SSF will need to be
activated via the console

RIM-SSF license file to install []:
...
Tip In general, you can accept the default answers during installation (press RETURN). See also details for entering licenses and activation, and information for the SIS instances and CDR resource adaptor entity.

Licenses and activation

The very first question during the R-IM-SSF installation asks you for a license file. If you have one, enter the path to it. If you don’t have a license file, or if you already have a valid license installed (perhaps as a part of your SIS license), then provide an empty response.

The installer will try to activate the R-IM-SSF at the end of the install process if it can. If it cannot, then it will print a message giving you some guidance.

Tip You can always install a license after the install process, and manually activate R-IM-SSF using the sis-console, with the rimssfactivate command.

SIS instances

The R-IM-SSF needs to bind to both an IN and SIP instance. Below is an example of R-IM-SSF installer questions (and responses) about SIS instances. In the example, the SIS deployment being installed has been configured to support SIP (instance name is sis-sip) and IN (instance name is sis-in).

SIS-SIP instance name
---------------------
The SIS-SIP instance the R-IM-SSF should use to connect to SIP AS's.  This
SIS instance must already be present in the SLEE.

SIS-SIP instance name: sis-sip

SIS-IN instance name
--------------------
The SIS-IN instance the R-IM-SSF should use to connect to the IN.  This SIS
instance must already be present in the SLEE.

SIS-IN instance name: sis-in
Tip
Finding SIS instances

If you cannot recall the names of the resource adaptor entities in your SIS install, use the listraentities command from the sis-console. In this install there are two entities: sis-in and sis-sip.

$ cd sis/in/3.0.0.0/admin
$ ./sis-console
Interactive Rhino Management Shell
Rhino management console, enter 'help' for a list of commands
[Rhino@localhost (#0)] listraentities
sis-in
sis-sip

CDR resource adaptor entity

The R-IM-SSF will create its own CDR resource adaptor entity from the CDR RA that comes with the Rhino install the SIS is installed with. By default, this resource adaptor entity is configured using properties appropriate for functional testing (it writes one CDR file per session).

R-IM-SSF CDR Resource Adaptor properties
----------------------------------------
Properties for the R-IM-SSF CDRs.  The default properties are suitable for
functional testing.  Please refer to the OpenCloud CDR Resource Adaptor
documentation for configuration options.

R-IM-SSF CDR Resource Adaptor properties [MaxCdrs=1,OutputDirectoryName=cdr,FilenamePattern=rimssf-cdr_%n_%t.log]:
Tip Please refer to the CDR RA documentation for configuration options you wish to use in a production setting.

Configuring the R-IM-SSF

The SIS administration interface is extended with a set of commands during the R-IM-SSF installation process.

If you use the sis-console help command to list the help categories, you will see three new categories:

[Rhino@localhost (#0)] help
Available command categories:

auditing              Manage Rhino's auditing subsystem
...
rimssf                R-IM-SSF management operations
rimssf-nic            R-IM-SSF network initiated call management operations
rimssf-svc            R-IM-SSF service mapping management operations
rimssf-ui             R-IM-SSF user interaction management operations
...
Enter help <category name | command name substring> for a list of available commands

The first is related to general configuration properties,
the second is related to calls initiated by the SIP network,
the third is related to external SIP application servers,
and the fourth is related to user-interaction configuration.

General R-IM-SSF Configuration

This command category supports general administration tasks such as activating the R-IM-SSF.

Tip Type help rimssf at the sis-console to see a list of commands related to general R-IM-SSF configuration.

Display the current configuration

rimssf-displaygeneralcfg

Command

rimssf-displaygeneralcfg
     Display general configuration of the R-IM-SSF

Example

To display the current general configuration:

[Rhino@localhost (#1)] rimssf-displaygeneralcfg
R-IM-SSF Configuration Data
CountryCode     : 64
IddPrefix       : 00
MscAddress      : null
NoAnswerTimeout : 30
RimssfDomain    : opencloud.co.nz
...

Activate/deactivate the R-IM-SSF

rimssf-activate

Command

rimssf-activate <true/false>
     Activate the R-IM-SSF (true=activate/false=deactivate)

Example

To activate the R-IM-SSF:

[Rhino@localhost (#1)] rimssf-activate true
The R-IM-SSF has been activated

Configure the International Dialing prefix and Country Code

rimssf-configureiddprefix

Command

rimssf-configureidprefix <idd-prefix>
     Configure the IddPrefix

Example

To configure the international dialing prefix:

[Rhino@localhost (#1)] rimssf-configureiddprefix 00
InternationalDiallingPrefix now set to: 00

rimssf-configurecountrycode

Command

rimssf-configurecountrycode <country-code>
     Configure the CountryCode

Example

To configure the country code:

[Rhino@localhost (#1)] rimssf-configurecountrycode 64
ConfigureCountryCode now set to: 64

Configure the Domain

rmssf-configuredomain

Command

rimssf-configuredomain <rimssf-domain>
     Configure the RimssfDomain

Example

To configure the domain of R-IM-SSF:

[Rhino@localhost (#1)] rimssf-configuredomain opencloud.com
RimssfDomain now set to: opencloud.com

Configure the SCF ID Address String

rmssf-configurescfidaddress

Command

rimssf-configurescfidaddress <scfid address>
     Configure the address string of ScfID used in EstablishTemporaryConnection
     messages sent by the R-IM-SSF

Example

To configure the SCF ID address string:

[Rhino@localhost (#1)] rimssf-configurescfidaddress 642347923873438
ScfIdAddress now set to: 642347923873438

Configure the MSC SCCP Address

rmssf-configuremscaddress

Note The MSC address only needs to be configured for scenarios where the SIP network initiates the call. The specified address must be described using the correct format.

Command

rimssf-configuremscaddress <msc address>
     Configure the SCCP address string of the MSC used for network-initiated calls.
     Use the value 'null' to remove an existing setting
     messages sent by the R-IM-SSF

Example

To configure the MSC address string:

[Rhino@localhost (#1)] rimssf-configuremscaddress type=c7,ri=gt,digits=34607012345,nature=national,national=true
MscAddress now set to: type=c7,ri=gt,digits=34607012345,nature=national,national=true

Configure the No Answer Timeout

rimssf-configurenoanswertimeout

Command

rimssf-configurenoanswertimeout <timeout>
     Configure the NoAnswer EDP timeout. The timeout units is seconds. Use 0 for no
     explicit timeout

Example

To configure the no answer timeout:

[Rhino@localhost (#1)] rimssf-configurenoanswertimeout 30
NoAnswer EDP timeout now set to: 30

Configure Connect behaviour

The R-IM-SSF can be configured to always send a Connect operation to route a normal call, or to send a Connect or Continue operation depending on whether or not the A or B party numbers have been changed by the SIP-AS.

rimssf-configurealwaysuseconnect

Command

configurealwaysuseconnect <always-use-connect?>
     Configure Always-Use-Connect setting. The argument must be a boolean value

Example

To configure the R-IM-SSF to always send a Connect:

[Rhino@localhost (#1)] rimssf-configurealwaysuseconnect true
Always-Use-Connect setting now set to: true

Configure Default Media Server Address

The default media server address is only used in the case where an announcement is to be played using an MRF instead of an SRF or IP and a media server address has not been configured in the relevant announcement mapping.

rimssf-configuredefaultmediaserveraddress

Command

rimssf-configuredefaultmediaserveraddress <uri>
     Configure the Default Media Server Address for user interaction performed using
     an MRF. The argument must be a SIP URI. Use the value 'null' to remove an
     existing setting

Example

To configure a default media server address of mrf.opencloud.com

[Rhino@localhost (#1)] rimssf-configuredefaultmediaserveraddress mrf.opencloud.com
DefaultMediaServerAddress setting now set to: mrf.opencloud.com

Configure Announcement Combined-Mode Field Format

The combined-mode field format specifier is used to indicate the field widths of the assisting SSP-IP routing address, correlation ID, and SCF-ID fields when the R-IM-SSF sends an Establish Temporary Connection operation using the combined mode of pre-ISUP '97.

Tip It is generally expected that the SCF-ID address (as configured above) will fit within the specified field width, and that the total width of all fields is not greater than the address string length supported by the protocol.

rimssf-configureannouncementcombinedmodefieldformat

Command

rimssf-configureannouncementcombinedmodefieldformat <aSSP-IP-address-width> <correlation-id-width> <scf-id-width>
     Configure the Announcement Combined-Mode Field Format. Use a single value 'null'
     to remove an existing setting

Example

To configure a combined-mode field format specifier for an assisting SSP-IP address width of 6 digits, an SCF ID address of 2 digits, and a correlation ID of 4 digits:

[Rhino@localhost (#1)] rimssf-configureannouncementcombinedmodefieldformat 6 2 4
Announcement Combined Mode Field Format setting now set to: 6:2:4

Configuring R-IM-SSF Network-Initiated Calls

The R-IM-SSF includes support for calls initiated by the SIP network.

Tip Type help rimssf-nic at the sis-console to see a list of commands related to network initiated calls.

Display the current configuration

rimssf-displayniccfg

Command

rimssf-displayniccfg
     Display network initiated call configuration of the R-IM-SSF

Example

To display the current general configuration

[Rhino@localhost (#1)] rimssf-displayniccfg
Network Initiated Call Configuration Data
IsIDDCCNormalisationEnabled : true

Configure number normalisation behaviour

rimssf-configureniciddccnormalisation

Command

rimssf-configureniciddccnormalisation <use-idd-cc-normalisation>
     Configure IDD/CC normalisation for network initiated calls

Example

To disable number normalisation, so that calling and called party addresses are passed from SIP to IN without the modification with respect to IDD and Country Code prefixes:

[Rhino@localhost (#1)] rimssf-configureniciddccnormalisation false
IDD/CC normalisation for network initiated calls is now disabled

Configuring R-IM-SSF Subscription Information

The R-IM-SSF includes configuration tables that dictate which SIP Application Server is triggered for an InitialDP.

Tip Type help rimssf-svc at the sis-console to see a list of commands related to subscription information.

Configuring SIP application servers

Below are descriptions and examples of commands for configuring SIP application servers.

rimssf-configuresipas

Command

rimssf-configuresipas <service-key> <sip-as address> <announcement-mode> <announcement-prefix> <resettimer-timeout>
     Configure SIP AS properties for a service-key. Announcement mode must be one of
     DIRECT, ASSISTING_SEPARATE, or ASSISTING_COMBINED

Example

To add the configuration for a SIP application server:

[Rhino@localhost (#1)] rimssf-configuresipas 23 192.168.62.102:5070 DIRECT 441123 90
Added SipAs configuration for service key 23

rimssf-displaysipascfg

Command

rimssf-displaysipascfg <service-key>
     Display SIP AS properties for a service-key

Example

To display the SIP AS configuration associated with a service-key:

[Rhino@localhost (#1)] rimssf-displaysipascfg 23
Mapping of serviceKey to SIP AS
AnnouncementMode          : DIRECT
AnnouncementPrefix        : 441123
ResetTimerTimeout         : 90
ServiceKey                : 23
SipAsAddress              : 192.168.62.102:5070

rimssf-displayallsipascfg

Command

rimssf-displayallsipascfg
     Display all SIP AS properties

Example

To display all SIP AS configurations:

[Rhino@localhost (#1)] rimssf-displayallsipascfg
ServiceKey   AnnouncementPrefix   AnnouncementMode   ResetTimerTimeout   SipAsAddress
-----------  -------------------  -----------------  ------------------  --------------------
         35               441135             DIRECT                  90   192.168.62.135:5070
         23               441123             DIRECT                  90   192.168.62.102:5070

rimssf-removesipas

Command

rimssf-removesipas <service-key>
     Remove SIP AS properties for a service-key
---

Example

To remove a SIP AS configuration

[Rhino@localhost (#1)] rimssf-removesipas 35
SIP AS configuration for service key 35 has been removed

Configuring INVITE properties

Below are descriptions and examples of the commands for configuring INVITE properties.

rimssf-configureinviteproperties

Command

rimssf-configureinviteproperties <service-key> <useSipUri> <transport> <accessParam> <o_AccessVal> <t_AccessVal> <hasCldPtyIDHeader> <hasSupportedHeader> <supportedHeader> <hasPChargingVectorHeader> <hasECF> <ecf> <hasCCF> <ccf> <hasPAccessNWInfoHeader> <defaultCGI> <expiresHeader> <hasSessionExpiresHeader> <sessionExpiresHeader> <hasMinSEHeader> <minSEHeader> <userAgentHeader>
     Configure INVITE properties for a service-key

Example

To add INVITE properties associated with ServiceKey of 23

[Rhino@localhost (#1)] rimssf-configureinviteproperties 23 true udp call orig term true true timer,replaces true false "" false "" true 12345 360 true 360 true 1212 rimssf
Added INVITE parameters for service key 23

rimssf-displayinviteproperties

Command

rimssf-displayinviteproperties <service-key>
     Display INVITE properties for a service-key

Example

To display INVITE properties for ServiceKey 23

[Rhino@localhost (#1)] rimssf-displayinviteproperties 23
Mapping of serviceKey to INVITE properties
AccessParameter             : call
AccessParameterOrigValue    : orig
AccessParameterTermValue    : term
CCF                         :
DefaultCgi                  : 12345
ECF                         :
ExpiresHeader               : 360
HasCCF                      : false
HasECF                      : false
HasMinSEHeader              : true
HasPAccessNetworkInfoHeader : true
HasPCalledPartyIDHeader     : true
HasPChargingVectorHeader    : true
HasSessionExpiresHeader     : true
HasSupportedHeader          : true
IsSipURIUsed                : true
MinSEHeader                 : 1212
ServiceKey                  : 23
SessionExpiresHeader        : 360
SupportedHeader             : timer,replaces
Transport                   : udp
UserAgentHeader             : rimssf

rimssf-displayallinviteproperties

Command

rimssf-displayallinviteproperties
     Display all INVITE properties

Example

To display all INVITE properties

[Rhino@localhost (#1)] rimssf-displayallinviteproperties
ServiceKey   AccessParameter   AccessParameterOrigValue   AccessParameterTermValue   CCF   DefaultCgi   ECF   ExpiresHeader   ...
-----------  ----------------  -------------------------  -------------------------  ----  -----------  ----  --------------  ...
         32              call                       orig                       term              12345                   360  ...
         23              call                       orig                       term              12345                   360  ...
2 rows

rimssf-removeinviteproperties

Command

rimssf-removeinviteproperties <service-key>
     Remove INVITE properties for a service-key

Example

To remove the INVITE properties associated with ServiceKey of 32

[Rhino@localhost (#1)] rimssf-removeinviteproperties 32
INVITE parameters for service key 32 has been removed

Configuring SDP portion properties

Below are descriptions and examples of commands for configuring SDP portion properties.

rimssf-configuresdpcfg

Command

rimssf-configuresdpcfg <service-key> <networkType> <addressType> <mediaType> <mediaProtocol> <mediaFormat> <fmtpAttribute> <rtpmapAttribute> <origPort>
     Configure SDP properties for a service-key

Example

To configure SDP properties associated with ServiceKey of 23

[Rhino@localhost (#1)] rimssf-configuresdpcfg 23 IN IPV4 audio RTP/AVP [0,8,18] 96\ 0-15,66,70 96\ telephone-event/8000 49170
Added SipAs configuration for service key 23

rimssf-displaysdpcfg

Command

rimssf-displaysdpcfg <service-key>
     Display SDP properties for a service-key

Example

To

[Rhino@localhost (#1)] rimssf-displaysdpcfg 23
Mapping of serviceKey to SDP properties
OrigPort           : 49170
SDPAddressType     : IPV4
SDPFmtpAttribute   : 96 0-15,66,70
SDPMediaFormat     : [0, 8, 18]
SDPMediaProtocol   : RTP/AVP
SDPMediaType       : audio
SDPNetworkType     : IN
SDPRtpmapAttribute : 96 telephone-event/8000
ServiceKey         : 23

rimssf-displayallsdpcfg

Command

rimssf-displayallsdpcfg
     Display all SDP properties

Example

To display all SDP configurations

[Rhino@localhost (#1)] rimssf-displayallsdpcfg
ServiceKey   OrigPort   SDPAddressType   SDPFmtpAttribute   SDPMediaFormat   SDPMediaProtocol   SDPMediaType   SDPNetworkType   ...
-----------  ---------  ---------------  -----------------  ---------------  -----------------  -------------  ---------------  ...
         32      49170             IPV4      96 0-15,66,70       [0, 8, 18]            RTP/AVP          audio               IN  ...
         35      49170             IPV4      96 0-15,66,70       [0, 8, 18]            RTP/AVP          audio               IN  ...
         23      49170             IPV4      96 0-15,66,70       [0, 8, 18]            RTP/AVP          audio               IN  ...
3 rows

rimssf-removesdpcfg

Command

rimssf-removesdpcfg <service-key>
     Remove SDP properties for a service-key

Example

To remove the SDP configuration associates with ServiceKey 35

[Rhino@localhost (#1)] rimssf-removesdpcfg 35
SDP configuration for service key 35 has been removed

Configuring R-IM-SSF User Interaction

The R-IM-SSF includes support for translating user-interaction requests by SIP application servers into equivalent requests to network elements in the IN (such as an IVR). For example, if a SIP application requests that a particular announcement should be played with a play-url in an INVITE, then the R-IM-SSF will map this to a PlayAnnouncement message.

Tip Type help rimssf-ui at the sis-console to see a list of commands related to subscription information.

Configuring prefix announcement mappings

Below are descriptions and examples of the commands for configuring prefix announcement mappings.

rimssf-addprefixmessageannouncementmapping

Command

rimssf-addprefixmessageannouncementmapping <prefix> <id> <assistingSspIpRoutingAddress> <resourceAddress>
     Add prefix -> message announcement mapping

Example

To add a message announcement mapped to prefix 351123700:

[Rhino@localhost (#1)] rimssf-addprefixmessageannouncementmapping 351123700 15 123456 12345678
Added Message announcement mapping for prefix 351123700

rimssf-addprefixtoneannouncementmapping

Command

rimssf-addprefixtoneannouncementmapping <prefix> <id> <assistingSspIpRoutingAddress> <resourceAddress>
     Add prefix -> tone announcement mapping

Example

To add a tone announcement mapped to prefix 351123456:

[Rhino@localhost (#1)] rimssf-addprefixtoneannouncementmapping 351123456 12 123456 12345678
Added Tone announcement mapping for prefix 351123456

rimssf-displayprefixannouncementmapping

Command

rimssf-displayprefixannouncementmapping <prefix>
     Display the announcement mapping for a prefix

Example

To display announcement configuration associated with prefix 351123456:

[Rhino@localhost (#1)] rimssf-displayprefixannouncementmapping 351123456
Mapping of prefix to announcement properties
AnnouncementID               : 12
AssistingSSPIPRoutingAddress : 123456
MessageType                  : TONE_ANNOUNCEMENT
Prefix                       : 351123456
ResourceAddress              : 12345678

rimssf-displayallprefixannouncementmappings

Command

rimssf-displayallprefixannouncementmappings
     Display all prefix -> announcement mappings

Example

To display all prefix → announcement mappings:

[Rhino@localhost (#1)] rimssf-displayallprefixannouncementmappings
Prefix      AnnouncementID   AssistingSSPIPRoutingAddress   MessageType            ResourceAddress
----------  ---------------  -----------------------------  ---------------------  ----------------
 351123456               12                         123456      TONE_ANNOUNCEMENT          12345678
 351123700               15                         123456   MESSAGE_ANNOUNCEMENT          12345678

rimssf-removeprefixannouncementmapping

Command

rimssf-removeprefixannouncementmapping <prefix>
     Remove a prefix -> announcement mapping

Example

To remove an announcement mapping for prefix 351123456:

[Rhino@localhost (#1)] rimssf-removeprefixannouncementmapping 351123456
Announcement mapping for prefix 351123700 has been removed

Configuring play-URL announcement mappings

Below are descriptions and examples of commands for configuring play-URL announcement mappings.

rimssf-addplayurlmessageannouncementmapping

Command

rimssf-addplayurlmessageannouncementmapping <playurl> <id> <assistingSspIpRoutingAddress> <resourceAddress> <mrfAddress>
     Add playurl -> message announcement mapping. The value of resourceAddress or
     mrfAddress may be 'null' if no specific value is to be configured

Example

To add a message announcement, played using an IN resource, mapped to a play-url /provisioned/19:

[Rhino@localhost (#1)] rimssf-addplayurlmessageannouncementmapping /provisioned/19 19 123456 12345678 null
Added Message announcement mapping for play url /provisioned/19

rimssf-addplayurltoneannouncementmapping

Command

rimssf-addplayurltoneannouncementmapping <playurl> <id> <assistingSspIpRoutingAddress> <resourceAddress>
     Add playurl -> tone announcement mapping

Example

To add a tone announcement, played using a SIP resource, mapped to a play-url /provisioned/12:

[Rhino@localhost (#1)] rimssf-addplayurltoneannouncementmapping /provisioned/12 12 123456 null 12345678@mrf.opencloud.com
Added Tone announcement mapping for play url /provisioned/12

rimssf-displayplayurlannouncementmapping

Command

rimssf-displayplayurlannouncementmapping <playurl>
     Display the announcement mapping for a play url

Example

To display the play-url → announcement mapping for /provisioned/12:

[Rhino@localhost (#1)] rimssf-displayplayurlannouncementmapping /provisioned/12
Mapping of PlayUrl to announcement properties
AnnouncementID               : 12
AssistingSSPIPRoutingAddress : 123456
MediaServerAddress           : 12345678@mrf.opencloud.com
MessageType                  : TONE_ANNOUNCEMENT
ResourceAddress              : null
Url                          : /provisioned/12

rimssf-displayallplayurlannouncementmappings

Command

rimssf-displayallplayurlannouncementmappings
     Display all play url -> announcement mappings

Example

To display all play-url → announcement mappings:

[Rhino@localhost (#1)] rimssf-displayallplayurlannouncementmappings
Url               AnnouncementID   AssistingSSPIPRoutingAddress   MediaServerAddress            MessageType            ResourceAddress
----------------  ---------------  -----------------------------  ---------------------------  ---------------------  ----------------
 /provisioned/12               12                         123456   12345678@mrf.opencloud.com   TONE_ANNOUNCEMENT
 /provisioned/15               15                         123456                                TONE_ANNOUNCEMENT          12345678
 /provisioned/19               19                         123456                                MESSAGE_ANNOUNCEMENT       12345678
3 rows

rimssf-removeplayurlannouncementmapping

Command

rimssf-removeplayurlannouncementmapping <playurl>
     Remove a playurl -> announcement mapping

Example

To remove an announcement mapping for play-url /provisioned/15:

[Rhino@localhost (#1)] rimssf-removeplayurlannouncementmapping /provisioned/15
Announcement mapping for play url /provisioned/15 has been removed

Configuring media XML announcement mappings

A media XML announcement mapping is used if an incoming INVITE request is not recognised as another type of announcement INVITE but contains a Content-Type header identifying the message content as application/mediaservercontrol\+xml. Media XML announcement mappings are keyed on the ServiceKey of the InitialDP that triggered the call. For SIP network initiated calls a ServiceKey value of 0 is used to look up the announcement mapping.

Below are descriptions and examples of commands for configuring media XML announcement mappings.

rimssf-addmediaxmlannouncementmapping

Command

rimssf-addmediaxmlannouncementmapping <service-key> <assistingSspIpRoutingAddress> <mrfAddress>
     Add media-xml announcement mapping for a service key. The value of mrfAddress
     may be 'null' if no specific value is to be configured

Example

To add a media XML announcement mapped to service key 100:

[Rhino@localhost (#1)] rimssf-addmediaxmlannouncementmapping 100 123456 mrf.opencloud.com
Added Media XML announcement mapping for service key 100

rimssf-displaymediaxmlannouncementmapping

Command

rimssf-displaymediaxmlannouncementmapping <service-key>
     Display the media-xml announcement mapping for a service key

Example

To display announcement configuration associated with service key 100:

[Rhino@localhost (#1)] rimssf-displaymediaxmlannouncementmapping 100
Mapping of service key to media-xml announcement properties
AssistingSSPIPRoutingAddress : 123456
MediaServerAddress           : mrf.opencloud.com
ServiceKey                   : 100

rimssf-displayallmediaxmlannouncementmappings

Command

rimssf-displayallmediaxmlannouncementmappings
     Display all media-xml announcement mappings

Example

To display all service key → media XML announcement mappings:

[Rhino@localhost (#1)] rimssf-displayallmediaxmlannouncementmappings
ServiceKey   AssistingSSPIPRoutingAddress   MediaServerAddress
-----------  -----------------------------  -------------------
        100                         123456    mrf.opencloud.com
         70                         123456

rimssf-removemediaxmlannouncementmapping

Command

rimssf-removemediaxmlannouncementmapping <service-key>
     Remove a media-xml announcement mapping for a service key

Example

To remove an announcement mapping for service key 100:

[Rhino@localhost (#1)] rimssf-removemediaxmlannouncementmapping 100
Media XML mapping for service key 100 has been removed

R-IM-SSF Behaviour

These sections describe the behaviour of the R-IM-SSF:

  • Initial Triggering via the IN — how the R-IM-SSF is triggered by the IN and how it makes initial contact with a SIP-AS.

  • Initial Triggering via SIP — how the R-IM-SSF can be triggered by the SIP network to create a new network initiated call in the IN, and how the R-IM-SSF makes initial contact with an MSC

  • IN Message Translation — how the R-IM-SSF deals with incoming IN messages after call initiation

  • SIP Message Translation — how the R-IM-SSF deals with incoming SIP messages after call initiation

  • Example Call Flows — example call flows for various scenarios.

Initial Triggering via the IN

The R-IM-SSF is triggered in the IN by the InitialDP initial request event.

Triggering the R-IM-SSF

  1. The R-IM-SSF uses the ServiceKey of the InitialDP event to find the address of the external SIP application server.

  2. The R-IM-SSF builds an INVITE (and the SDP portion) and invokes the SIP application server.

Tip The R-IM-SSF requires that the InitialDP has at least a ServiceKey, a CallingPartyNumber, and a CalledPartyNumber (or CalledPartyBCDNumber for CAP O-BCSM triggers).

The R-IM-SSF manages a number of profile tables that it uses to trigger a SIP application. The rimssf-configuration-profile-table contains global configuration information. This profile table typically contains only one profile, as the R-IM-SSF uses the same configuration information for all calls.

The R-IM-SSF uses records from three other configuration profile tables to determinate how to build the outgoing INVITE and which SIP application server to send it to:

  • rimssf-service-configuration-profile-table — external SIP application service configuration

  • rimssf-invite-builder-profile-table — information to populate the headers in the INVITE message

  • rimssf-sdp-builder-profile-table) — information to build the SDP portion of the INVITE.

The records in these three tables are indexed by service key. The ServiceKey from the incoming InitialDP is used to find the appropriate configuration information for the call.

Warning

If:

  • the InitialDP does not contain the minimum required fields …​ or …​

  • there isn’t a record corresponding to the ServiceKey in one or more of the configuration profile tables

…​then the R-IM-SSF does not attempt to trigger a SIP application server and allows the call to proceed (by responding to the switch with a Continue in a TC-End).

Finding the SIP-AS

The R-IM-SSF searches for a record in the rimssf-service-configuration-profile-table that corresponds to the ServiceKey from the InitialDP. The R-IM-SSF uses the information in the record to determine the address of the external SIP application server.

Field Description
 ServiceKey

The ServiceKey value from the InitialDP.

 SipAsAddress

The SIP application server address (in the form address:port).

 AnnouncementPrefix

A prefix to check for in the INVITE received from the SIP-AS that may indicate user interaction is required.

 AnnouncementMode

Indicates whether user interaction mode is direct, assisting using separate EstablishTemporaryConnection operation fields, or assisting combining parameters into a single ETC operation field.

 ResetTimerTimeout

Timeout used for ResetTimer operations. If 0 then ResetTimer operations are not sent by the R-IM-SSF during user interaction.

Tip See [2 Configuring R-IM-SSF Subscription Information] for the sis-console commands to use to manage the rimssf-service-configuration-profile-table.

Building the INVITE

The R-IM-SSF searches for a record in the rimssf-invite-builder-profile-table that corresponds to the ServiceKey from the InitialDP. The R-IM-SSF uses the information in the record to build the INVITE message it sends to the external SIP application server.

Field Description
 ServiceKey

The ServiceKey value from the InitialDP

 IsSipURIUsed

Whether a SIP URI or Tel URL should be used to create initial INVITE

 Transport

The SIP Transport used towards the service: udp, tcp, or udp/tcp

 AccessParameter

The name of a parameter of the Route that should be used to distinguish between originating and terminating triggers

 AccessParameterOrigValue

The value of the AccessParameter parameter that indicates an originating trigger

 AccessParameterTermValue

The value of the AccessParameter parameter that indicates a terminating trigger

 HasPAccessNetworkInfoHeader

If the initial INVITE should include the optional P-Access-Network-Info header

 DefaultCgi

The default CGI parameter for the P-Access-Network-Info header; used when LocationNumber is not present on the InitialDP received

 HasPChargingVectorHeader

If the initial INVITE should include a P-Charging-Function-Addresses header

 HasCCF

If the initial INVITE includes the optional CCF parameter in the P-Charging-Function-Addresses header

 CCF

CCF parameter for P-Charging-Function-Addresses header

 HasCCF

If the initial INVITE includes the optional ECF parameter in the P-Charging-Function-Addresses header

 ECF

ECF parameter for P-Charging-Function-Addresses header

 ExpiresHeader

The Expires header value used for the initial INVITE

 HasMinSEHeader

If the initial INVITE should include an optional Min-SE header

 MinSEHeader

Min-SE header value

 HasPCalledPartyIDHeader

If the initial INVITE should include an optional P-Called-Party-ID header

 HasSessionExpiresHeader

If the initial INVITE should include an optional Session-Expires header

 SessionExpiresHeader

Session-Expires header value

 HasSupportedHeader

If the initial INVITE includes optional Supported header

 SupportedHeader

Values to include in the Supported header

 UserAgentHeader

User-Agent header value for initial INVITE

Example configuration …​ …​results in:
 ServiceKey
 23
 IsSipURIUsed
 true
 Transport
 udp
 AccessParameter
 call
 AccessParameterOrigValue
 orig
 AccessParameterTermValue
 term
 HasPAccessNetworkInfoHeader
 true
 DefaultCgi
 111111111
 HasPChargingVectorHeader
 true
 HasCCF
 false
 CCF

               
 HasCCF
 false
 ECF

               
 ExpiresHeader
 360
 HasMinSEHeader
 true
 MinSEHeader
 2120
 HasPCalledPartyIDHeader
 false
 HasSessionExpiresHeader
 true
 SessionExpiresHeader
 360
 HasSupportedHeader
 true
 SupportedHeader
 timer,replaces
 UserAgentHeader
 rimssf-useragent-inv-builder
INVITE sip:123456789@opencloud.co.nz SIP/2.0
From: <sip:+351987654321@opencloud.co.nz>;tag=g5qB7w
To: <sip:123456789@opencloud.co.nz>
Call-ID: n1O3nxW0T6iW5P5P3-TmjQ
CSeq: 63062 INVITE
Max-Forwards: 70
Via: SIP/2.0/UDP 192.168.62.102:5060;oc-node=101;rport;branch=z9hG4bKFAdZ7Kn7vR364EMwd73ABA;ext
Via: SIP/2.0/UDP 192.168.62.102:5060;oc-node=101;rport;branch=z9hG4bKTvm5BnH1zYrsbC0ZDLpWdw
Contact: <sip:Ai-cCypiu+hkF35L3H~FqyAw@192.168.62.102:5060;oc-node=101;transport=udp>
Route: <sip:192.168.62.102:5070;lr;transport=udp;call=orig>
Route: <sip:Ai-cCypiu+hkF35L3H~FqyAw@192.168.62.102:5060;oc-node=101;lr;transport=udp>
P-Asserted-Identity: <tel:+351987654321>, <sip:+351987654321@opencloud.co.nz>
Supported: timer, replaces, 100rel
Allow: INVITE, BYE, CANCEL, ACK, PRACK, UPDATE
P-Charging-Vector: icid-value=1283143839977;orig-ioi=opencloud.co.nz
P-Access-Network-Info: 3GPP-GERAN;cgi-3gpp=111111111
Expires: 360
Session-Expires: 360
Min-SE: 2120
User-Agent: rimssf-useragent-inv-builder
...
Tip See Configuring R-IM-SSF Subscription Information for the sis-console commands to use to manage the rimssf-invite-builder-profile-table.

Building the SDP portion

The R-IM-SSF searches for a record in the rimssf-sdp-builder-profile-table that corresponds to the ServiceKey from the InitialDP. The R-IM-SSF uses the information in the record to build the SDP portion of the INVITE message it sends to the external SIP application server.

Field Description
 ServiceKey

The ServiceKey value from the InitialDP

 SDPNetworkType

The SDP network type

 SDPAddressType

The SDP address type

 SDPMediaType

The SDP media type

 SDPMediaFormat

The SDP media format

 SDPMediaProtocol

The SDP media protocol

 SDPFmtpAttribute

The SDP Fmtp attribute


          

SDPRtpmapAttribute

 The `SDP` `Rtpmap` attribute

OrigPort

Example configuration…​ …​results in
 ServiceKey
 23
 SDPNetworkType
 IN
 SDPAddressType
 IPV4
 SDPMediaType
 audio
 SDPMediaFormat
 [0, 8, 18]
 SDPMediaProtocol
 RTP/AVP
 SDPFmtpAttribute
 96 0-15,66,70
 SDPRtpmapAttribute
 96 telephone-event/8000
 OrigPort
 49170
INVITE sip:123456789@opencloud.co.nz SIP/2.0
From: <sip:+351987654321@opencloud.co.nz>;tag=g5qB7w
...
User-Agent: rimssf-useragent-inv-builder
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 182

v=0
o=+351987654321 3 3 IN IP4 192.168.62.102
s=oc-node=101
c=IN IPV4 192.168.62.102
t=0 0
m=audio 49170 RTP/AVP 0 8 18
a=fmtp:96 0-15,66,70
a=rtpmap:96 telephone-event/8000
Tip See Configuring R-IM-SSF Subscription Information for the sis-console commands to use to manage the rimssf-sdp-builder-profile-table.

Initial Triggering via SIP (Network Initiated Call)

The R-IM-SSF may also be triggered by an incoming INVITE request from the SIP network when a SIP-AS wishes to create a network initiated call in the IN.

Note In order to establish a network initiated call, an IN protocol that supports such calls is required. Currently the only protocol supporting these types of calls that is also supported by the R-IM-SSF is Ericsson INAP CS1+.

Identifying a network initiated call

A SIP-AS uses the principles specified in RFC 4579 s5.4 (Creating a Conference Using Ad-Hoc SIP Methods) to create a new network initiated call attempt in the IN. In order to identify an INVITE request that represents a new network initiated call attempt, the INVITE from the SIP-AS must contain a Request-URI that:

  • is a SIP URI

  • specifies a user of conference-factory

  • contains the URI parameter oc-rimssf=conference.

The To header in the initial INVITE should identify the phone number of the first call party.

When the first call party answers the call, the R-IM-SSF will respond to the INVITE with a 200 OK. The Contact URI contained in this 200 OK identifies the call to the SIP-AS and must be used by the SIP-AS as the Request-URI or topmost Route header (when received by the R-IM-SSF) in subsequent INVITE requests that add further participants to the call. The To header in subsequent INVITE requests should again identify the phone number of the party to be added to the call.

Triggering the R-IM-SSF

The R-IM-SSF can be triggered in the SIS for a SIP network initiated call by checking for the presence of the required conference URI. For example, the following condition could be used in a SIS trigger to select a composition that invokes the R-IM-SSF for such a call:

<on-condition>
  <and>
    <equal a="${uri.user}" b="conference-factory"/>
    <equal a="${uri.param.oc-rimssf}" b="conference"/>
  </and>
</on-condition>
Tip R-IM-SSF install packages that include support for IN protocols that support network initiated calls include an example SIS trigger and composition that can be used to invoke the R-IM-SSF for a SIP network initiated call.

Find the MSC

The R-IM-SSF general configuration includes a setting for the default MSC address (as an SCCP address) to use for network initiated calls. The R-IM-SSF provides the capability to override this default address on a per call basis using a SIS interceptor.

Once the interceptor completes (if relevant), the R-IM-SSF uses the final determined SCCP address as the destination address for a new outgoing IN dialog. The R-IM-SSF then builds the InitiateCallAttempt to send on this dialog.

Warning The R-IM-SSF rejects the call with a 500 Internal Server Error response if a valid MSC address cannot be determined. This can happen if no default MSC address is configured and an interceptor does not provide a suitable value.

Build the InitiateCallAttempt

The R-IM-SSF uses information from the incoming INVITE to populate the fields of the InitiateCallAttempt request it sends to the MSC.

Field Source Description
  DestinationRoutingAddress
  Request-URI

The Request-URI must contain a numerical address. This address is used to determine the destination address.

  CallingPartyNumber
  From

The From header must also contain a numerical address. This address is used to determine the calling party number.

  LegToBeCreated

n/a

The first leg created has a leg id of 1. This value is incremented by one for each subsequent leg.

When converting a SIP URI address to an IN data value, the final address will have a format based on the international dialling prefix and country code settings provisioned in the general configuration.

Before sending the InitiateCallAttempt message, the R-IM-SSF invokes a SIS interceptor allowing additional fields to be populated in the message.

Once the InitiateCallAttempt has been sent to the MSC and routing of the new call begins, the R-IM-SSF sends a 183 Session Progress provisional response to the INVITE back to the SIP-AS.

Example R-IM-SSF configuration …​ Example INVITE …​ …​ results in
 IddPrefix
 00
 CountryCode
 64
INVITE sip:conference-factory@rimssf.opencloud.com;oc-rimssf=conference SIP/2.0
From: <tel:+64219999999>;tag=MEuBTA
To: <tel:+64211234567>
Call-ID: XuCsVFJjoGKZF7oECrJDtg
CSeq: 0 INVITE
Max-Forwards: 70
...
InitiateCallAttempt[
  destinationRoutingAddress
    {
      calledPartyNumber
        nature NATIONAL
        routingToInternalNetworkNumber ALLOWED
        numberingPlan ISDN
        address "211234567"
    }
  callingPartyNumber
    nature NATIONAL
    numberIncomplete false
    numberingPlan ISDN
    presentation ALLOWED
    screening NETWORK_PROVIDED
    address "219999999"
  legToBeCreated
    sendingSideID
      encodedValue CALLING_PARTY
]

Typical call flow

For a call initiated by the SIP network, this is a typical call flow.

  1. An INVITE from SIP-AS initiates the call.

  2. R-IM-SSF creates the new call in the IN network,using InitiateCallAttempt to contact the A-party.

  3. The A-party answers; R-IM-SSF informs SIP-AS.

  4. SIP-AS sends a second INVITE for the B-party.

  5. R-IM-SSF routes the call to the B-party.

  6. The B-party answers; R-IM-SSF informs SIP-AS.

Once the A-party has answered the call and the SIP-AS has been notified, the call progresses in the same way as if the A-party had initiated the call in the IN and the R-IM-SSF had been triggered for that call by an InitialDP.

Interceptors for network-initiated Calls

The SIS does not automatically provide support for interceptors or other service interaction behaviour on dialogs created by SLEE applications. To solve this problem and allow interceptors to modify the messages it sends for network-initiated calls, the R-IM-SSF manually invokes interceptors for relevant outgoing messages. The R-IM-SSF supports interceptors that complete both synchronously and asynchronously, and will correctly maintain message ordering for interceptors that do complete asynchronously.

Below is a description of the interceptors the R-IM-SSF will try to invoke. All interceptors are given an OperationInvokeEvent[] as input, and the R-IM-SSF expects the interceptor output to be of the same type. An interceptor may modify the input argument as required, within any noted restrictions; however an interceptor must not include null elements in the output array, and all OperationInvokeEvent array elements must at least declare the operation to be invoked. The dialog, invokeId, and linkedId attributes of OperationInvokeEvents passed to and returned from an interceptor are unused and ignored by the R-IM-SSF.

Warning A callprocessing error will occur if an interceptor returns invalid output, leading to call termination.
Interceptor Ref Name Interceptor Input
 rimssf.nic

Input object: OperationInvokeEvent[] containing one element: the InitiateCallAttempt operation request which begins a new network-initiated call attempt. The interceptor may modify the operation argument, or return a new OperationInvokeEvent[] array with additional operations to send, provided that an InitiateCallAttempt operation request remains as the first array element.

Input user variables:

Variable name Type Description
 user.rimssf.nic.destination-sccp-address

The configured default MSC SCCP address. Will be null if no default is configured. May be changed (or set) by the interceptor if required.

  user.rimssf.nic.application-context

The application context that will be used to create the outgoing IN dialog. This value is provided for information purposes only. Changes to the value of this variable will be ignored by the R-IM-SSF.

  user.rimssf.nic.invite

The incoming INVITE request that caused the new call attempt. This value is provided for information purposes only. An interceptor should not attempt to change the content of the INVITE message or interact with the SIP dialog the message was sent on.

 rimssf.ica

Input object: OperationInvokeEvent[] containing one element: an InitiateCallAttempt operation request creating a new call leg in a call already in progress. The interceptor may modify the operation argument, or return a new OperationInvokeEvent[] array with additional operations to send, provided that an InitiateCallAttempt operation request remains as the first array element.

Warning In the Ericsson INAP CS1+ protocol, the second leg created in a network-initiated call is established using a Connect operation rather than an InitiateCallAttempt operation.

Input user variables:

Variable name Type Description
 user.rimssf.leg.invite

The incoming INVITE request that caused the new leg to be created. This value is provided for information purposes only. An interceptor should not attempt to change the content of the INVITE message or interact with the SIP dialog the message was sent on.

 rimssf.con

Input object: OperationInvokeEvent[] containing one element: a Connect operation request. A Connect request is used in Ericsson INAP CS1+ to create the second call leg in a network-initiated call.

Input user variables:

Variable name Type Description
 user.rimssf.leg.invite

The incoming INVITE request that caused the new leg to be created. This value is provided for information purposes only. An interceptor should not attempt to change the content of the INVITE message or interact with the SIP dialog the message was sent on.

 rimssf.rrbe

Input object: OperationInvokeEvent[] containing one element: a RequestRequestBCSMEvent operation request arming appropriate EDPs on a new call leg.

Input user variables: none

 rimssf.etc

Input object: OperationInvokeEvent[] containing one or two elements: an EstablishTemporaryConnection operation request and an optional ResetTimer operation request (only if the reset timer timeout in the service configuration is greater than zero).

Input user variables: none

 rimssf.pa

Input object: OperationInvokeEvent[] containing two or three elements: a ConnectToResource operation request, a PlayAnnouncement operation request, and an optional ResetTimer operation request (only if the reset timer timeout in the service configuration is greater than zero).

Input user variables: none

 rimssf.dl

Input object: OperationInvokeEvent[] containing one element: a ReleaseCallPartyConnection operation request to disconnect a call leg.

Input user variables: none

 rimssf.rc

Input object: OperationInvokeEvent[] containing one element: a ReleaseCall operation request terminating the call.

Input user variables: none

IN Message Translation

Here’s what the R-IM-SSF does when it gets messages from the IN:

IN message Action
 InitialDP

Initial trigger for an IN-initiated call. See [1 Initial Triggering via the IN] for a detailed description of how the R-IM-SSF uses the information contained in the InitialDP and provisioned state to contact a SIP-AS.

 EventReportBCSM

An EventReportBCSM event causes the R-IM-SSF to send a message on the SIP dialog corresponding to the same call leg for which the event was reported. The actual SIP message sent depends on the reported event:

event message

abandon

CANCEL request for the INVITE, to the SIP-AS Any incoming SIP dialogs representing call legs (rather than user interaction requests) will also be terminated with a 487 Request Terminated final response

alerting

180 Alerting provisional response

busy

486 Busy Here final response

no answer

408 Request Timeout final response

not reachable

408 Request Timeout final response

route select failure

404 Not Found final response

answer

200 OK response

disconnect

BYE request

If the event report corresponds to a leg terminating event: then once the SIP dialog has been confirmed terminated in the R-IM-SSF by receipt of an ACK (for a final response) or 200 OK (for a BYE), then the R-IM-SSF will release the leg or call (as described when a CANCEL or BYE is received) if the call has not already been released.

 AssistRequestInstructions

Indicates the initiation of an SRF assisting dialog. A 200 OK response is sent by the R-IM-SSF on the SIP dialog that initiated the user interaction session.

 SpecializedResourceReport

Indicates the end of an announcement. A DisconnectForwardConnection request is sent by the R-IM-SSF on the IN dialog; and, if relevant, the SRF assisting dialog will be closed. A BYE request is also sent by the R-IM-SSF on the SIP dialog that initiated the user interaction.

 HoldResult +
ReconnectResult

The call leg was successfully held or resumed. A 200 OK response is sent by the R-IM-SSF on the corresponding SIP dialog.

 ReleaseCallPartyConnectionResult

The call leg was successfully disconnected. The corresponding SIP dialog has already terminated at this point, so no further action is necessary.

 OpenRefuse

This event only occurs for SIP network initiated calls in the case where the IN dialog created by the R-IM-SSF is not accepted by the MSC. A 503 Service Unavailable final response is sent on the SIP dialog that initiated the call.

 UserAbort +
ProviderAbort
  • When received for an IN-initiated call, depending on the current call state, a CANCEL or BYE is sent by the R-IM-SSF on the outgoing SIP dialog to the SIP-AS, and a 500 Internal Server Error final response or BYE is sent on any incoming SIP dialog from the SIP-AS.

  • When received for a SIP network initiated call, depending on the current call state, a 503 Service Unavailable final response or BYE request is sent by the R-IM-SSF on each incoming SIP dialog from the SIP-AS.

  • When received for an SRF assisting dialog, a BYE request is sent in the R-IM-SSF to the SIP-AS on the SIP dialog that initiated the user interaction session.

 OperationError
  • If a user error response relating to a ConnectToResource operation, a BYE request is sent by the R-IM-SSF on the SIP dialog that initiated the user interaction session. If user interaction was being performed using an assisting dialog, the assisting dialog is aborted and a DisconnectForwardConnection request is sent by the R-IM-SSF on the main IN dialog.

  • If a user error response indicating a PlayAnnouncement request has been cancelled, a DisconnectForwardConnection request is sent by the R-IM-SSF on the IN dialog; and, if relevant, the SRF assisting dialog will be closed. Announcement cancellation occurs because the SIP-AS terminated the SIP dialog initiating the user interaction session before the announcement had completed, so no further action is needed on this dialog.

  • If an error response relating to an InitiateCallAttempt operation, establishment of the new call leg failed and a 503 Service Unavailable final response is sent by the R-IM-SSF on the corresponding SIP dialog.

  • If an error response relating to a HoldCallPartyConnection or Reconnect operation, the a 500 Internal Server Error final response to the re-INVITE is sent by the R-IM-SSF on the corresponding SIP dialog.

  • If any other case, the R-IM-SSF aborts the call, and acts the same as if it received an abort message.

SIP Message Translation

Here’s what the R-IM-SSF does when it gets messages from the SIP network:

SIP message Action

initial

INVITE

New call leg

An incoming INVITE that is not creating a new network-initiated call and is not related to user interaction must identify the session it relates to in at least one of the following ways:

  • by including the oc-rimssf-session parameter in the top-most Route header. The return Route added by the R-IM-SSF in an INVITE sent to a SIP-AS already includes this parameter to identify the session; so a SIP-AS that simply forwards the INVITE doesn’t need to do anything more.

  • by including the oc-rimssf-session parameter in the Request-URI. The Contact header contained in the 200 OK response to an INVITE creating a new network-initiated call includes this parameter; so a SIP-AS that uses this Contact header as the Request-URI when adding further legs to the call doesn’t need to do anything more.

  • by using the session-id field of the Origin SDP parameter. The SDP included in the INVITE sent to a SIP-AS already contains this value; so a SIP-AS that uses the same SDP in the INVITE forwarded back to the R-IM-SSF doesn’t need to do anything more.

The R-IM-SSF attempts to determine the session ID by applying the rules above in the order given. The R-IM-SSF stops evaluating the rules once a session ID is found. If a session ID is not found, or a session ID is found that is not recognised, then the R-IM-SSF responds to the INVITE with a 503 Service Unavailable final response.

Assuming an active session is found, the incoming INVITE creates a new call leg in the corresponding IN call. If the new call leg represents the B party, the R-IM-SSF sends RequestReportBCSMEvent and Connect operation requests to arm the appropriate EDPs in the MSC, and route the call to the destination address. For any other call leg, the R-IM-SSF sends an InitiateCallAttempt operation request to create the new call leg, followed by RequestReportBCSMEvent and Continue operation requests to arm the appropriate EDPs and begin call leg routing.

Tip The R-IM-SSF will populate the user variable user.rimssf.leg.invite in the interceptor script context with the incoming INVITE message, as described in Interceptors for Network Initiated Calls, whenever a Connect or InitiateCallAttempt message is sent to the network, regardless of whether the call was IN or SIP initiated.

The R-IM-SSF arms all EDPs in in the RequestReportBCSMEvent operation in Interrupted mode, except for the abandon EDP when using CAPv2, as this protocol only supports the Notify & Continue mode for this EDP. The R-IM-SSF determines which EDPs to arm based on information contained in the INVITE:

  • if the INVITE contains a Record-Route header, or the Contact header URI is not the local URI of the R-IM-SSF, then the R-IM-SSF arms all EDPs, and monitors the call leg for its entire duration

  • otherwise, the R-IM-SSF arms all EDPs except disconnect, and only monitors the call leg until it is answered or fails for some reason (busy, no answer, and so on).

After the Connect or Continue operation has been sent by the R-IM-SSF, it sends a 183 Session Progress provisional response for the INVITE to the SIP-AS.

Warning Multi-leg call scenarios such as parallel alerting require an IN protocol that supports more than two parties in a single call. Currently the only relevant protocol supported by the R-IM-SSF is Ericsson INAP CS1+. If an initial INVITE is received to establish a new call leg but the maximum number of call legs supported by the IN protocol has already been reached, then the R-IM-SSF sends a 503 Service Unavailable final response to the INVITE.

User interaction

The R-IM-SSF identifies an INVITE for user interaction in a number of ways. The following table describes how the R-IM-SSF may identify such an INVITE and what configuration information is used to handle it:

Identified by…​ Required Configuration

A Request-URI containing the play parameter.

The value of the play parameter is the URL of the announcement to play. A URL announcement mapping must be configured in the R-IM-SSF for this URL.

A Request-URI with an address (user name or telephone number) starting with the announcement prefix configured for the service.

A prefix announcement mapping must be configured in the R-IM-SSF for the prefix.

A content type of application/mediaservercontrol\+xml.

A media XML announcement mapping must be configured in the R-IM-SSF for the service key of the triggering InitialDP. If the call was a SIP network-initiated call, then a media XML announcement mapping must be configured for a service key of 0.

Additional service configuration information determines whether to play the announcement in direct or assisting mode. If in assisting mode, an EstablishTemporaryConnection operation request is sent by the R-IM-SSF to the MSC. A ResetTimer operation is also sent if the configured reset timer timeout period is greater than 0. The R-IM-SSF then waits for a response from the MSC.

Announcements using the IN

If the announcement is played in direct mode, or the MSC/SRF responds with an AssistRequestInstructions operation on an assisting dialog with a correlation ID matching that sent in the EstablishTemporaryConnection operation, then the announcement is played using the IN, and the R-IM-SSF sends a 200 OK response to the SIP-AS for the announcement INVITE. Once the R-IM-SSF receives the ACK for the 200 OK from the SIP-AS, the R-IM-SSF then sends ConnectToResource and PlayAnnouncement operation requests to start the announcement. A ResetTimer operation will also be sent if the configured reset timer timeout period is greater than 0.

Announcements using the SIP network

The MSC may play an announcement using a SIP MRF by sending an INVITE towards the R-IM-SSF. In order for the R-IM-SSF to recognise this INVITE and correlate it with the correct session, the INVITE must have a Request-URI with user equal to either the full assistingSSPIPRoutingAddress address digits or the correlation ID part only from the EstablishTemporaryConnection operation (if using combined mode), or a Request-URI with user equal to the correlationID digits from the EstablishTemporaryConnection operation (if using separate fields). A Service Composition Selection extension component is implemented by the R-IM-SSF to perform this session correlation. If a correlated session is found, the SCS extension routes the INVITE to the session (which may be on another cluster node).

Once the correct R-IM-SSF session receives the INVITE, the R-IM-SSF forwards the announcement INVITE received from the SIP-AS to the media server address configured in the announcement mapping, or the default media server address configured for the R-IM-SSF if the announcement mapping does not have a value set for this parameter. The response from the MRF is forwarded back to the SIP-AS. If the MRF responds to the INVITE with a 200 OK, a 183 Session Progress provisional response with the SDP from the MRF is sent to the MSC so that the media connection can be established. Further in-dialog requests such as INFO sent by the SIP-AS or MRF are automatically proxied by the R-IM-SSF to the corresponding peer.

Mid-call announcements

The R-IM-SSF supports user interaction mid-call, that is, any time after the initial trigger when the call is being routed to a second call party or a second call party has already answered the call. An INVITE for a mid-call announcement must identify the call leg that the announcement is to be played to by including a Target-Dialog header as defined in RFC 4538. The Target-Dialog header includes the Call-ID and local and remote tags (from the R-IM-SSF’s perspective) that identifies the relevant SIP dialog for the call leg in the R-IM-SSF.

The R-IM-SSF supports additional special-case behaviour for user interaction on call answer. In a two-party call, if the SIP-AS sends an INVITE for user interaction for the second call party immediately after receiving the 200 OK from the R-IM-SSF for call answer and before forwarding the 200 OK upstream back to the R-IM-SSF, then the R-IM-SSF will automatically split the second call leg into a separate call segment before playing the announcement, and will move the leg back to the primary call segment again when the announcement completes. In any other case, if mid-call user interaction requires the target call leg to be split to a separate call segment first then re-INVITEs for media change indicating hold and resume for that call leg must be sent before and after the user interaction sequence.

Warning Mid-call user interaction requires an IN protocol that supports this function. Currently the only relevant protocol supported by the R-IM-SSF is Ericsson INAP CS1+. The R-IM-SSF will include the tdialog option tag in the Supported header of the INVITE towards the SIP-AS, and a 200 OK response to an INVITE sent by the SIP-AS, if mid-call user interaction is supported by the R-IM-SSF instance. If an INVITE is received requesting mid-call user interaction but the IN protocol in use does not support this function, the R-IM-SSF sends a 488 Not Acceptable Here final response to the INVITE.

re-

INVITE

The R-IM-SSF recognises the following updates via an INVITE received in the context of an existing dialog:

Media change

The R-IM-SSF supports leg hold and resume through a media change in a new SDP offer. If the new SDP contains a session attribute with value sendonly and the corresponding IN call leg is not currently being held, then a HoldCallPartyConnection operation request is sent by the R-IM-SSF. If the new SDP contains a session attribute with value sendrecv and the corresponding IN call leg is currently held, then a Reconnect operation request is sent by the R-IM-SSF. If sendonly is received for a leg that is already held, or sendrecv is received for a leg that is not held, the R-IM-SSF performs no action on the IN dialog and simply responds to the INVITE with a 200 OK.

Warning Leg hold and resume requires an IN protocol that supports these functions. Currently the only relevant protocol supported by the R-IM-SSF is Ericsson INAP CS1+. If an INVITE is received requesting leg hold but the IN protocol in use does not support this function, the R-IM-SSF sends a 488 Not Acceptable Here final response to the INVITE.
CANCEL

or

BYE

A CANCEL or BYE terminates a SIP dialog. The R-IM-SSF handles such an event as follows:

Normal call leg termination

The R-IM-SSF determines whether to disconnect just the corresponding IN call leg or the entire IN call based on the following conditions:

  • if call monitoring is only until call answer (rather than call termination) and the call has already been answered, then only the call leg is released;

  • if the call is an IN initiated call and the outgoing SIP dialog, representing the incoming (calling party) call leg, has terminated, then the call is released;

  • if no outgoing call legs would remain after the IN leg was disconnected, then the call is released;

  • if the call is a SIP network initiated call and only one call leg would remain after the IN leg was disconnected, then the call is released;

  • otherwise, only the call leg is released.

The call is released using the ReleaseCall operation request. A single leg is released using the ReleaseCallPartyConnection operation request.

User interaction

If a dialog representing user interaction is terminated by the SIP-AS:

  • if the announcement is being played using the IN, then a Cancel operation request is sent by the R-IM-SSF to cancel the PlayAnnouncement request previously sent to start the user interaction; else

  • if the announcement is being played using the SIP network, then a CANCEL or BYE request (depending on current state) is sent to the MRF to terminate the announcement.

Once the announcement is confirmed terminated, the R-IM-SSF then sends a DisconnectForwardConnection operation request to the MSC to end the user interaction.

 INFO

In-dialog INFO requests are supported between the SIP-AS and MRF when performing user interaction using the SIP network. The R-IM-SSF will act as proxy for these INFO requests and their responses.

2xx success response

A success response to the INVITE means at least one outgoing call leg has been answered. If the call is to be monitored only until answer then the IN dialog is closed and the session is ended, otherwise call monitoring continues.

3xx redirect response

The R-IM-SSF does not currently support 3xx redirect responses.

400-699 error response

An error response may be received by the R-IM-SSF for the INVITE sent to the SIP-AS during IN call establishment. It indicates a failure to establish the call and causes the R-IM-SSF to terminate the IN dialog with ReleaseCall operation request.

Example Call Flows

Below are some general and user-interaction example call flows illustrating R-IM-SSF behaviours.

Note In the following diagrams, messages related to different SIP dialogs display in different colours to help interpret the call flows. To keep it simple, 100 Trying provisional responses and PRACK/200 OK messages for reliable provisional responses are not shown (though the R-IM-SSF does send or handle those messages as appropriate).

General call flows

Below is the typical basic call flow for an IN-initiated call that is answered. The calling (A) party hangs up at call end.

Note The R-IM-SSF sends both 180 Ringing and 200 OK on call answer if the IN protocol in use does not support an explicit alerting event detection point (EDP), as many SIP applications expect such a message sequence.
in basic call flow

Unanswered call

Below is the typical call flow for an IN-initiated call that goes unanswered.

in no answer

Call alerting

The R-IM-SSF will arm the appropriate alerting event detection point (EDP) and handle the corresponding EventReportBCSM if the IN protocol in use supports it.

in with alerting

Forked SIP dialog - call setup

SIP dialog forking for parallel alerting is supported for IN protocols that provide call party handling operations. The call flow below illustrates call setup when the SIP dialog is forked.

in forked dialog

Forked SIP dialog - call answered

Once a forked call leg answers, the leg is moved to the primary call segment (if necessary) and other legs are disconnected when the SIP-AS CANCELs the INVITEs.

in forked dialog answer with rcpc

Leg hold

Leg hold and resume is supported for IN protocols that provide call party handling operations. Below is the typical call flow for a leg hold procedure.

hcpc ok

An attempt to place a leg on hold may fail or be rejected by the MSC for various reasons. In these cases, the R-IM-SSF will always respond to the re-INVITE with the same error response.

hcpc failed

The R-IM-SSF will immediately reject an attempt to place a leg on hold when using an IN protocol that doesn’t provide call party handling operations.

hcpc unsupported

Network initiated call - triggered by SIP

Below is the basic call flow for a two-party network initiated call triggered by the SIP-AS.

nic answered

User-interaction call flows

User interaction using direct mode

Below is the typical call flow for a pre-call announcement using direct mode. The call is allowed to proceed after the announcement completes.

announcement direct

User interaction using an assisting dialog

Below is the typical call flow for a pre-call announcement using assisting mode. The call is terminated after the announcement completes.

announcement etc

User interaction using a SIP MRF announcement device

Below is an example call flow for a pre-call announcement played using an MRF in the SIP network. The call is terminated after the announcement completes.

announcement mrf

User interaction on call answer

Below is an example call flow for an announcement played to the B party as soon as they answer the call. The call leg is automatically placed on hold for this use case. This example shows the announcement played using an MRF in the SIP network, but the announcement could be played using any supported method.

announcement on answer

Mid-call user interaction

Below is an example call flow for a mid-call announcement played to the B party. The target call leg must be placed on hold using a re-INVITE before beginning the announcement procedure if the announcement should only be played to the one call party. The call leg is returned from hold with another re-INVITE after the announcement completes. This example shows the announcement initiated using an ETC operation, but the announcement could be played using any supported method.

announcement mid call

R-IM-SSF Statistics

The R-IM-SSF defines a parameter set with these statistics for each SS7 protocol it supports.

Tip

You can list the statistics parameter sets using the rhino-stats tool:

$ ./rhino-stats -l SLEE-Usage.Services.ServiceID[name=R-IM-SSF,vendor=OpenCloud,version=<version>].

See Usage in the Rhino Administration and Deployment Guide for more details about usage statistics.

Counter Description
 totalCalls

number of triggers processed

 noLicenseCalls

number of triggers not processed because no licence was installed

 internalErrors

number of internal errors

 sS7Errors

number of SS7 errors

 sipErrors

number of SIP Operation errors

 answeredCalls

number of calls for which R-IM-SSF received an {{Answer}}

 noAnswerCalls

number of calls for which R-IM-SSF received a {{NoAnswer}}

 busyCalls

number of calls for which R-IM-SSF received a {{Busy}}

 abandonCalls

number of calls for which R-IM-SSF received an {{Abandon}}

 announcements

number of announcements played

 cDRWriteFailures

number of calls for which R-IM-SSF failed to write a CDR while the CDR RA was enabled

 cDRsNotWritten

number of calls for which R-IM-SSF failed to write a CDR because the CDR RA was not enabled

Parameter sets

The R-IM-SSF accumulates usage statistics on a per-protocol basis. Each R-IM-SSF SBB named for a specific IN protocol accumulates usage statistics for that protocol. The following parameter sets accumulate usage statistics for the protocol named by the SBB:

SLEE-Usage.Services.ServiceID\[name=R-IM-SSF,vendor=OpenCloud,version={space-metadata-from:rimssf-version}\].SbbID\[name=rimssf.cap2.sbb,vendor=OpenCloud,version={space-metadata-from:rimssf-version}\].(default)
SLEE-Usage.Services.ServiceID\[name=R-IM-SSF,vendor=OpenCloud,version={space-metadata-from:rimssf-version}\].SbbID\[name=rimssf.cap3.sbb,vendor=OpenCloud,version={space-metadata-from:rimssf-version}\].(default)
SLEE-Usage.Services.ServiceID\[name=R-IM-SSF,vendor=OpenCloud,version={space-metadata-from:rimssf-version}\].SbbID\[name=rimssf.inap.sbb,vendor=OpenCloud,version={space-metadata-from:rimssf-version}\].(default)

R-IM-SSF Alarms

The R-IM-SSF may raise the following two alarms:

Alarm Type Alarm Instance ID Alarm level Description Raised if…​
 UnlicensedComponent

Name of resource adaptor entity providing R-IM-SSF management

CRITICAL

R-IM-SSF is not active. Check that there is a valid license for Rhino-R-IM-SSF, and that resource adaptor entity <entity-name> has been activated.

…​the R-IM-SSF is triggered by the SIS, but the R-IM-SSF is not licensed.

 nolicense
originating

or

terminating

CRITICAL

No license to process
<trigger-type> triggers.

…​the R-IM-SSF is triggered by the SIS, but the R-IM-SSF is not licensed.

 missing-config-profile-table
 rimssf-configuration-profile-table

CRITICAL

Configuration profile table
rimssf-configuration-profile-table does not exist.

…​the R-IM-SSF is triggered by the SIS, but the profile table containing general configuration information for the R-IM-SSF does not exist.

 missing-config-profile
 rimssf-configuration-profile

CRITICAL

Configuration profile
rimssf-configuration-profile does not exist.

…​the R-IM-SSF is triggered by the SIS, but the profile containing general configuration information for the R-IM-SSF does not exist.

 missing-service-config-profile-table
 rimssf-service-configuration-profile-table

CRITICAL

Service configuration profile table
rimssf-service-configuration-profile-table does not exist.

…​the R-IM-SSF is triggered by the SIS, but the profile table containing SIP-AS configuration information does not exist.

 missing-invite-config-profile-table
 rimssf-invite-builder-profile-table

CRITICAL

INVITE Builder Configuration profile table
rimssf-invite-builder-profile-table does not exist.

…​the R-IM-SSF is triggered by the SIS, but the profile table containing INVITE builder configuration information does not exist.

 missing-sdp-config-profile-table

rimssf-sdp-builder-profile-table

CRITICAL

SDP Builder Configuration profile table
rimssf-sdp-builder-profile-table does not exist.

…​the R-IM-SSF is triggered by the SIS, but the profile table containing SDP builder configuration information does not exist.

 cdr

n/a

CRITICAL

Failed to write a CDR.

…​the R-IM-SSF fails to write a call detail record.

Tip
Threshold-based alarms

You can define your own custom alarms using Rhino’s threshold based alarm feature — see Threshold Alarms in the Rhino Administration and Deployment Guide.

Using the R-IM-SSF

Below are instructions for using the R-IM-SSF.

Including the RIM-SSF in a service composition

Before you can use the R-IM-SSF in a service composition you must create a service reference in your SIS IN instance. Use the sis-console command createlocalserviceref to do this (see 1 Creating Local Service References):

[Rhino@localhost (#1)] createlocalserviceref sis-in R-IM-SSF "name=R-IM-SSF,vendor=OpenCloud,version=3.0"
Created service reference R-IM-SSF for local SLEE service ServiceID[name=R-IM-SSF,vendor=OpenCloud,version=3.0]

Supporting more than one R-IM-SSF use in a service composition

The rimssf-service-configuration-profile-table, rimssf-invite-builder-profile-table and rimssf-sdp-builder-profile-table tables are keyed on the ServiceKey. So, one can define many records in these tables with the ServiceKey = <value that corresponds to a service> and use a SIS signaling interceptor to update the ServiceKey in the InitialDP before the R-IM-SSF is triggered.

Rate limiting the R-IM-SSF

The R-IM-SSF defines a custom rate limiter endpoint, rimssf-triggers. By default this limiter endpoint is not associated with a limiter. You can create a limiter in the SIS using the sis-console, and associate it with the R-IM-SSF limiter endpoint if you wish.

[Rhino@localhost (#0)] listlimiterendpoints
RAEntity/rimssf-cdr/Input
RAEntity/rimssf_management/Input
RAEntity/rimssf_management/rimssf-triggers
RAEntity/sis-cap/Input
RAEntity/sis-cap/inbound
RAEntity/sis-inap/Input
RAEntity/sis-inap/inbound
RAEntity/sis-sip/Input
RAEntity/sis-sip/inbound

Changelog

R-IM-SSF SIS Module 3.0.0.1

* This release is built on and requires JDK 11. It requires Rhino 3.0 or later releases.

R-IM-SSF SIS Module 1.4.2.4

* Handle crossover of incoming PRACK and outgoing 200 (PRX-219)

* Handle crossover of incoming 200/BYE and outgoing BYE within Rhino more
  cleanly (PRX-101)

R-IM-SSF SIS Module 1.4.2.2

* Updated installer to support SIS-2.5.3 in addition to 2.5.2 (PRX-166)

* Fixed some cases where an incoming BYE request during user interaction may
  not have received a response.

R-IM-SSF SIS Module 1.4.2.1

* Migrated to CGIN 1.5.2.

R-IM-SSF SIS Module 1.4.0.12

* Behaviour on call abandon has been modified.  If the IN call is abandoned,
  as well as a CANCEL being sent on the outgoing SIP dialog, a 487 error
  response will also be sent on any incoming SIP dialogs for call legs.  This
  ensures that all SIP dialogs are terminated properly.

* An EventReportBCSM event for the tAbandon EDP was accidentally being
  ignored.  This is now fixed.

R-IM-SSF SIS Module 1.4.0.10

* Fixed behaviour on IN dialog abort.  Incoming SIP dialogs will no longer
  simply be invalidated.  Incoming INVITEs that have not yet had a final
  response will be responded to with a 500 Internal Server Error.  For
  confirmed dialogs, a BYE will be sent.

R-IM-SSF SIS Module 1.4.0.9

* Fixed a state machine issue dealing with ACK and BYE when call monitoring
  completes when the call is answered.

* Fixed an issue dealing with IN dialog abort while waiting for an ACK after
  answer.

R-IM-SSF SIS Module 1.4.0.8

* Incoming INVITEs with a From header containing the anonymous URI will now be
  handled correctly.

R-IM-SSF SIS Module 1.4.0.7

* Added a new option to the SIP-AS configuration for a service key that
  determines if the R-IM-SSF will do any number normalisation when mapping
  protocol messages between the IN and SIP.

* Added new profile table, management MBean, and configuration commands to
  configure options for network initiated call.  Added configuration option
  that determines in the R-IM-SSF will do any number normalisation when
  mapping protocol messages from SIP to IN for network initiated calls.

* Fixed an issue setting the ResetTimer timeout configuration parameter to 0.

* Fixed potential security exceptions when accessing persistent state.

R-IM-SSF SIS Module 1.4.0.6

* The R-IM-SSF will no longer accept and try to process IN dialogs for which
  it does not recognise the application context.

R-IM-SSF SIS Module 1.4.0.5

* Updated to cgin-connectivity 1.5.0-protocol-patches

R-IM-SSF SIS Module 1.4.0.4

* The main R-IM-SSF configuration profile has a new option that specifies if
  the R-IM-SSF will always send a Connect operation to route a call (the
  previous behaviour), or will send a Connect or Continue depending on whether
  or not the SIP-AS changes the A or B party numbers when forwarding the
  INVITE.

* The prefix in a prefix announcement mapping is now stored in its original
  form as a string rather than being converted to a number.  This means that
  any leading zeros are preserved, and also that the digits '#' and '*' can
  be used if necessary.

* User interaction is now supported using an MRF if the MSC responds to an
  Establish Temporary Connection operation request with an MGCP INVITE.

* Fixed issues with some R-IM-SSF management commands not working properly.

* Fixed a NullPointerException when the R-IM-SSF is invoked if the Management
  Resource Adaptor is not active.

* Fixed NullPointerException when attempting to raise an alarm after a CDR
  write failure.

R-IM-SSF SIS Module 1.4.0.2 (2013-02-02 23:20:26 +1300)

* Updated to cgin-connectivity 1.5.*

* The value used for the applicationTimer dp-specific criteria when arming the
  o/tNoAnswer EDP is now a configurable option.

* The o/tAbandon EDP armed by the RequestReportBCSMEvent operation when using
  CAPv2 will now correctly use the Notify & Continue arming mode, as
  Interrupted mode is not supported for this EDP in CAPv2.

* Fixed an issue where the CalledPartyBCDNumber in CAP originating BCSM
  triggers was not being recognised.

* Revised usage parameters collected by the R-IM-SSF.  In particular, the
  "EndedByASCallsCounter" has been removed as it's no longer easily possible
  in some cases to determine a specific reason for call termination.

R-IM-SSF SIS Module 1.3.0.0 (2011-09-26 10:22:41 +1300)

* Updated to cgin-connectivity 1.4.*

R-IM-SSF SIS Module 1.2.0.1 (2011-04-20 13:05:10 +1200)

* Updated to cgin-connectivity 1.3.*

* Updated to use configured CountryCode to create SIP URIs from Calling and
  Called Party Numbers.

* Updated to use original Calling and Called Party Numbers settings where
  possible to create the forwarding and forwarded party numbers from incoming
  SIP URIs.

R-IM-SSF SIS Module 1.1.0 (2010-08-30 17:44:44 +1200)

* Initial release.