Article by David Ferry, Chief Engineer & Founder of OpenCloud.

This session in the Developer Summit at TADS will walk through the implementation of a pair of features to handle GSM Mobile to IMS (IP Multimedia Subsystem) re-origination.  The features are written on OpenCloud’s Sentinel. We also illustrate the use of our Scenario Editor and Scenario Simulator so that the appropriate signalling can be fired at the features under test.

1. First the IN (Intelligent Network) side is triggered via a CAMEL (Customized Applications for Mobile networks Enhanced Logic) trigger. Sentinel runs the appropriate Feature Execution Script that in turn invokes an IN/CAMEL feature.
2. The IN/CAMEL feature is invoked with an IDP (Initial Detection Point) and a CAMEL dialog.
3. It checks that the call-type is appropriate (Originating or Terminating but not Forwarding).
4. It then attempts to allocate a re-origination number from a pool of numbers, and store correlation information essentially the originally dialed number. This number will be stored for a certain time.
5. An error condition could occur if the number pool is exhausted. If so the feature increments a suitable statistic, and releases the call.
6. Assuming allocation succeeded and correlation information was stored appropriately, the feature routes the call towards the re-origination number.

All Re-origination pool management etc. is performed by a SLEE (Service Logic Execution Environment) Resource Adaptor (RA) – the Correlation RA. The rationale for this is that the feature logic is simplified as it just uses the Correlation RA to do the hard work, additionally multiple features can use the Correlation RA so we get some code/behaviour re-use.

Now the Circuit Switched core network will attempt to route towards the IMS core. Once the IMS core network receives the appropriate Signalling it sees that a call is routed towards a special number – termed a Public Service Identity (PSI). The I-CSCF will then trigger the application, as it does not know how to route the PSI. The application now receives a SIP INVITE trigger from the I-CSCF.

This SIP INVITE is routed to the SLEE service, and includes the A number as well as the PSI (as the B-number).
Sentinel invokes the appropriate Feature Execution Script that in turn invokes a SIP feature. This feature is invoked with the SIP request and a SIP Session.  It checks some parameters on the INVITE and then assuming these succeed, it fetches the correlation data from the Correlation RA. It them maps this data into the INVITE. This is essentially restoration of the originally dialled B number!

However, we still are unable to route this call further, as the IMS core does not know the Serving CSCF for the called user. Therefore the feature executes a query against the HSS using the Diameter Sh interface/Resource Adaptor. The query asks for the S-CSCF name for the B-party identity. At this point, the query may timeout, or return an error response, or succeed. Error responses/timeouts etc from the HSS query result in an error response being sent towards the I-CSCF.
Success responses mean that the Feature can request the Sentinel framework to route the transformed INVITE onwards (towards the S-CSCF).

In 3GPP standards, the application (termed the Service Centralization and Continuity Application Server, or SCC-AS) is now supposed to act as a B2BUA (Back 2 back user Agent) between the I-CSCF and the S-CSCF.  Sentinel essentially does this for free, so that the feature is simplified. Alternatively the feature can be configured to return a SIP Redirect response to the I-CSCF so that it can directly communicate with the S-CSCF.

Signalling flows are implemented using OpenCloud’s Scenario Editor+Simulator.  Continuous Integration is used to drive integration tests that use these signalling flows.  This will all be demonstrated live during the session to see the unique telecom apps enabled of the features to handle GSM Mobile to IMS (IP Multimedia Subsystem) re-origination.