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

In this last part of the three part posting, we will add an application that is invoked to serve both the caller and the callee. We will also examine an interesting feature interaction and see how application precedence can help achieve the desired behavior.

Thus far all the applications we have encountered operate in the terminating region. RR, CCF and NAT are meaningful only when their subscriber is receiving a call. However, other applications may operate when their subscriber is the caller, and others may operate regardless of whether their subscriber is caller or caller. Let's consider the following example:

TalkTime: Limit the amount of time a subscriber can talk in a day. If there is no time credit remaining, reject the call at set up time. Otherwise, allow the call through but start deducting credit once the call is connected. If the credit is used up, tear down the call.

This may be a useful feature that parents subscribe for their teenage children so the youngsters won't spend all their time chatting to their friends. Clearly this application must be invoked when the subscriber is either placing or receiving a call. Otherwise, a clever teenager may subvert the limit by simply asking the other party to call back or vice versa.

The source code for TalkTime is included in the E4SS SDK. The following commands build and deploy a test implementation of the application:

> cd $EDK_HOME/features/talkTime/test
> ant fatsar
> asadmin deploy talkTimeTest.war 

Going back to the example of Alice and Bob, we will add TT for both of them. Put this approuter.xml to the SailFin <install_home>/domains/domain1/config/ directory, and redeploy the DFC-AR. Notice that the mapping section now has two new elements. Also notice the precedence of the applications in the terminating region:


The precedence specifies two orderings: RR-CCF-NAT, and RR-TT. Therefore, when all four applications are selected each of the following chain is valid -- RR-TT-CCF-NAT, RR-CCF-TT-NAT, and RR-CCF-NAT-TT. As we shall see below, only the precedence between RR and TT is important. The precedence between TT and CCF and NAT is not.

Now when Alice calls Bob, the container invokes the DFC-AR. As before, the DFC-AR determines that Alice is the caller. But unlike before, Alice now subscribes to TT. Therefore AR returns TT to the container.

Assuming that Alice's time is not used up, TT acts as a B2BUA and relays the INVITE request with the CONTINUE directive. The DFC-AR finds out that Alice has no more applications, moves into terminating region, finds out that the caller is Bob, and invokes Bob's applications in turn. In my run the chain looks like:

Next, let's set the time limits for Alice and Bob.  First, we will set Alice remaining credit to 0 while Bob still has one hour:

> curl ""
> curl ""

When the first instance of TT is selected, it is invoked in the Originating region to serve Alice. It can find out who the subscriber is by making the following API call in the doInvite() method:

URI subscriberURI = request.getSession().getSubscriberURI(); 

Therefore Alice's TT can find out that Alice's credit is 0, and rejects the call immediately. (The PFD version of JSR289 also adds request.getSubscriberURI(), but it is not implemented in SailFin yet.) TT may also find out that it is in the originating region by using getRegion() API call.

Let's see what happens if we set Alice's credit to one hour, but Bob's credit to 0. Let's also set an alternative address for Bob:

> curl ""
> curl ""
> curl 

This time, Alice's TT lets the call through. But Bob's TT rejects the call with 480 response. This triggers Bob's RR, which reroutes the call to Voicemail.

Note that the precedence between RR and TT is important. Because RR is invoked first and then TT, RR is in a position to reroute the call when TT rejects it. On the other hand, if the desired behavior is that when Bob has run out of credit, he cannot even receive voicemail or get his calls routed elsewhere, then we can reverse the precedence. This way, RR is not even in the application chain and thus cannot reroute the call.

In this blog post, several aspects of the JSR-289 API and the DFC-AR are illustrated:

  • Originating applications are inserted first, followed by terminating application.
  • Multiple instances of the same application may be invoked in the application chain. Each instance may find out whom it is serving by the getSubscriberURI() API call. If needed, it can also find out which region it is operating in. For example, when the time credit runs out, TT may want to connect the subscriber and the other party to a media server to play a voice prompt before dropping the call. As it is desirable that the subscriber hears a different prompt than the other party, TT needs to know whether the caller or callee is the subscriber.
  • Precedence affects how applications interact. By changing precedence relationships, different feature interaction may be achieved.

This concludes the three-party series on posting on application composition with the DFC-AR. For more information, see:
Getting Started with Application Routing
Getting Started with ECharts for SIP Servlets

And please post any comments or questions below!

Discuss this article on the forums. (0 posts)

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