INVITE triggers a composition that invokes IM-SSF

The process starts when …​

1

…​the SIS receives an INVITE. This triggers a SIS process that selects a service composition to run — which includes an invoke of the IM-SSF. For example, in the following diagram we see that a service composition is using the IM-SSF to run SS7-based VPN services, in a composition with a SIP-based OCS.

imssf

2

The SIS forwards the INVITE message to the IM-SSF. The IM-SSF uses request-uri and the headers of the INVITE to:

3

IM-SSF uses a key to look up subscription information

To look up subscription information, IM-SSF first checks to see if the INVITE has an "IM-CSI-Key"header. If so, IM-SSF will use the value of theheader as the key to lookup subscription information. Otherwise, it will:

1

Get the destination MSISDN from the request-uri, and get the source MSISDN from the Fromheader address uri.

2

3

If the call is originating:

  • Check the destination number against the list of provisioned B number prefixes. If it matches, then use the destination number as the key for lookup of O-IM-CSI.

  • Otherwise use the source number as the key for lookup of O-IM-CSI

Tip To provision the set of B number prefixes, use the sis-console command configure-bnumber-prefixes. (See General IM-SSF Configuration for more details.)

4

If the call is terminating:

  • Use the destination number as the key for lookup of VT-IM-CSI.

Warning If IM-SSF fails to locate any subscription information for the call, it rejects the INVITE.
Note
Getting an MSISDN from a SIP URI
  1. If the uri is a Tel URL then, the MSISDN is the Tel URL address without any separator charactors. If the Tel URL includes a leading "+", then treat the numbers as international.

  2. Otherwise, the uri is a SIP URI. Take the user part of the SIP URI, and parse it according to the rules in rfc2806. By default, the IM-SSF relaxes these rules to allow non-digits ("A"…​"D") in the address sequence.

If the IM-SSF cannot extract an MSISDN, it rejects the INVITE.

Classifying the call as originating or terminating

To classify a call as originating or terminating, the IM-SSF first checks to see if the INVITE includes an "IM-Access-Override" header. If the value of theheader is:

  • orig — IM-SSF applies originating treatment

  • term — IM-SSF applies terminating treatment

  • otherwise, the IM-SSF checks the parameters in the topmost Routeheader (see below).

Note The IM-SSF is configured with the parameter to look for (RqdParameter) and the expected parameter value (RqdParameterVal) that tells the IM-SSF if the call is originating access. RqdParameterVal may be empty, indicating that presence of the parameter is enough to classify the call as originating.{ocpanel}
Tip You can define the parameter the IM-SSF looks for using the sis-console command configure-originating-access. See General IM-SSF Configuration for more details.

Inspecting the Routeheader

The IM-SSF inspects the topmost Routeheader and checks each parameter:

if (RqdParameterVal is Empty) then

  if (param == RqdParameter) then call is *originating*, else call is *terminating*

else

  if (param == RqdParameter and paramVal == RqdParameterVal) then call is *originating* else call is *terminating*

In the following example, we can see an incoming INVITE that includes a parameter mode with expected value originating in the topmost route (in this case, the IM-SSF should be configured: configure-originating-access mode originating).

  INVITE sip:1453800888888@ims1.operator.com SIP/2.0
  To: <sip:1453800888888@ims1.operator.com;user=phone>
  From: <sip:+886230050000@ims1.operator.com;user=phone>;tag=snl_0008395652_NSN_CLIENT
  Call-ID: NSNSIP-c2421c0a-c4421c0a-1-11-1254881719-108155-1254989874
  CSeq: 1235 INVITE
  ...
  Route: <sip:6N0j0Hg5C+O3p0hBLp~usAFA@172.28.81.7:5060;oc-node=101;lr;transport=udp;mode=originating>, ...
...

Running the BCSM

The IM-SSF executes the IM-BCSM following description 3gpp 23.278. An important aspect of this process is the subscription information it uses for the call. The subscription information tells the IM-SSF, among other things, the address of the external SCP to contact, the ServiceKey to use in the InitialDP message and how to respond in failure scenarios. The following tables explain the fields in both O-IM-CSI and VT-IM-CSI.

Properties common to both O-IM-CSI and VT-IM-CSI

Field Description
 Msisdn

The unique id of the subscriber. This field is a string that is normally a digit sequence. It may, however, be a string that corresponds to the IM-CSI-KEYheader.

 getGsmSCFAddress

The SCCP address of the external SCF.

 ServiceKey.

The service key to include in the InitialDP message sent to the SCF. This indicates the service to execute in the SCF.

 DefaultCallHandling

Indicates whether the IP multimedia session shall be released or continued in case of error in the IM-SSF to gsmSSF dialogue. One of (Default_Released, Default_Continued).

 CAMELCapabilityHandling

Indicates the phase of CAMEL which is asked by the gsmSCF for the service. One of (CAPv2, CAPv3, CAPv4, ETSIINAPCS1).

 CSIActiveStatus

Whether the CSI is active or not.

 TraceEnabled

Whether detailed tracing should be done, if tracer level is Fine, Finer, or Finest.

O-IM-CSI

Field Description

Trigger Detection Points

 CollectedInfo

One of (INTERRUPTED, NOTIFY_AND_CONTINUE, TRANSPARENT).

 AnalyzedInformation

One of (INTERRUPTED, NOTIFY_AND_CONTINUE, TRANSPARENT).

Note that this TDP is only relevant for INAP.

 RouteSelectFailure

One of (INTERRUPTED, NOTIFY_AND_CONTINUE, TRANSPARENT).

VT-IM-CSI

Field Description

Trigger Detection Points

 TerminatingAttemptAuthourised

One of (INTERRUPTED, NOTIFY_AND_CONTINUE, TRANSPARENT).

 TBusy

One of (INTERRUPTED, NOTIFY_AND_CONTINUE, TRANSPARENT).

 TNOAnswer

One of (INTERRUPTED, NOTIFY_AND_CONTINUE, TRANSPARENT).

Tip See Configuring IM-SSF Subscription Information for the sis-console commands to use for managing the subscription information.
Previous page Next page