JBoss.orgCommunity Documentation
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
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. |
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..
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 |
Spaces where introduced in address type field
column values, to correctly render the table. Please remove them when using copy/paste.
Prefix SIP:
comes from JSLEE addressing scheme.
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
Aliased ACI variables must be of same, serializable type. However alias name must be distinct
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();
}
Call blocking service purpose is to block incoming calls based on data stored in call controll2 profile. It is first service to receive incoming SIP INVITE request.
Flow diagram for call blocking look as follows:
Call Controller2 Blocking Service flow
Call forwarding purpose is to simply forward call to callees backup address in case main is not available.
It is second service to receive incoming SIP INVITE request. Call forwarding service relies on sip-services proxy to route messages to proper destination UA.
Flow diagram for call forwarding look as follows:
Call Controller2 Forwarding Service flow
Voice mail purpose is to store voice message and play it back when callee requests it.
It is the last to receive incoming SIP INVITE request.
Voice mail service is most complicated service of Call Controller2. It carries on task of communicating with SIP UA and media server. That includes SDP negotiation procedures and media server primitives handling.
Users accesse voice mail box by calling
sip:vmail@mobicents.org
.
Flow diagram for voice mail look as follows:
Call Controller2 Voice Mail Service playback flow
Voice mail must create media session and establish media path in media server in order to perform its function.
Media path is created in media server with connections
and endpoints
(for explanation of acronyms and capabilities please refer to Mobicents Media Server Documentation
)
Path is composed as follows:
Call Controller2 Media Path
For details of creating media session please refer to RFC4566