Home arrow Blog arrow Application Composition with the DFC-AR Part 2
Application Composition with the DFC-AR Part 2 Print
Written by Eric Cheung   

In part 2, we will look at what happens when the subscriber Bob cannot be reached, and Reroute Upon Failure application acts to reroute the call to an alternate destination.

First of all, we need to configure an alternate address for the Reroute upon Failure (RR) application. The test implementation available in the E4SS SDK provides a simple HTTP interface for this to be set.

> curl http://127.0.0.1:8080/rerouteUponFailureTest/set.jsp?altUser=Voicemail

Next, let's also configure Conditional Call Failure (CCF) to reject an INVITE request. This is akin to Bob wishes not to be disturbed, and turns Do-Not-Disturb on. Similarly, CCFTest provides a HTTP interface for setting this up. In this case, we will set it up to respond with 480 Temporary Unavailable response.

> curl http://127.0.0.1:8080/ccfTest/set.jsp?sc=480

Now when Alice calls Bob, the following happen:

1) RR is invoked as in part 1. It acts as a B2BUA and relays the INVITE request with the CONTINUE routing directive and without changing the Request-URI.

2) CCF is invoked next. This time, CCF acts as a UAS and responds with 480.

3) The response is received by RR. RE now tries the alternate destination. As in step 1, it relays the INVITE with the CONTINUE routing directive. But this time it modifies the user part of the Request-URI to Voicemail.

4) When the container invokes The DFC-AR, the DFC-AR knows that the current request is a continuation of a previous request in the terminating region. It also knows that the previous request was addressed to Bob, but the current request is addressed to Voicemail. Therefore, the DFC-AR stops selecting Bob's applications (NAT would have been the next one), and starts considering applications subscribed to by Voicemail. In this case, Voicemail does not subscribe to any applications, i.e. no mapping in approuter.xml matches Voicemail. Therefore DFC-AR returns null to the container, and the container sends the request externally.

As a second example, this time Bob wishes to delegate all calls to a colleague Carol in case he cannot answer. Carol also subscribes to the same three applications. We need to add the following to the <terminating-region-mapping> element in approuter.xml:

<mapping>
<address-pattern>sip:carol.*</address-pattern>
<app-name>/rerouteUponFailureTest</app-name>
</mapping>
<mapping>
<address-pattern>sip:carol.*</address-pattern>
<app-name>/ccfTest</app-name>
</mapping>
<mapping>
<address-pattern>sip:carol.*</address-pattern>
<app-name>/noAnswerTimeoutTest</app-name>
</mapping>

After approuter.xml is modified, you can undeploy and redeploy dfcar.jar so the new configuration is read in.

> asadmin undeploy dfcar
> asadmin deploy $EDK_HOME/lib/dfcar.jar

Let's disable CCF and exercise NAT this time by setting a no answer timeout value of 10 seconds. We will also set the alternative destination for RR to Carol:

> curl http://127.0.0.1:8080/ccfTest/set.jsp?sc=0
> curl http://127.0.0.1:8080/noAnswerTimeoutTest/set.jsp?timeoutMsec=10000
> curl http://127.0.0.1:8080/rerouteUponFailureTest/set.jsp?altUser=Carol

Now when Alice calls Bob, Bob's phone rings. If Bob does not pick up after 10 seconds, NAT kicks in and sends a CANCEL to Bob, and sends 480 response upstream. When RR receives the 480, the behavior is the same as before, except now the alternate destination is Carol.  When Carol picks up the call, the application chain will look like this:

In this example, we see that when an application continues a request but changes the subscriber address, the DFC-AR stops selecting the remaining applications for the original subscriber. Instead, it selects the applications for the new address.

Attentive readers may notice that if Carol also does not pick up after 10 seconds, Carol's NAT will act and send 480 response upstream, which will in turn trigger Carol's RR. But as the configured alternate destination is Carol, Carol will get the rerouted call again. This is only due to a limitation in the simple test implementation of RerouteUponFailureTest where it uses the same configuration for all subscribers. It is not a limitation of the SIP servlet API or E4SS. In the next and last part of the series, we will look at how an application can find out who its subscriber is in order to obtain configuration specific to the subscriber. We will also add an originating region application, and look at a feature interaction.

Discuss this article on the forums. (0 posts)

Last Updated ( Monday, 04 August 2008 )
 
< Prev   Next >
Copyright © 2006-2009 echarts.org