Home arrow Blog arrow Proxy Application Support
Proxy Application Support Print
Written by Tom Smith   
The state-based approach of ECharts makes it very well-suited to back-to-back user agent (B2BUA) applications.  With the introduction of the SIP Servlet Application Router, multiple applications can be composed to get rich service behavior.  Often it is beneficial to compose proxy applications with B2BUA applications.  Our framework provides a mechanism for creating proxy applications (that are not based on state machines) and composing them with ECharts B2BUA applications.

B2BUA applications can be difficult to develop, with the need to maintain dialog state for multiple SIP dialogs as well as application state. That is why the state machine approach of ECharts is so powerful for these applications. But to provide good application modularity, it is good practice to separate concerns when possible.  Consider an application that will interrupt calls after a preset time to tell your teenager to get back to homework. You may want this to apply to calls to his main number and also to any number that he may forward his calls to.

In this case, it is natural to have two separate applications: a HomeworkReminder (B2BUA) application and a CallForwarding (Proxy) application.  HomeworkReminder is created using ECharts machines.  The initial state might look like this:

initial state PLACE_CALL : B2buaFSM(box, caller, callee, null); 

Note that the last argument to the B2buaFSM machine is a null RequestModifier. This means that the application is not applying any changes to the outgoing INVITE, and that the application router will simply CONTINUE the call.

In contrast, the only function of the CallForwarding application is to (conditionally) change the outgoing INVITE. This can be done by subclassing EChartsProxyServlet, as shown here:

public class CallForwardingProxyServlet extends EChartsProxyServlet {
     public URI specifyRequestURI(SipServletRequest req) {
         if( !isForwardingOn ) return null; // no change

         URI newURI = (URI) req.getRequestURI().clone();
         ...
         return newURI;
     }
}

The EChartsProxyServlet will apply the results of specifyRequestURI and invoke the application router to CONTINUE the call with the new Request-URI.

The appgen tool can be used to create both B2BUA and proxy application skeletons. The sip.xml deployment descriptors created by this tool will contain a special matching rule used by the application router in order to route calls to the proper application in the proper order. The desired order is specified in approuter.xml, as shown below. (See approuter.sample.xml in the ECharts Development Kit for more details on file format.)

...
    <precedence>
        <terminating-region>
            <ordering>
                <!-- apps listed higher will get applied
                     later in the terminating region -->
                <app-name>callForwarding</app-name>
                <app-name>homeworkReminder</app-name>
            </ordering>
        </terminating-region>
    </precedence>
...
    <application-mapping>
        <terminating-region-mapping>
            <mapping>
                <address-pattern>sip:1\d{10}@.*</address-pattern>
                <app-name>callForwarding</app-name>
            </mapping>
            <mapping>
                <address-pattern>sip:1\d{10}@.*</address-pattern>
                <app-name>homeworkReminder</app-name>
            </mapping>
        </terminating-region-mapping>
    </application-mapping>
...

This assumes that callForwarding and homeworkReminder were the last components of the package names provided to appgen.

Note that if HomeworkReminder sends an INVITE to a Request-URI that does not have a userpart which is 1 followed by 10 digits (as may be the case if sending an INVITE to a media server), then the application router will not route the call to the CallForwarding application.

By using the SIP Servlet application router to compose multiple applications, it becomes easier to create modular applications which can be reused in different contexts. In particular, it is often good practice to separate call routing functions into their own proxy applications. Our framework allows such proxy applications to be easily integrated with other applications to provide rich services.

Discuss this article on the forums. (0 posts)
Last Updated ( Tuesday, 05 February 2008 )
 
< Prev   Next >
Copyright © 2006-2009 echarts.org