4 Application Composition

For reasons of software modularity or system integration, it is often necessary or desirable to have more than one SIP application in the call path. This capability is addressed by the application routing mechanism specified by JSR 289 [1]. The E4SS development kit includes a powerful application router component, called the DFC application router (DFC AR), that can be used if desired to compose E4SS (or non-E4SS) applications. For detailed information on the DFC application router, see [4]. For information on how to configure a container to use the DFC application router, see Section  A in this manual.

4.1 DFC AR Configuration

The DFC AR rules are specified using XML in a file named approuter.xml. See [EDK_HOME]/etc/approuter.sample.xml in the ECharts for SIP Servlets development kit for an example. The deployment location of the approuter.xml file is container-dependent. See Section  A for details.

4.1.1 Subscription Rules

Two sets of rules are specified in the file: one for applications in the originating region and another for applications in the terminating region. For each rule (enclosed within a <originating-region-mapping> or <terminating-region-mapping> element), an address pattern is specified based on which an initial request is routed to the appropriate application. For an application subscribed to in the originating region, the address in the From header in the initial request is used to match against address patterns specified in the originating region. For an application subscribed to in the terminating region, the Request-URI in the initial request is used to match against address patterns specified in the terminating region. Standard Java regular expressions can be used to specify address patterns.

Consider an example where the goal is to have an initial request routed to an application apporig, when the caller is Alice whose SIP address is ``Alice'' <sip:alice@foo.com>. Moreover, the initial request should subsequently get routed to another application appterm, when the callee is Bob whose SIP URI is sip:bob@foo.com.

To achieve this routing, we specify a <originating-region-mapping> based on Alice’s SIP address so that an initial request would be routed to apporig application. When the SIP address in the From header of a initial request matches the address pattern specified in this rule, the application router inserts an app parameter in the Request-URI with a value of “origapp”. Note that while specifying the address pattern on the originating side, the display name part of a SIP address should also be accounted for. This is different from address pattern specification for the terminating region which specifies a pattern for matching the SIP URI (as opposed to a SIP address) in the Request-URI.


   <originating-region-mapping>
     <mapping>
       <address-pattern>.*<sip:alice@.*</address-pattern>
       <app-name>origapp</app-name>
     </mapping>
   </originating-region-mapping>

Note that after the above rule is matched by the application router, the actual routing of an initial request is done by the servlet mapping mechanisms within the container.

To achieve routing to the appterm application on the terminating side, we specify a <terminating-region-mapping> based on Bob’s URI so that an initial request would be routed to the appterm application.


   <terminating-region-mapping>
     <mapping>
       <address-pattern>sip:bob@.*</address-pattern>
       <app-name>termapp</app-name>
     </mapping>
   </terminating-region-mapping>

4.1.2 Precedence Rules

When there are multiple applications subscribed to within one region, then a precedence relationship among these applications can be specified using the <precedence> section as shown below.


<precedence>
  <terminating-region>
    <ordering>
      <app-name>app4</app-name>
      <app-name>app3</app-name>
    </ordering>
 </terminating-region>
  <originating-region>
    <ordering>
      <app-name>app1</app-name>
      <app-name>app2</app-name>
    </ordering>
 </originating-region>
</precedence>

The precedence relationship specifies the order of invocation for the applications within a region. For example, the above fragment from a approuter.xml file specifies that application app1 should be invoked before app2 in the originating region and app3 should be invoked before app4 in the terminating region. Note that the first application in the list for the originating side has the highest precedence and the last application in the list for the terminating side has the highest precedence. In either region, the application closest to the subscriber is specified as the first application and the application furthest from the subscriber is specified as the last application.