Under each SIP message you can add the applications in a chain to be called when this message is received. The applications will be called in the order you specify unless you explicitly set the Order value.
In order to move an application from one chain to another you can simply drag the blue handle of the application. to another chain
In order to move a whole chain and associate it with another SIP message, you can drag the red handle to another column.
As an application router component is essential for the functioning of the container the following application router logic SHOULD be available with every container compliant with this specification. The container implementations MAY chose to provide a much richer application router component. For the purpose of this discussion the application router defined in this appendix is termed as Default Application Router (DAR).
The Application Router and the Container have a simple contract defined
by the SipApplicationRouter
interface.
The DAR MUST implement all the methods of that interface as described in
this document.
The DAR Configuration File
The DAR works off a simple configuration text file which is modeled as a
Java properties file:
INVITE: (sip-router-info-1), (sip-router-info-2).. SUBSCRIBE: (sip-router-info-3), (sip-router-info-4)..
init()
is first called on the DAR. The arguments passed in the
init()
are ignored. applicationDeployed()
or applicationUndeployed()
is called. Similar to init()
, the argument of these two invocations are ignored, these callbacks act just as a trigger to read the file afresh.
The sip-router-info data that goes in the properties file is a stringified version of the SipRouterInfo object. It consists of the following information :
Following is an example of the DAR configuration file:
INVITE: ("OriginatingCallWaiting", "DAR:From", "ORIGINATING", "", "NO_ROUTE", "0"), ("CallForwarding", "DAR:To", "TERMINATING", "", "NO_ROUTE", "1")In this example, the DAR is setup to invoke two applications on INVITE request, one each in the originating and the terminating half. The applications are identified by their names as defined in the application deployment descriptors and used here. The subscriber identity returned in this case is the URI from the From and To header respectively for the two applications. The DAR does not return any route to the container and maintains the invocation state in the stateInfo as the index of the last application in the list.
The DAR Operation
The key interaction point between the Container and the Application Router
is the method
SipApplicationRouterInfo getNextApplication (SipServletRequest initialRequest, SipApplicationRoutingRegion region, SipApplicationRoutingDirective directive, java.lang.String stateInfo);This method is invoked when an initial request is received by the container. When this method is invoked on DAR it will make use of the stateInfo and the initialRequest parameters and find out what SIP method is in the request. Next it will create the object
SipApplicationRouterInfo
from the sip-router-info information in the
properties file, starting from the first in the list. The stateInfo could
contain the index of the last sip-router-info returned so on next
invocation of getNextApplication the DAR proceeds to the next sip-router-
info in the list. The order of declaration of sip-router-info becomes
the priority order of invocation.
As you would notice, this is a minimalist application router with no processing logic besides the declaration of the application order. It is expected that in real world deployments, the application router shall play an extremely important role in application orchestration and composition. It is likely to make use of complex rules and diverse data repositories. The DAR is intended to be a very simple implementation that is available as part of the reference implementation, and could be used instead of a real world application router.