Restcomm RCML as IMS SCIM layer

The RCML interpreter is the core of the Restcomm CPAAS added value capabilities. Beyond the usual programmability delivered by the REST API, the RCML interpreter allows to further orchestrate all the different services/features supported by the platform, and together with asynchronous Webhooks triggered from the RCML execution, realizes an asynchronous web friendly approach.

SCIM to Service Interaction

As part of our Cloud journey, we keep decomposing our core into micro-services to improve availability, scalability and maintainability of the solution. One of the latest introductions is the formal definition of the SCIM/Orchestration layer, and the interaction pattern with services. We keep pushing to have single Protocol in the communications core, and this one is SIP for its flexibility.

The interaction pattern is based on standard SIP Subscribe/Notify pattern, including a proprietary event package. This package defines how Subscriber and Notify bodies will look like, essentially JSON documents.

The following diagram depicts main functions in the solution

Each RCML verb is a completely independent service feature (conference, record…), with independent logic, and accounting records. The SUBSCRIBE request contains the context of the RCML Interpreter so far( sip call uris, media resources uris, session variables…) and the RCML XML Tag as included in the original document.

When a particular RCML verb is executed, a new service instance is created that handles the SUBSCRIBE request. The RCML service will check the RCML context and the RCML tag for proper conditions. If appropriate, it will accept the subscription and proceed to execute RCML logic. Later the RCML verb will send NOTIFY to RCML SCIM with a list of actions. The set of possible actions are:

• Continue: Tells the interpreter to continue interpretation with next RCML verb in the document.
• ContinueTo(URL): Tells the interpreter to jump into a new RCML documente available in the given HTTP URL. The HTTP request will include regular session parameters, plus any particular parameter included by RCML logic.
• ModifyContext(varName,varValue): Modify the RCML SCIM context with given variable content. Then execute next action.
• SendStatusCallback(URL): send an HTTP request to the given URL. This request will include regular session parameters, plus any particular parameter included by RCML logic.
• Stop(reason): Immediately stop interpretation. Abort any ongoing session with given reason code.

The following sequence depicts a possible interaction:

1. Incoming Call into the Core
2. Restcomm Connect as S-CSCF evaluates the incoming number provisioned trigger, and proxies request to SCIM with HTTP URL to rcml doc.
3. RCML SCIM sends 180 ringing, and start the media bridging.
4. Connect proxies response
5. RCML SCIM acts as B2BUA and establish session with Media server.
6. MediaServer returns SDP to the created bridge endpoint.
7. RCML SCIM sends 200 response as B2BUA
8. Connect proxies response
9. Caller sends ACK.
10. Connect proxies ACK. Media is established
11. SCIM retrieves the RCML document
12. SCIM gets RCML doc and starts interpretation. First verb is invoked.
13. SCIM Subscribes to the RCML service mapped to the ongoing RCML verb (DNS SRV resolution). The subscription includes current context (inbound sip call uri, bridged sip call uri, media server mgcp uri…) and RCML tag from document.
14. The RCML service evaluates the Subscribe body, and accepts the subscription
15. The RCML service is done and completes logic. The service logic may involve call control or media actions over the established sessions, or initiating new sessions (dial, sms, email..). It sends a Notify with subscription state terminated. It includes a set of actions for RCML SCIM.
16. SCIM sends response to RCML service, and subscription is ended.
17. SCIM excutes actions from RCML service, and retrieve a new RCML document. The HTTP request is enriched with RCML SCIM context variables (callid, call status…) and last RCML service parameters.
18. SCIM gets new RCML document and starts interpretation.
19. SCIM Subscribes to the RCML service mapped by current RCML verb.
20. New RCML Services evaluates subscriptions and accepts.
21. The RCML service is done and completes logic. It sends a Notify with subscription state terminated. It includes a set of actions for RCML SCIM.
22. SCIM sends response to RCML service, and subscription is ended. In this case the action is “Continue” but no more RCML verbs are available in the document, the orchestration is stop fro time being.
23. The RCML App decides to apply a new orchestration to the ongoing voice sesion, and sends and API request with a new URL.
24. The APIGateway instruct a REFER to the SCIM via the Connect.
25. Connect proxies REFER to RCML SCIM
26. The SCIM accepts the transfer, and retrieves new RCML document.
27. SCIM gets the document and start interpretation one more time

This is just an example on how the orchestration may happen. The RCML document, the REST API and the RCML webhook triggers allows any combination at any time. The RCML Application is in complete control, and decides how to proceed depending on its business logic.

Conclusion

The RCML programming approach (RCML SCIM + RCML API + RCML Webhooks) provides a web friendly developing framework to author communications services rapidly, and be agnostic of the Telco protocol complexities.