Chapter 3. Design Overview

Example is created by three independent services which compose logical whole. CallBlocking, CallForwarding and VoiceMail process incoming INVITE request in sequence and make decision based on certain configurable conditions.

Top view of example components look as follows:

Call Controller2 Top overview of components

3.1. Call Controll Profile

Profile specification is JSLEE API to access non SBB data. It provides call controller services with required data to make decision how call should look like. Structure of profile data look as follows:

Call Controller2 Profile Specification

Table 3.1. Call Controller2 Profile attributes

Name	Type	Description
userAddress	javax.slee.Address	Determines AOR(address of record) of profile owner.
blockedAddresses	javax.slee.Address[]	Set of addresses blocked for profile owner. Calls originating from one of those should be blocked.
backupAddress	javax.slee.Address	Backup address to which call should be forwarded
voicemailState	boolean	Determines if user has enabled voice mail service, `true` indicates enabled voice mail.

Note

Addresses stored in profiles are AORs - that is logical addresses of user present in From and To headers for instance. Example AOR : sip:newbie@mobicents.org..

3.1.1. Profile default data

Profile table for Call Controller2 is "Controller"

Table 3.2. Call Controller2 Profile default values

Profile Name	User Address	Blocked Addresses	Backup Address	Voice Mail State
torosvi	SIP:sip:torosvi@ b127.0.0.1	{SIP:sip:mobicents@ 127.0.0.1, SIP:sip:hugo@ 127.0.0.1}	null	true
mobicents	SIP:sip:mobicents@ 127.0.0.1	null	null	false
victor	SIP:sip:victor@ 127.0.0.1	null	SIP:sip:torosvi@ 127.0.0.1	false
vhros2	SIP:sip:vhros2@ 127.0.0.1	null	null	true
vmail	SIP:sip:vmail@ 127.0.0.1	null	null	true

Important

Spaces where introduced in address type field column values, to correctly render the table. Please remove them when using copy/paste.

Note

Prefix SIP: comes from JSLEE addressing scheme.

3.2. ACI variable aliasing and service composition

Call control services act independently from each other. New services can be inserted into chain without modifying source code of existing pieces.

Chain of services is built with service priority feature of JSLEE:

Call Controller2 Message routing

Service priority determines order by which services are chosen to receive the same event. However JLSEE services are independent entities, that is, each has separate state associated with incoming message. To indicate that event has been consumed and must not be processed anymore services need to share information. This is done with ACI variable aliasing. It allows to share data stored in ACI variable

Aliasing scheme used by this example look as follows:

Call Controller2 Aliasing overview

Important

Aliased ACI variables must be of same, serializable type. However alias name must be distinct

Note

There is no limitation on how many variables and ACIs pairs can be aliased, ie. three ACI can share the same variable.

Aliases are created on custom ACI variables. Custom ACI and aliases are defined in sbb-jar.xml as follow:




    <sbb>

        <description />

        <sbb-name>CallBlockingSbb</sbb-name>

        <sbb-vendor>org.mobicents</sbb-vendor>

        <sbb-version>0.1</sbb-version>



        

        

        <sbb-classes>

            ...

            <sbb-activity-context-interface>

                <sbb-activity-context-interface-name>

                    org.mobicents.slee.examples.callcontrol.blocking.CallBlockingSbbActivityContextInterface

                </sbb-activity-context-interface-name>

            </sbb-activity-context-interface>

        </sbb-classes>

         

         ....

         

        <activity-context-attribute-alias>

            <attribute-alias-name>inviteFilteredByCallBlocking</attribute-alias-name>

            <sbb-activity-context-attribute-name>filteredByMe</sbb-activity-context-attribute-name>

        </activity-context-attribute-alias>

        

    </sbb>

    <sbb>

        <description />

        <sbb-name>CallForwardingSbb</sbb-name>

        <sbb-vendor>org.mobicents</sbb-vendor>

        <sbb-version>0.1</sbb-version>



        

        <sbb-classes>

            <sbb-abstract-class>

                ...

            <sbb-activity-context-interface>

                <sbb-activity-context-interface-name>

                    org.mobicents.slee.examples.callcontrol.forwarding.CallForwardingSbbActivityContextInterface

                </sbb-activity-context-interface-name>

            </sbb-activity-context-interface>

        </sbb-classes>

        

        

        <activity-context-attribute-alias>

            <attribute-alias-name>inviteFilteredByCallBlocking</attribute-alias-name>

            <sbb-activity-context-attribute-name>filteredByAncestor</sbb-activity-context-attribute-name>

        </activity-context-attribute-alias>

        <activity-context-attribute-alias>

            <attribute-alias-name>inviteFilteredByCallForwarding</attribute-alias-name>

            <sbb-activity-context-attribute-name>filteredByMe</sbb-activity-context-attribute-name>

        </activity-context-attribute-alias>

        

    </sbb>

Source definition of ACI and variable accessors look as follows:



public interface CallBlockingSbbActivityContextInterface 

    extends javax.slee.ActivityContextInterface {

    public void setFilteredByMe(boolean val);

    public boolean getFilteredByMe();

}



public interface CallForwardingSbbActivityContextInterface 

    extends javax.slee.ActivityContextInterface {

    public boolean getFilteredByAncestor();

    public void setFilteredByMe(boolean val);

    public boolean getFilteredByMe();

}