Below are instructions for using the IM-SSF
Including the IM-SSF in a service composition
Before you can use the IM-SSF in a service composition you must create a service reference in your SIS SIP instance. Use the sis-console
command createlocalserviceref
to do this (see 1 Creating Local Service References):
[Rhino@localhost (#1)] createlocalserviceref sis-sip IM-SSF "name=IM-SSF,vendor=OpenCloud,version=1.4" Created service reference IM-SSF for local SLEE service ServiceID[name=IM-SSF,vendor=OpenCloud,version=1.4]
Supporting more than one IM-SSF use in a service composition
The O-IM-CSI
and VT-IM-CSI
tables are keyed on the MSISDN field (this field is actually of type String, so we can use things other than digit sequences as a key if we wish). The IM-SSF will also recognise a proprietary header: IM-CSI-KEY
that it will use in place of the subscriber’s MSISDN when selecting an appropriate CSI.
So, one can define O-IM-CSI
and VT-IM-CSI
with the MSISDN
field = <some string that corresponds to a service>
and use a SIS signaling interceptor to add a header to the initial INVITE with IM-CSI-KEY: <some string that corresponds to a service>
. The IM-SSF removes this header so we do not propagate it forward.
In the following example, we can see a fragment of an INVITE message that uses the IM-CSI-KEY
header with the value to use as the CSI key of VPN
.
INVITE tel:+351210999999 SIP/2.0 From: <tel:+351210900000>;tag=1 To: <tel:+351210999999> ... CSeq: 8511 INVITE ... IM-CSI-KEY: VPN
Overriding the IM-SSF method for classifying originating or terminating access
The IMSSF uses parameters in the route header to determine whether to use originating or terminating access. However, some use cases require an alternate method to classify the call as originating or terminating treatment. The IMSSF can recognise a proprietary header to decide how to treat the call.
The header is called IM-Access-Override
, with valid values of orig
and term
. If this header exists, then the route is ignored and the value of the header is used instead.
If the values provided are not orig
or term
, the IM-SSF falls back onto the default behaviour.
The IM-SSF also removes this header so we do not propagate it forward.
One can use a SIS signaling interceptor to perform any ad-hoc determination of originating or terminating access, and add an IM-Access-Override
header.
Tracing in the IM-SSF
The IM-SSF supports a per-CSI tracing option that will generate detailed output of messages sent and received, and generate a flow-trace output. You may configure this feature with the sis-console
command imssfenabletracing
(see Configuring IM-SSF Subscription Information).
Support for IM-SSF acting as an assisting SSF for announcements
The IM-SSF supports ETC/ARI for announcements. It acts as an assisting SSP when it receives an ETC, by opening a second dialog to the SCP and issuing an ARI on it. The properties of the ARI can be configured using the sis-console
, with commands such as imssfaddariipavailable
and imssfaddariipsspcapabilities
(see Configuring IM-SSF User Interaction).
These commands let you manage a lookup table of assistSSPIPRoutingAddres → AssistRequestInstructions
properties.
IP Capabilities Profile Attribute | Description |
---|---|
AssistingSSPIPRoutingAddress |
As provided in the ETC. |
IncludeIPSSPCapabilities |
Whether to include this in the ARI. iPSSPCapabilities:
|
IPSSPCapabilities |
The hex-encoded string that corresponds to the byte[]. |
IncludeIPAvailable |
Whether to include this in the ARI. iPAvailable:
|
IPAvailable |
The hex-encoded string that corresponds to the byte[]. |
If there is no entry in the IP-capabilities table, then the IM-SSF will use defaults of IPSSPCapabilities(supported=(IPRoutingAddress, VoiceBack))
.
See the CGIN RA javadoc and the INAP and CAP specs for the layout of the byte[].
Correlation ID and Scf ID
The EstablishTemporaryConnection
operation may either include a correlation ID and scfID as separate parameters, or it may encode them as a part of the AssistingSSPIPRoutingAddress parameter. This encoding is operator-specific, so the IM-SSF includes configuration options for controlling how this decoding is achieved.
Use the sis-console
command imssfconfigureassistingsspiproutingaddressformat
to configure how the IM-SSF should decode the AssistingSSPIPRoutingAddress
parameter.
The IM-SSF ignores the ScfID
Rather than use the ScfID to query a lookup table for the SCCP address of the SCP, the IM-SSF uses the CSI data it already has. That is, it assumes that the ARI should go to the same SCP that it sent the InitialDP to. |
Rate limiting the IM-SSF
The IM-SSF defines a custom rate limiter endpoint, imssf-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 IM-SSF limiter endpoint if you wish.
[Rhino@localhost (#0)] listlimiterendpoints RAEntity/imssf-cdr/Input RAEntity/imssf_management/Input RAEntity/imssf_management/imssf-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