Bartosz Baranowski - blog

SNMP enabled SLEE !!!

2011-11-08T08:35:00.000-08:00

Sometimes ago we had brainstorm session during regular SLEE core chat. Community users shed some light on real use cases and their expectations with regard to management of live system.

It came out that simple JMX is sometimes not enough. Especially for deployment where some existing third party management tool/application is running.

Community users directed us in direction of SNMP. It came out that some of them tried to enable our containers (or even JBoss) to allow SNMP management, without much luck. So we decided to step in.

Sometime ago Jean Deruelle and Tom Hauser made an effort to bring back JBoss SNMP adaptor. Main goal of their work was to:

add SNMP V3 support
add MIB files generator
update adaptor code to AS5
update adaptor code to use netsnmp4j library

Fruit of their work has been embeded in last MSS release, in MSS-1.6. The 1.6 is first SNMP enabled container from Mobicents family. Documentation for binary adaptor included in MSS can be found here.

Note that this documentation will change in near future.

Source

While first draft (Alpha1) of adaptor and MIB generator were fine for test, it turned out that releasing its source code as binary maven artifact proven to be a problem. So we decided to rework it a bit to be more logical in both structure and deploy process.

Current source can be found here, along with simple example.

Version 2 source can be found here and here. (This may change, I will update post if it does. Proposed source is currently attached to issue.)

Basics

SNMP is a simple network management protocol(though its defined in ASN.1). In general SNMP is used to monitor network devices in order to perform two things:

monitor and set configuration parameters
monitor state of devices in hope(or not) to receive notification about condition which requires administrative actions

Detailed protocol description can be found here.

SNMP identifies devices by using something called M.I.B. . In short MIB is a way of organizing resources. MIB has tree like structure, where each root has non-negative index. Resources in MIB are identified by concatenation of indexes which lead to particular node. Example URI looks as follows: 1.0.12.4124.66.8365

This URI, has a specific name, which is object identifiers or , in short the OID.

OIDs are managed by IANA. The IANA OID registry contains a list of registered entities that use OIDs to reference internal structures (e.g. directory attributes). Each entity is assigned an initial referential value (e.g. 1.3.6.1.4.1.2312 for Red Hat, see http://www.oid-info.com/get/1.3.6.1.4.1.2312) and thereafter the internal numbering plan is up to the entity to define (e.g. 1.3.6.1.4.1.2312.100.1.1 might refer to the "ActiveThreadCount" attribute of the JBoss Application Sever). This allows for precise referencing of data attributes in a company or other entity.

This is very important. It means that OIDs, inside of company/entity leaf of MIB are managed solely by that company/entity. In other words, resources from the same company, have the same referential value and rest can be freely assigned - depening on whim of administrator.

He can for instance decide that following OIDs have :

RedHat : 1.3.6.1.4.1.2312
RedHat US : 1.3.6.1.4.1.2312.0
RedHat US Office 4 : 1.3.6.1.4.1.2312.0.4
Office 4 JSLEE : 1.3.6.1.4.1.2312.0.4.1
Office 4 JSLEE Server 1 : 1.3.6.1.4.1.2312.0.4.1.1
Office 4 JSLEE Server 2 : 1.3.6.1.4.1.2312.0.4.1.2
Office 4 MSS Server 1 : 1.3.6.1.4.1.2312.0.4.2.1
Office 4 MSS Server 2 : 1.3.6.1.4.1.2312.0.4.2.2

SNMP managed attributes are identified by MIB entries. Each MIB entry has type associated to it. For instance, lets go through the "ActiveThreadCount":

1.3.6.1.4.1.2312 identifies RedHat(OID type)
1.3.6.1.4.1.2312.100 identifies JBoss appliaction server(OID type)
1.3.6.1.4.1.2312.100.1 identifies MBean(OID type)
1.3.6.1.4.1.2312.100.1.1 identifies MBean property, which can be managed with SNMP(Integer32 type)

Detailed information about Management Information Base can be found here.

The playground

For this exercise I used single Ubuntu machine. It is possible to use windows, however it has to be 32bit. This limitation exists due to SNMP manager does not support 64bit.

Lets advance step by step with proper setup.

First thing that needs to be addressed are the dependencies for SNMP implementation. Since I had desktop version of Ubuntu (10+) , only dependency I had to install was lib-perldev

baranowb@port3:~/tmp$ sudo apt-get install libperl-dev

Once dependency is there, we can install SNMP program/daemon. Since there is no precompiled package(and version 5.7 seems to be broken) I went for net-snmp v 5.6.1.1. To get it simply download source(unless there is package now or there is package for your OS):

baranowb@port3:~/tmp$ wget http://sourceforge.net/projects/net-snmp/files/net-snmp/5.6.1/net-snmp-5.6.1.1.tar.gz

Unpack:

baranowb@port3:~/tmp$ tar -xvzf net-snmp-5.6.1.1.tar.gz

Configure source build:

baranowb@port3:~/tmp$ cd net-snmp-5.6.1.1
baranowb@port3:~/tmp/net-snmp-5.6.1.1$ ./configure

This will run configure script. It will scan OS for all dependencies. Once it is done, it will ask few questions, like location, adminitrator contact, log files folder etc.

To avoid questioning, you can pass answer as invocation arguments like:

baranowb@port3:~/tmp/net-snmp-5.6.1.1$ ./configure --with-default-snmp-version="3" --with-sys-contact="alice@mobicents.org" --with-sys-location="DMZ" 
--with-logfile="/var/log/snmpd.log" --with-persistent-directory="/var/net-snmp

Once script has completed its execution, it should show frame similar to one below:

---------------------------------------------------------
            Net-SNMP configuration summary:
---------------------------------------------------------

  SNMP Versions Supported:    1 2c 3
  Building for:               linux
  Net-SNMP Version:           5.6.1.1
  Network transport support:  Callback Unix Alias TCP UDP IPv4Base SocketBase TCPBase UDPIPv4Base UDPBase
  SNMPv3 Security Modules:     usm
  Agent MIB code:             default_modules =>  snmpv3mibs mibII ucd_snmp notification notification-log-mib target 
agent_mibs agentx disman/event disman/schedule utilities host
  MYSQL Trap Logging:         unavailable
  Embedded Perl support:      enabled
  SNMP Perl modules:          building -- embeddable
  SNMP Python modules:        disabled
  Crypto support from:        internal
  Authentication support:     MD5 SHA1
  Encryption support:         DES AES

---------------------------------------------------------

This indicates that source can be build. To do so, issue following command:

baranowb@port3:~/tmp/net-snmp-5.6.1.1$ make

Once compilation sequence is done, SNMP binary is ready to be installed:

baranowb@port3:~/tmp/net-snmp-5.6.1.1$ sudo make install

Now we are almost ready to have SNMP run. Last step before SNMP configuration magic is to expose *.so objects. Either link libraries to proper place, or add /usr/local/lib to LD_LIBRARY_PATH. However, if you do the latter, remember, that SNMP programs must run with SU privileges(or specific group).

On my machine, dependencies looked as follows:

baranowb@port3:/usr/local/sbin$ ldd snmptrapd 
 linux-vdso.so.1 =>  (0x00007fffcefe0000)
 libnetsnmptrapd.so.25 => /usr/local/lib/libnetsnmptrapd.so.25 (0x00007f5400fcf000)
 libnetsnmpmibs.so.25 => /usr/local/lib/libnetsnmpmibs.so.25 (0x00007f5400c35000)
 libnetsnmpagent.so.25 => /usr/local/lib/libnetsnmpagent.so.25 (0x00007f54009cf000)
 libnetsnmp.so.25 => /usr/local/lib/libnetsnmp.so.25 (0x00007f54006e7000)
 libperl.so.5.10 => /usr/lib/libperl.so.5.10 (0x00007f540035f000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f540015a000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f53ffed5000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f53ffcb7000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f53ff922000)
 libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f53ff6e9000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f54011dc000)

To verify if everything is properly setup, try following:

baranowb@port3:/usr/local/sbin$ snmptrapd  --version
NET-SNMP Version:  5.6.1.1
Web:               http://www.net-snmp.org/
Email:             net-snmp-coders@lists.sourceforge.net

Now what we need is JBoss, SLEE, adaptor and some specific setup. To get JBoss go here and download proper version. To get SLEE up and running, follow instructions found here(or simply download binary release from here.)

Once SLEE is up and you ensure it can run, it's time to brew some notifications from SLEE. By default SLEE emits notifications on following:

SLEE container state changes
alarm is beeing emited

Obviously, the first one is useful kind, however lets add some complexity to this exercise and brew some alarm. To emit alarm, I would advise to create simple Service with single SBB, which on ServiceStartedEvent and possibly on ActivityEndEvent(service activity) will raise alarm. In my test I processed only ServiceStartedEvent. My SBB looks as follows:

package test;
import javax.slee.*;
import org.mobicents.slee.SbbContextExt;
public abstract class AlarmExampleSbb implements javax.slee.Sbb {


public void onServiceStartedEvent(ServiceStartedEvent event, ActivityContextInterface aci) {
  sbbContext.getTracer(getClass().getSimpleName()).warning("Service activated, now rising alarm.");
  this.sbbContext.getAlarmFacility().raiseAlarm("ImportantAlarm", ""+this.sbbContext.getSbb(), AlarmLevel.INDETERMINATE, "Im just alarming, cause I've been started", new IllegalSelectorException());
 }
public void setSbbContext(SbbContext context) {
  sbbContext = (SbbContextExt) context;
 }
public void unsetSbbContext() {
  this.sbbContext = null;
 }

public void sbbCreate() throws javax.slee.CreateException {}
 public void sbbPostCreate() throws javax.slee.CreateException {}
 public void sbbActivate() {}
 public void sbbPassivate() {}
 public void sbbRemove() {}
 public void sbbLoad() {}
 public void sbbStore() {}
 public void sbbExceptionThrown(Exception exception, Object event, ActivityContextInterface activity) {}
 public void sbbRolledBack(RolledBackContext context) {}
private SbbContextExt sbbContext; // This SBB's SbbContext
}

The SBB descriptor is very simple, it looks as follows:


    
        SNMPTest
        org.mobicents
        1.0
     
        
            
                test.AlarmExampleSbb
            
        
        
        
      ServiceStartedEvent
    
        
   javax.slee.serviceactivity.ServiceStartedEvent
        
        javax.slee
        1.1

However to kickstart everything as fast as possible, you could simply edit one of existing examples, like sip-uas.

SNMP and MIB magic

Above concludes steps on SLEE side, atleast for simple setup. Now SNMP adaptor has to be configured. For this I did not use current trunk, nor I did use binary version. This is because trunk version had some errors(fixed already) in poms . On top of that there have been some MSS modifications in configuration files. Which rendered that source a bit useless outside MSS. After sometime I just decided to go highway and hack around/fix that.

Reason against binary version available from jboss wiki is that it.... was wrong, for some reason it had bad version linked(should be fixed shortly).

Ok, to get it running, simply download source from our repository(links at the beginning of this article) or get it from patches. This source is pure JBoss SNMP adaptor, it has no setup ready for SLEE. This is our task now, to bring this up to speed.

For sake of beeing complete, in step by step setup, I will explain how to modify this source to enable SLEE. In general case, you would use preset that we have for SLEE. I will write simple article about setup in following days.

Now, first thing we need to do, is to identify resources we want to expose, resources that can be exposed to SNMP management. In JSLEE we have few sets of MBeans present for management purposes.
That is:

javax.slee.management.* - all standard MBeans
org.mobicents - mobicents specific MBeans

Now, we need to identify one weakness in SNMP - it allows to manage configuration, that is access and set value of MBean attributes. It does not allow to invoke methods like "clearAlarms(String type);". So by default, without some hack, we will be able to manage limited subset of SLEE configuration. However it should be enough for a jump start.

First thing that has to be done before we can create config files for adaptor is to come up with MIB scheme.

Obviously we should reuse RedHat referential value: "1.3.6.1.4.1.2312". Our MIBs will start with this prefix. For sake of simplicity, lets assume we dont have to divide MIB to provide distinction between countries, offices, buildings etc. In other word we have flat MIB space. Now lets assume following:

.1.3.6.1.4.1.2312.101 - identifies Mobicents/JBCP
.1.3.6.1.4.1.2312.101.1 - indentifies server 1
.1.3.6.1.4.1.2312.101.1.100 - identifies MBeans from javax.slee.management group
.1.3.6.1.4.1.2312.101.1.200 - identifies MBeans from org.mobicents group
.1.3.6.1.4.1.2312.101.1.300 - identifies MBeans specific for deployed application(if ever used)

Having above in mind, we can create 'attributes.xml' which suits our needs - that is to expose SLEE information. Lets assume we are good with Alarm and Platform information. So, lets define the file:

Now lets examine the file. We have definition of two MBeans. Each mbean entry has following:

name - this attribute identifies MBean, it has to map to specific MBean or set(in case name contains wildcards)
oid-prefix - the OID assocaited with this MBean or MBean set
definition-name - human readable name. It can be used to avoid using oid-prefix in command line queries

Each mbean element has child elements of type attribute. Child has following type of atrributes:

name - name of MBean attribute. It maps directly to getter/setter - follow java bean attributes pattern.
oid - oid suffix which will be appended to oid-prefix. In case of array/collection types, indended value has to be appended with '.1'. For instance SleeState can have oid='.1', but Subsystems will have oid='.5.1'.
mode and max-access (reduntant, I know, this should be cleared in next source iteration) - determine type of attribute access mode=[ro|rw] and max-access=[read-only, read-write]
snmp-type - indicates type of attribute, check ASN.1 types( OCTET STRING, BIT STRING, etc...)

Above code snippet defines two MBeans as MIB accessible resources. For SleeManagement MBean it resrves OID='.1.3.6.1.4.1.2312.101.1.100.1' and for Alarm it reserves OID='.1.3.6.1.4.1.2312.101.1.100.2'. There is nothing special about this setup, so lets move to notifications.

One very important limitation, is that notification can be mapped only to resource already existing in MIB. In short, there has to be definition of resource in 'attributes.xml' in order to have definition of notification.

Lets assume we want to receive SNMP trap/info for all SLEE basic notifications. So we want to map notification from SleeManagement and Alarm MBeans. This can be achieved with following:

Notification mapping file is not hard to understand. Each mapping has following attributes:

name - name identifying this entry, in general it should match 'definition-name'
notification-type - regular expression which should find match in Notification.getType() value
enterprise - the OID, it MUST match oid-prefix of MBean in 'attributes.xml'
generic and specific - SNMP metadata, check this for explanation.
inform - optional boolean attribute, if present and set to true, notification is converted to SNMP inform, not trap
security-name - name of user to match entry in 'users.xml'

What is interesting is defined in mbean child elements. The var-bind-list declares actual binding of notification data to SNMP world. The var-bind-list has single attribute, the wrapper-class. This attribute must be set to class name of a class which implements org.jboss.jmx.adaptor.snmp.agent.NotificationWrapper ( by default its org.jboss.jmx.adaptor.snmp.agent.NotificationWrapperSupport ). Default class handles conversion of common notification data. It binds following data to tag( tag is a logical name, its similar in meanig to association-name):

Tag	Description
n:message	javax.management.Notification.getMessage()
n:sequenceNumber	javax.management.Notification.getSequenceNumber()
n:timeStamp	javax.management.Notification.getTimestamp()
n:type	javax.management.Notification.getType()
n:all	javax.management.Notification.toString()
n:class	javax.management.Notification.getClass().getName()
a:startTime	snmp agent/adaptor start time
a:uptime	snmp agent/adaptor up time
a:trapCount	snmp agent/adaptor trap count
u:	looked-up in n.getUserData()

Non standard binding can be defined as child elements of var-bind-list as var-bind. Each var-bind element creates binding for some attribute. The binding has following data which describes it:

oid - full OID identifying this variable. (NOTE: compare OID of bindings, to enterprise value and value of oid-prefix of MBean definition in attributes.xml)
tag - logical name of binding. It follows pattern [a|u|n]:beanAttributeName
type - ASN.1/SNMP data type

The tag value (beanAttributeName) is in general name of attribute(follows java bean convention).

Now depending on tag prefix, name has different meaning:

a - following name must be a name of MBean attribute. The oid MUST match one defined in attributes.xml.
u - the prefix:name is looked up in Notification.getUserData() (only in case it contains java.util.Map instance) and copied to payload. For this type of tag, the oid must not have to match existing attribute, MIB entry with this OID will be created( by generator )
n - name following this prefix must be a valid java bean attribute of notification class. As in case of u the OID must not match existing attribute.

Now what is interesting in above example, is that it does not use standard wrapper-class and defines some non standard var-binds. Lets see how custom wrapper handles conversion:

package org.mobicents.slee.tools.snmp;

import javax.management.Notification;
import javax.slee.management.AlarmNotification;

import org.jboss.jmx.adaptor.snmp.agent.NotificationWrapperSupport;
/**
 * Simple implementation of wrapper support. It fetches all data from Alarm notification and encodes it as
 * @author baranowb
 *
 */
public class AlarmNotificationWrapperSupport extends NotificationWrapperSupport {

 // Agent properties
 public static final String NOTIFICATION_SRC_TAG = "n:source";
 public static final String ALARM_LEVEL_TAG = "n:level";
 public static final String INSTANCE_ID_TAG = "n:instanceId";
 public static final String ALARM_ID_TAG = "n:id";
 public static final String ALARM_TYPE_TAG = "n:type";
 
   
 
 public AlarmNotificationWrapperSupport() {
  // TODO Auto-generated constructor stub
 }

 @Override
 public void prime(Notification n) {
  if( !(n instanceof AlarmNotification) )
  {
   throw new IllegalArgumentException("Wrong type of notification!");
  }
  //trigger super, so it puts all the data...
  super.prime(n);
  //now put our specific data
  AlarmNotification an = (AlarmNotification) n;
  //remember, we may get v1 alarms... which dont have certain fields!
  //simply divide... this will bring less chaos!
  
  //current version of adaptor does not clean payload...
  super.payload.remove(NOTIFICATION_SRC_TAG);
  super.payload.remove(ALARM_LEVEL_TAG);
  super.payload.remove(INSTANCE_ID_TAG);
  super.payload.remove(ALARM_ID_TAG);
  super.payload.remove(ALARM_TYPE_TAG);
  
  if(an.getNotificationSource()==null)
  {
   //1.0 - it does not set NS, however 1.1 alarm sets alarmSource to NS!
   super.payload.put(NOTIFICATION_SRC_TAG, an.getAlarmSource().toString());
   super.payload.put(ALARM_LEVEL_TAG, an.getLevel().toString());
  }else
  {
   //1.1
   super.payload.put(NOTIFICATION_SRC_TAG, an.getNotificationSource().toString());
   super.payload.put(ALARM_LEVEL_TAG, an.getAlarmLevel().toString());
   super.payload.put(INSTANCE_ID_TAG, an.getInstanceID());
   super.payload.put(ALARM_ID_TAG, an.getAlarmID());
  }
  
  //common part.
  super.payload.put(ALARM_TYPE_TAG, an.getAlarmType());
  if(an.getCause()!=null)
  {
   //TODO: add throwable conversion ?
  }

 }
}

Having our magic classes and configuration files ready, we can start thinking on proper deployment.
First thing is to build mib-gen( the dev version has artifacts version set to 5.1.1-SNAPSHOT).
Change directory to snmp-mibgen(or whatever it is called localy) and simply issue maven order:

baranowb@port3:~/workspace/snmp-mibgen$ mvn install
[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   SNMP MIB Parent
[INFO]   MIB Generator
[INFO]   MIB Generator Maven Plugin
[INFO] ------------------------------------------------------------------------
[INFO] Building SNMP MIB Parent
[INFO]    task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing /home/baranowb/workspace/snmp-mibgen/pom.xml to /home/baranowb/.m2/repository/org/jboss/jbossas/snmp/mib/parent/5.1.1-SNAPSHOT/parent-5.1.1-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] Building MIB Generator
[INFO]    task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
...
[INFO] ------------------------------------------------------------------------
[INFO] Building MIB Generator Maven Plugin
[INFO]    task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [plugin:descriptor {execution: default-descriptor}]
...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] SNMP MIB Parent ....................................... SUCCESS [1.591s]
[INFO] MIB Generator ......................................... SUCCESS [5.658s]
[INFO] MIB Generator Maven Plugin ............................ SUCCESS [1.973s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9 seconds
[INFO] Finished at: Tue Nov 08 16:11:25 CET 2011
[INFO] Final Memory: 46M/578M
[INFO] ------------------------------------------------------------------------

Once maven is done. Switch to snmp-adaptor directory and edit notifications.xml and attributes.xml files. Put there snippets outlined above. Those files can be found in snmp-adaptor/adaptor-service/src/main/resources.

Last thing you need to do, is to edit jboss-service.xml to instruct adaptor how to behave. Edit this file, search for following snippet:

Edit it and append following declaration:

This will instruct Adapter to do following:

try to register to declared MBeans as NotificationListener
if DynamicSubscriptions attribute is set to true, it will will try to register as NotificationListener once declared MBeans are available

One important remark here, note that there is notification element. It has attribute type. This attribute value is used as filter for notification. Important thing here is that its not matched as regular expression. The pseudo code for this operation looks as:

boolean doesMatch(Notification n)
{
  
    return  n.getType().startsWith(${notification.type});

}

Having done above, we can generate MIB, build adaptor deployment unit and start to play SNMP.
To do so, simply issue maven order in snmp-adaptor directory (note that JBOSS_HOME) has to be defined. Output should look similar to one below(it deploys deployer, but we dont care for it now):

baranowb@port3:~/workspace/snmp-adaptor$ mvn install
[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   SNMP Adaptor Parent
[INFO]   SNMP Adaptor Core
[INFO]   SNMP Adaptor Service
[INFO]   SNMP Deployer Core
[INFO]   SNMP Deployer Service
...
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [:generate-mib {execution: default}]
[INFO] Generating MIB from attributes file = /home/baranowb/workspace/snmp-adaptor/adaptor-service/src/main/resources/attributes.xml and notifications file = /home/baranowb/workspace/snmp-adaptor/adaptor-service/src/main/resources/notifications.xml
[INFO] Parsing...
[INFO] Writing file /home/baranowb/workspace/snmp-adaptor/adaptor-service/target/classes/adaptor.mib...
...
    [unjar] Expanding: /home/baranowb/workspace/snmp-adaptor/adaptor-service/target/adaptor-service-5.1.1-SNAPSHOT-sar.jar into /home/baranowb/servers/jboss-5.1.0.GA/server/default/deploy/snmp-adaptor.sar
...
[INFO] 
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] SNMP Adaptor Parent ................................... SUCCESS [1.340s]
[INFO] SNMP Adaptor Core ..................................... SUCCESS [3.153s]
[INFO] SNMP Adaptor Service .................................. SUCCESS [2.162s]
[INFO] SNMP Deployer Core .................................... SUCCESS [0.977s]
[INFO] SNMP Deployer Service ................................. SUCCESS [0.231s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8 seconds
[INFO] Finished at: Tue Nov 08 16:52:59 CET 2011
[INFO] Final Memory: 57M/581M
[INFO] ------------------------------------------------------------------------

Receiving traps

Once above completes we are ready to play with SNMP. That is if assumption that default users/managers are fine with setup, but since we will use single machine, it should. To receive traps, we have to configure SNMP tool(net-snmp).

First login as super user. Than create user:

net-snmp-config --create-snmpv3-user -a maplesyrup TEST

Note that above values match default user present in adapter configuration file users.xml .
Once above completes, edit snmptrapd.conf:

gedit /etc/snmp/snmptrapd.conf

Add following entries:

#User to receive TRAP
createUser -e 0x80001370017F000101 TEST MD5 maplesyrup DES maplesyrup
#Those make snmptrapd log the TRAPs and INFORM to the console
authUser log,execute,net TEST

The hex value in above snippet is ENGINEID. For me it did not change. If you need to double check, see what is written to /var/net-snmp/snmptrapd.conf file. (Note: for some reason, snmp tool did not use config files from /etc directory. I had to edit /root/.snmp/snmptrapd.conf) .

Having done above ,there is one final step that needs to be taken. We need to copy MIB file. It is located in $JBOSS_HOME/server/default/deploy/snmp-adaptor.sar directory.
First check where MIB should be stored, by issuing following command:



net-snmp-config --default-mibdirs

I had to copy MIB files to /root/.snmp/mibs, so my directory structure looked as follows:

root@port3:~/.snmp# ll -R
.:
total 20
drwxr-xr-x  3 root root 4096 2011-10-27 09:54 ./
drwx------ 12 root root 4096 2011-11-04 16:54 ../
drwxr-xr-x  2 root root 4096 2011-10-27 15:53 mibs/
-rw-r--r--  1 root root  216 2011-10-27 09:54 snmp.conf
-rw-r--r--  1 root root  544 2011-10-27 09:54 snmptrapd.conf
./mibs:
total 16
drwxr-xr-x 2 root root 4096 2011-10-27 15:53 ./
drwxr-xr-x 3 root root 4096 2011-10-27 09:54 ../
-rw-r--r-- 1 root root 4217 2011-11-02 13:07 mobicents-slee.mib

Now we are ready to fire up the daemon. If everything is setup properly we can execute following(and see similar output):

root@port3:~/.snmp# snmptrapd -f -Lo -Dusm
registered debug token usm, 1
usmUser: created a new user TEST at 80 00 13 70 01 7F 00 01 01 
NET-SNMP version 5.6.1.1

Now we can start JSLEE container:

baranowb@port3:~/# cd $JBOSS_HOME; bin/run.sh -b 127.0.0.1 | tee console.log

Once container starts, we can deploy example service and observe SNMP daemon output. For me it looked similar to following:

2011-10-28 08:48:05 localhost [UDP: [127.0.0.1]:1161->[127.0.0.1]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (16179) 0:02:41.79 SNMPv2-MIB::snmpTrapOID.0 = OID: SLEE-MIB::jbossJmxNotificationOldState.0.10 SLEE-MIB::jbossJmxNotificationOldState = STRING: "Stopped" SLEE-MIB::jbossJmxNotificationNewState = STRING: "Starting"
usm: USM processing begun...
usm: match on user TEST
usm: Verification succeeded.
usm: USM processing completed.
2011-10-28 08:48:05 localhost [UDP: [127.0.0.1]:1161->[127.0.0.1]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (17188) 0:02:51.88 SNMPv2-MIB::snmpTrapOID.0 = OID: SLEE-MIB::jbossJmxNotificationSource.0.11 SLEE-MIB::jbossJmxNotificationSource = STRING: "SbbNotification[service=ServiceID[name=SNMPTestService,vendor=org.mobicents,version=1.0],sbb=SbbID[name=SNMPTest,vendor=org.mobicents,version=1.0]]" SLEE-MIB::jbossJmxNotificationLevel = STRING: "Indeterminate" SLEE-MIB::jbossJmxNotificationInstanceId = STRING: "SbbID[name=SNMPTest,vendor=org.mobicents,version=1.0]" SLEE-MIB::jbossJmxNotificationId = STRING: "9e4ebf6e-9821-4b48-98d1-d77a596e5da4" SLEE-MIB::jbossJmxNotificationType = STRING: "ImportantAlarm"
usm: USM processing begun...
usm: match on user TEST
usm: Verification succeeded.
usm: USM processing completed.
2011-10-28 08:48:06 localhost [UDP: [127.0.0.1]:1161->[127.0.0.1]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (18124) 0:03:01.24 SNMPv2-MIB::snmpTrapOID.0 = OID: SLEE-MIB::jbossJmxNotificationOldState.0.10 SLEE-MIB::jbossJmxNotificationOldState = STRING: "Starting" SLEE-MIB::jbossJmxNotificationNewState = STRING: "Running"

In next post, I will cover ways to manage SNMP exposed attributes.

First Mobicents SS7 Gateway is out!!!

2011-09-23T03:19:00.000-07:00

Just as subject states. Our long struggle with SS7 specs and traces bring our long forgotten child to the public.
The 1.0.0.BETA1 of Mobicents SS7 Gateway is out. Currently it supports only 'USSD' over SIP/HTTP, but more will come.

Detailed info can be found here.

SLEE Basic concepts, mini FAQ

2011-04-28T09:28:00.000-07:00

I have had this post in mind for quite some time now, some may find in trivial or redundant, however I feel it needed. FAQ on mobicents.org is not a good place for such content, JSR's dont have it(hidden in plain sight), since its simple specs, mobicents user guides may incorporate it in future. Soooo, as community member I decided to create some sort of little FAQ, since its always easier to understand something stated directly, than browse tons of pages, in search of concept one does not even comprehend or missunderstands.

Each year there is some sort of of magic period, when lots of new users pop up in forums They ask. They really ask lots of questions. Thats a good thing, whats bad is that lots of questions are hard to understand, since new users mix/confuse SLEE concepts. Below you can find answers and clarification to some of them.

First lets explain some basic concepts:

1. SBB Abstract class(SBBA)

SBB Abstract class - is a class created by developer It contains all the service logic which SBB should perform. It implements javax.slee.Sbb interface.

NOTE: SBBA MUST implement all methods from javax.slee.Sbb interface, SLEE container does not provide those by default.

SBB Abtract class must have following, concrete methods(implemented):

receive event handlers - for each definition of incoming event in descriptor, SBBA must have method on<>
methods defined in SBB LO (if any defined) - for each method defined there, SBBA must have concrete method with matchin signature
methods defined in javax.slee.Sbb

Concrete methods define SBB Logic executed on call - be it an event, SBB LO call or SLEE callback.

SBB Abstract class must have following, abstract methods:

fire event method, for each event defined as "Fireable" (check events direction), SBBA must have method fire<>
setter and getter for each CMP field defined in descriptor
method to fetch custom Activity Context Interface, if any is defined
methods to fetch usage parameter sets, if any defined
methods to fetch child relation object for each child relation defined, if any

NOTE: As explained below, SBBA should not( or rather MUST NOT, but thats on devs responsibility) defined any class level variables to store any kind of state. It should use CMPs, ACI variables, profiles and some 3rd party resources, like database.

Thats it, there is nothing more to that class.

2. SBB Concrete class(SBBC)

SBB Concrete class is non abstract class. It is created by SLEE container upon deployment of SBB.

SLEE container implements all required methods(mandated by specs) present in SBBA. To put it simply, SBBC extends(in one way or another) SBB abstract class.

3. SBB Entity (SBBE)

SBBE is a logical entity(bad place for such word, but it is 100% accurate). It has no physical representation in what developer creates. It is maintained by SLEE container.

To put it simply, SBBE is a state of single SBB. More or less it consists of:

convergence name, ID
CMP fields of SBB (defined in SBBA)
activities to which SBB is attached
ACI variables
children references, if any children have been created
....

IMPORTANT: calls to SBBE state(like getter of CMP) outside of JSLEE calls WILL in most/all cases fail!

3. SBB LocalObject( SBBLO)

SBB Local object is an interface. Each SBB have it. By default SLEE container provides implementation of javax.slee.SbbLocalObject interface. It allows limited management over SBBs (SBBE actaully).

Some may have non standard interface. In such case user is responsible for implementation of methods defined in such, nonstandard interface, in SBB Abstract class.

4. SLEE Object Pools

SLEE container creates pools of concrete objects( for profiles and SBBs ) from concrete classes(SBBC for instance. Pools are managed my container. Objects within those pools are assigned to serve a call. For instance, imagine following situation. Event is fired into SLEE, container in some way determines:

- there is SBBE attached to activity

- it is capable of receiving said event

- SBBE has no real object assigned

SLEE container will do the following:

- borrow SBBC object from pool

- assign SBBC to SBBE (now calls to SBBE state are valid, ie. getter of CMP can be called)

- deliver said event to SBBC(actually handler is defined in SBBA) event handler

- possibly terminate assgiment of SBBC to SBBE, in such case SBBC instance is returned to pool, SBBE state is stored somewhere in container.

5. SBB Concrete class(SBBC) vs SBB Abtract class (SBBA) vs SBB Entity

It is very common for new users to mix or confuse above. Diagram below may shed some light on this problem:

6. Root SBB vs child SBB

Root SBB is a trigger point for service start. Each service defines root SBB. Root SBBE are create ONLY by SLEE container. They are created based on on logic defined below. Root SBBs can create children( children are created by code create by developer, NOT by SLEE container). Child SBBs can create more children.

IMPORTANT: Only root SBBs are interrogated for initial events. Child SBBs are not. Thats a rule of thumb

IMPORTANT: ONLY initial events are handled differently for Root SBBs, all other events are handled in the same way for Root and child SBBs

7. Initial Event Selector & convergence name

Convergence name is a sort of hidden property of root SBB. Convergence name is unique in container.

Initial event selectors allow to define custom convergence name. Variable selectors use SLEE variable(like EventTypeId) to compose convergence name.

Initial Event Selector method is a callback method. It is called by SLEE container when descriptors points to it. Selector method is called to allow code to determine two things:

- if event is AT all initial

- compute convergence name(create, based on developer whim)

Initial event selector method MUST be concrete method, implemented by developer in SBBA. It takes single argument of type javax.slee.InitialEventSelector

IMPORTANT: if event in descriptor has initial-event set to false(attribute of event definition) selectors are ignored by SLEE container, ie, following event definition, wont create service instance when event is fired into SLEE:

<event event-direction="Receive" initial-event="False">
   <event-name>StartServiceEvent</event-name>
   <event-type-ref>
    <event-type-name>
     javax.slee.serviceactivity.ServiceStartedEvent
    </event-type-name>
    <event-type-vendor>javax.slee</event-type-vendor>
    <event-type-version>1.1</event-type-version>
   </event-type-ref>
   <initial-event-select variable="ActivityContext" />
  </event>

8. How SLEE creates instance of service/SBBE

   There are two ways to create SBBEs. First one required javax.slee.ChildRelation object. SBBE is created with call to create() method. It is done directly from SBBA code created by developer.

   Second one is managed by SLEE container. Simple flow looks as follows(not exactly, it is simplyfied):

   - create list(organized by priority) of ROOT SBBs defining EventType as initial.
   - determine if event is initial:
   * if variable is used: default true
   * if initial-event-selector-method is used, check its return value
   - compute convergence name( or fetch from InitialEventSelector )
   - check if there is SBBE for that convergence name exists, if not, create SBBE and attach to activity on which event is delivered
  - deliver event to SBBE

   Above procedure is repeated for all root SBBs in said list.

   IMPORTANT: Note that if SBBE exists, its not created, its only attached to activity on which event is delivered.

Guidelines:
   1. Read specs, user guide and forums before posting. There is high chance one of said resources has answer to that question.
   2. If you post, give descriptive topic: "I have problem", "MGCP problem" or "Help I have problem/am in a hurry" is not descriptive, users, with similar problems wont be able to find it easly!
   3. Read exception/debug information - it may hold key to solve your problem.
   4. If you post please add as much info as possible. container name, container version, deployment config, conditions, traffic dump, etc....

Now some questions that I remember/googled from forums. If something is missing, send me email or add comment:

GENERAL Questions

  1. I have SLEE 1.x, when SMPP5 RA will be ported(or any new one)
   1.x reached its AOL loooong time ago, move to 2.x container or hack that resource. Core team does not have time to support everything :)

2. How can I contribute?
   You have to sign contributors agreement, so code becomes open source: https://cla.jboss.org

3. How can I create/send/receive XXX message?
   Read specific resources, check examples. Examples have sample code to create some basic interaction - ie. SIP messages, between two nodes. RFCs for SIP describe procedures used. If you still face problem, post with as much info as possible, step by step explanation what you do, core member or community member may have time to shed some light there.

  4. Which container is better SS or SLEE?
   There is no such thing as better container. Those are created in two different technologies. Performance wise they are quite similar. However there are key differences.
   SLEE:
   - RA abstraction allows easy integration of any type of protocol or resource(even hardware)
   - transactional by default
   - requires more time to comprehend
   - requires some low level knowledge about protocols used
   - similar to EJB in some way
   - well defined container facilities

   SS:
   - based on well known Servlets programming model
   - out of box integration between HTTP and SIP(SIP & HTTP oriented only)
   - not transactional by default, JTA requires user hacks
   - well defined help utilities - like Proxy or B2BUAHelper

   Depending on application purpose,available time, previous experience of dev team, one of them is more suitable. Detailed list of differences can be found here.

GENERAL SLEE Questions

1. When SBBE is removed?
   SBBE are removed in one of two cases:
   - explicit removal from developer code
   - SBBE attachment count - number of activities to which SBBE is attached, reaches zero.

If none of above happens, SBBE lingers in memory and performs actions developer coded it to perform.

2. Can I store profile data in some other place than default JPA resource?

Yes. Check profiles lifecycle methods. By default containers handles callbacks and actions associated with them. However you can provide implementation, which will be respected by container.

ERROR Reports

1. DU deployment gives error: xxxxx violates SLEE specification section x.y.z, what should I do?
   Read that section, validators in container print that information for a reason. If error says component violates some section, it does.

2. Container start/DU deployment throws exception with weird content:
- method not found
- wrong arguments
- etc...

   Clean container, if you get your hands dirty, you have to wash them, same thing applies to container. Remove everything you deployed previously before playing with source. Better, fetch clean AS and play in it.
  If problem persists it means that source is outdated. Now to solve that perform following:
   - update every source you use and rebuild
   - possibly update .m2/settings.xml and add nexus:

<repositories>
        <repository>
          <id>jboss-public-repository-group</id>
          <name>JBoss Public Maven Repository Group</name>
          <url>https://repository.jboss.org/nexus/content/groups/public/</url>
          <layout>default</layout>
          <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </releases>
          <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </snapshots>
        </repository>
      </repositories>

      <pluginRepositories>
        <pluginRepository>
          <id>jboss-public-repository-group</id>
          <name>JBoss Public Maven Repository Group</name>
          <url>https://repository.jboss.org/nexus/content/groups/public/</url>
          <layout>default</layout>
          <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </releases>
          <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>

}

3. Deployment shows error similar to: Missing dependencies for mobicents-
slee-example-sip11-b2b-DU-2.4.0.CR1.jar:

....

Well there is no other way! Deploy dependencies to make this nasty error go away. You can always check status of deployment via SLEE Twiddle or directly via AS JMX-Console.

Diameter Educational Series: Creating a "Hello World" Application with Mobicents Diameter

2010-11-19T01:53:00.000-08:00

For some time now the Mobicents Diameter Team have been wondering how should we introduce diameter use cases to mobicents community. After some talk we decided to create series of blog posts with step by step instructions and examples.

In next posts, me and Alex will cover topics ranging from simple "Hello World Example" to prepaid billing service or some IMS components.

Some basics

As weird as it may seem in diameter domain, first example is always "hello world", so... Always simplistic, to show how to play in new environment. In this post I will describe basics of interaction in diameter world. I wont however describe protocol level details(like CER/CEA capabilities exchange).

Diameter Nodes.

Diameter node is a network entity which supports diameter protocol and certain application. Each node is identified by certain set of informations:

realm
URI

Diameter realm is simply string, for instance "mobicents.org". It identifies nodes domain of responsibility.

URI identifies diameter nodes in realm. It has following form: aaa://[:port][;params]*

Nodes which has direct connection are called Diameter Peers. Diameter Peers have set of common applications. When connection is established between two diameter nodes, this set is determined. If there are no common applications, connection is not created. This implies that peers understand all exchanged messages and AVPs.

Messages and AVPs

All diameter data structures exchanged over wire have similar structure:

header
payload

Structure is proper word, since proper interpretation depends on metadata. Metadata is encoded in header.

Header contains following information:

ID
flags
length
(possibly additional information)

ID is a set of unique codes identifying structure. IDs include structure code and vendor ID(or application ID).

Flags are a set of bit switches. Flags carry additional information which may be helpful in proper interpretation of structure.

Payload is simply byte encoded content of structure, it may be simple data like integer number, or another set of structures. To see visualization please refer to this page. Since payload is byte[], its proper interpetation depends on type associated to ID of structure.

Diameter Session

Messages are exchanged within session. Session is a relation of exchanged messages to particular activity, for instance accounting. Each diameter application defines life cycle of session and types of messages that can be exchanged within session. This allows peers to communicate with integrity and confidentiality.

Sessions are identified by unique session id(AVP) present in each message exchanged.

Diameter Application

Diameter Application is not a software application. It is definition of protocol based on Diameter Base Protocol(RFC3588). Protocol is correct term since Diameter Application defines new messages, session state machines and AVPs.

Step by step example

Now for purpose of this example lets define our own, private application. Our example application has to meet following requirements:

define new messages
define new AVPs
define very simple FSM for session to allow strict message exchange

Lets consider IDs of application as follows:

ApplicationID: 33333

VendorID : 66666

In this example we want our application to exchange text data within custom messages.

Lets consider new type of message with name: SomeApplication-Exchange with message code equal to686 and application ID set to examples application ID.

Request(SER - SomeApplication Exchange Request) is defined as follows:

SER ::= < Diameter Header: 686, 33333, REQ, PXY >

                                        < Session-Id >

                                        { Origin-Host }

                                        { Origin-Realm }

                                        { Destination-Realm }                                       { Destination-Host }
                                       { Auth-Application-Id }
                                       { Exchange-Type }

                                       { Exchange-Data }

                                       * [ Proxy-Info ]

                                       * [ Route-Record ]

                                       * [ AVP ]

Answer is defined as follows:

SEA ::= < Diameter Header: 686, 33333, PXY >

                                       < Session-Id >

                                       { Result-Code }

                                       { Origin-Host }

                                       { Origin-Realm }

                                       { Auth-Application-Id }

                                       { Exchange-Type }                                       { Exchange-Data }
                                       * [ Proxy-Info ]

                                       * [ AVP ]

Message definition contains two non standard AVPs which are crucial to example application.

Both AVPs are specific to this application and are simple, not grouped AVPs. They are defined as follows:

+---------------------+

| AVP Flag rules |

|----+-----+----+-----|----+

Attribute Name Code Data Type |MUST| MAY | NOT| NOT|Encr|

--------------------------------|----+-----+----+-----|----|

Exchange-Type 888 Enumerated | M,V| P | | | N |

Exchange-Data 999 UTF8String | M,V| P | | | N |

Exchange-Type is simple enumerated AVP. Its code is 888 with Vendor ID equal to our examples vendor ID.

There are three possible values that this AVP may carry:

0: INITIAL - indicates start of data session exchange
1: INTERMEDIATE - indicates follow up exchange(consequent exchange)
2: TERMINATING - indicates last exchange, after answer is sent, session is terminated

Exchange-Data is simple UTF8String AVP. Its code is 999 with Vendor ID equal to our examples vendor ID. It contains data that has to be exchanged.

Since AVPs and messages are defined we need to define session FSM, so we know how to code exchange of messages. Since it has to be simple, lets consider such scenario:

client sends SAR with Exchange-Type set to INITIAL, server resonds with SAA
session starts
it can be followed by number of SAR with Exchange-Type set to INTERMEDIATE
session continues
client sends SAR with Exchange-Type set to TERMINATING
session ends

Diagram below depicts messages exchange:

Network

Since application logic and message flow has been defined, we can start creating client and server code. However to do that we need to understand how stack interacts with network.
For this example two types of listeners used by stack are relevant to us:

NetworkReqListener
EventListener

NetworkReqListener is very simple one. It is invoked for requests incoming from network layer. It has single method "processRequest". It is defined as follows:

public interface NetworkReqListener {
        Answer processRequest(Request request);
}

Instances of this listener type are registered in stack. With registration, stack is given information which applications are of interest for particular listener. That is, listener method is invoked for messages which belong to specific application.
Single method defined in this interface has return type of "Answer". Implementation of this interface may return non null value, in such case its sent as answer to request, for which method is invoked. However if method invocation does not return value, nothing bad happens. In such case, user code has to call session object to send answer explicitly.

Registration of this listener type looks as follows:

Stack stack;
 ....
 ApplicationId authAppId = ApplicationId.createByAuthAppId(....);

 Network network = stack.unwrap(Network.class);
    network.addNetworkReqListener(new NetworkReqListener() {
     
     @Override
     public Answer processRequest(Request request) {
      //this wontbe called.
      return null;
     }
    }, authAppId);

EventListener is a bit more complicated. It is used to inform application on result of request send operation. It is defined as follows:

public interface EventListener { 
  
     void receivedSuccessMessage(R request, A answer);
     
     void timeoutExpired(R request);
     
 }

It is invoked in two cases:

there has been no answer to request: timeoutExpired(R request)
answer has been received for request send from this stack: receivedSuccessMessage(R request, A answer)

Instance of this listener type is passed to session object when new request is sent through it.
Sessions and messages exchange
Messages can be exchanged between peers by means of Session objects(RawSession or Session). In our example we will use Session object. Each object of this type represents single diameter session(identified by session-id AVP present in messages). Session object is very basic one. Session object may be in two states: valid and invalid. It is invalidated explicitly by user. Once invalidated, it is not eligible for further use.
Session objects can be obtained from SessionFactory in following way:

SessionFactory factory = stack.getSessionFactory();
 //create new session, with auto generated Session-Id
 Session session = factory.getNewSession();

Stack configuration
Stack is configured with instance of "Configuration" object. Current implementation provides instance of this interface which parses XML configuration file. For detailed description of XML tags used in this file please refer to stack guide. Below there is quick guide to essentials we need to make our example application work.
Definition of configuration file looks as follows:


<xsi:element name="Configuration">
        <xsi:annotation>
            <xsi:documentation>JDiameter configuration&lt/xsi:documentation>
        </xsi:annotation>
        <xsi:complexType>
            <xsi:sequence>
                <xsi:element ref="LocalPeer" minOccurs="1" maxOccurs="1"/>
                <xsi:element ref="Parameters" minOccurs="1" maxOccurs="1"/>
                <xsi:element ref="Network" minOccurs="1" maxOccurs="1"/>
                <xsi:element ref="Security" minOccurs="0" maxOccurs="1"/>
                <xsi:element ref="Extensions" minOccurs="0" maxOccurs="1"/>
            </xsi:sequence>
        </xsi:complexType>
    </xsi:element
>

To our example only two are relevant(Parameters are of no interest for now):

LocalPeer
Network

LocalPeer contains configuration options for local diameter node. It includes information like:

local peer URI( like aaa://our.localhost:34200 )
IP addresses
Realm name to which local peer belongs to
overload monitor and applications configuration

Network tag contains configuration information concerning network environment:

Realms to which local peer is connected
Remote peers to which local peer is connected

Below is example configuration file for stack which:

identifies itself as billing.server.company.org, bound to port 13868
bound to two NICs
belongs to "billing" domain.
supports one realm: "service"
is connected to single remote peer

<?xml version="1.0"?>
<Configuration xmlns="http://www.jdiameter.org/jdiameter-server">

        <LocalPeer>
                <URI value="aaa://billing.server.company.org:3868" />

                <IPAddresses>
                        <IPAddress value="212.30.0.12" />
                        <IPAddress value="212.30.1.12" />
                </IPAddresses>
                <Realm value="billing" />
                <VendorID value="0" />
                <ProductName value="jDiameter" />
                <FirmwareRevision value="1" />
                <OverloadMonitor>
                        <Entry index="1" lowThreshold="0.5" highThreshold="0.6">
                                <ApplicationID>
                                        <VendorId value="0" />
                                        <AuthApplId value="333333" />
                                        <AcctApplId value="0" />
                                </ApplicationID>
                        </Entry>
                </OverloadMonitor>
        </LocalPeer>

        <Parameters>
                ...
        </Parameters>

        <Network>
                <Peers>
                        <Peer name="aaa://212.31.0.12:3868" attempt_connect="true" rating="1" />
                </Peers>
                <Realms>
                        <Realm name="service" peers="212.31.0.12" local_action="LOCAL" dynamic="false" exp_time="1">
                                <ApplicationID>
                                        <VendorId value="0" />
                                        <AuthApplId value="333333" />
                                        <AcctApplId value="0" />
                                </ApplicationID>
                        </Realm>
                </Realms>
        </Network>
        <Extensions />
</Configuration>

Application Client
Since now we know some basics, we can start creating our client code. Step by step, we should be able to create simple source which will act according to our application FSM.
First we need definition of some static fields, with some values relevant to our application and configuration. Static definition may look as follows:

//configuration files
 private static final String configFile = "org/example/client/client-jdiameter-config.xml";
 private static final String dictionaryFile = "org/example/client/dictionary.xml";
 //our destination
 private static final String serverHost = "127.0.0.1";
 private static final String serverPort = "3868";
 private static final String serverURI = "aaa://" + serverHost + ":" + serverPort;
 //our realm
 private static final String realmName = "exchange.example.org";
 // definition of codes, IDs
 private static final int commandCode = 686;
 private static final long vendorID = 66666;
 private static final long applicationID = 33333;
 private ApplicationId authAppId = ApplicationId.createByAuthAppId(applicationID);
        //avp codes
 private static final int exchangeTypeCode = 888;
 private static final int exchangeDataCode = 999;
 // enum values for Exchange-Type AVP
 private static final int EXCHANGE_TYPE_INITIAL = 0;
 private static final int EXCHANGE_TYPE_INTERMEDIATE = 1;
 private static final int EXCHANGE_TYPE_TERMINATING = 2;
 //list of data we want to exchange.
 private static final String[] TO_SEND = new String[] { "I want to get 3 answers", "This is second message", "Bye bye" };

Secondly, we require definition of some objects, like stack, session etc. It could look as follows:

//Dictionary, for informational purposes.
 private AvpDictionary dictionary = AvpDictionary.INSTANCE;
 private Stack stack;
 private SessionFactory factory;
        // ////////////////////////////////////////
 // Objects which will be used in action //
 // ////////////////////////////////////////
 private Session session;  // session used as handle for communication
 private int toSendIndex = 0;  //index in TO_SEND table
 private boolean finished = false;  //boolean telling if we finished our interaction

Thirdly, we need code which will initialize stack, session factory and register us as dummy listener for network requests. It could look as follows:

private void initStack() {
  if (log.isInfoEnabled()) {
   log.info("Initializing Stack...");
  }
  InputStream is = null;
  try {
   //Parse dictionary, it is used for user friendly info.
   dictionary.parseDictionary(this.getClass().getClassLoader().getResourceAsStream(dictionaryFile));
   log.info("AVP Dictionary successfully parsed.");
   
   this.stack = new StackImpl();
   //Parse stack configuration
   is = this.getClass().getClassLoader().getResourceAsStream(configFile);
   Configuration config = new XMLConfiguration(is);
   factory = stack.init(config);
   if (log.isInfoEnabled()) {
    log.info("Stack Configuration successfully loaded.");
   }
   //Print info about applicatio
   Set<org.jdiameter.api.ApplicationId> appIds = stack.getMetaData().getLocalPeer().getCommonApplications();

   log.info("Diameter Stack  :: Supporting " + appIds.size() + " applications.");
   for (org.jdiameter.api.ApplicationId x : appIds) {
    log.info("Diameter Stack  :: Common :: " + x);
   }
   is.close();
   //Register network req listener, even though we wont receive requests
   //this has to be done to inform stack that we support application
   Network network = stack.unwrap(Network.class);
   network.addNetworkReqListener(new NetworkReqListener() {
    
    @Override
    public Answer processRequest(Request request) {
     //this wontbe called.
     return null;
    }
   }, this.authAppId); //passing our example app id.
   
  } catch (Exception e) {
   e.printStackTrace();
   if (this.stack != null) {
    this.stack.destroy();
   }

   if (is != null) {
    try {
     is.close();
    } catch (IOException e1) {
     // TODO Auto-generated catch block
     e1.printStackTrace();
    }
   }
   return;
  }

  MetaData metaData = stack.getMetaData();
  //ignore for now.
  if (metaData.getStackType() != StackType.TYPE_SERVER || metaData.getMinorVersion() <= 0) {
   stack.destroy();
   if (log.isEnabledFor(org.apache.log4j.Level.ERROR)) {
    log.error("Incorrect driver");
   }
   return;
  }

  try {
   if (log.isInfoEnabled()) {
    log.info("Starting stack");
   }
   stack.start();
   if (log.isInfoEnabled()) {
    log.info("Stack is running.");
   }
  } catch (Exception e) {
   e.printStackTrace();
   stack.destroy();
   return;
  }
  if (log.isInfoEnabled()) {
   log.info("Stack initialization successfully completed.");
  }
 }

Finally we need three more pieces of code to handle initialization of whole procedure, request send and answer handling.
Initialization part could be straightforward and could look as follows:

private void start() {
  try {
   //wait for connection to peer
   try {
    Thread.currentThread().sleep(5000);
   } catch (InterruptedException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   }
   //do send
   this.session = this.factory.getNewSession("BadCustomSessionId;YesWeCanPassId;" + System.currentTimeMillis());
   sendNextRequest(EXCHANGE_TYPE_INITIAL);
  } catch (InternalException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  } catch (IllegalDiameterStateException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  } catch (RouteException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  } catch (OverloadException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }

 }

Part which actually creates request and sends it via session objects is also quite trivial. It could look as follows:

private void sendNextRequest(int enumType) throws InternalException, IllegalDiameterStateException, RouteException, OverloadException {
  Request r = this.session.createRequest(commandCode, this.authAppId, realmName, serverURI);
  // here we have all except our custom avps

  AvpSet requestAvps = r.getAvps();
  // code , value , vendor, mandatory,protected,isUnsigned32
  // (Enumerated)
  Avp exchangeType = requestAvps.addAvp(exchangeTypeCode, (long) enumType, vendorID, true, false, true); // value is set on creation
  // code , value , vendor, mandatory,protected, isOctetString
  Avp exchangeData = requestAvps.addAvp(exchangeDataCode, TO_SEND[toSendIndex++], vendorID, true, false, false); // value is set on creation
  // send, pass oursevles as EventListener object
  this.session.send(r, this);
  dumpMessage(r,true);
 }

In above code, when request is sent this is passed as argument(EventListener). So our client object, must also handle answers. Lets consider that we want to perform following:

Send request with some data encoded as string
Receive properly formatted answer, with the same data client send
In case of error answer, client should terminate operations

Code which does above could look as follows:

@Override
 public void receivedSuccessMessage(Request request, Answer answer) {
  dumpMessage(answer,false);
  if (answer.getCommandCode() != commandCode) {
   log.error("Received bad answer: " + answer.getCommandCode());
   return;
  }
  AvpSet answerAvpSet = answer.getAvps();

  Avp exchangeTypeAvp = answerAvpSet.getAvp(exchangeTypeCode, vendorID);
  Avp exchangeDataAvp = answerAvpSet.getAvp(exchangeDataCode, vendorID);
  Avp resultAvp = answer.getResultCode();

  
  try {
   //for bad formatted request.
   if (resultAvp.getUnsigned32() == 5005 || resultAvp.getUnsigned32() == 5004) {
    // missing || bad value of avp
    this.session.release();
    this.session = null;
    log.error("Something wrong happened at server side!");
    finished = true;
   }
   switch ((int) exchangeTypeAvp.getUnsigned32()) {
   case EXCHANGE_TYPE_INITIAL:
    // JIC check;
    String data = exchangeDataAvp.getUTF8String();
    if (data.equals(TO_SEND[toSendIndex - 1])) {
     // ok :) send next;
     sendNextRequest(EXCHANGE_TYPE_INTERMEDIATE);
    } else {
     log.error("Received wrong Exchange-Data: " + data);
    }
    break;
   case EXCHANGE_TYPE_INTERMEDIATE:
    // JIC check;
    data = exchangeDataAvp.getUTF8String();
    if (data.equals(TO_SEND[toSendIndex - 1])) {
     // ok :) send next;
     sendNextRequest(EXCHANGE_TYPE_TERMINATING);
    } else {
     log.error("Received wrong Exchange-Data: " + data);
    }
    break;
   case EXCHANGE_TYPE_TERMINATING:
    data = exchangeDataAvp.getUTF8String();
    if (data.equals(TO_SEND[toSendIndex - 1])) {
     // good, we reached end of FSM.
     finished = true;
     // release session and its resources.
     this.session.release();
     this.session = null;
    } else {
     log.error("Received wrong Exchange-Data: " + data);
    }
    break;
   default:
    log.error("Bad value of Exchange-Type avp: " + exchangeTypeAvp.getUnsigned32());
    break;
   }
  } catch (AvpDataException e) {
   // thrown when interpretation of byte[] fails
   e.printStackTrace();
  } catch (InternalException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  } catch (IllegalDiameterStateException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  } catch (RouteException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  } catch (OverloadException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }

 }

As you can see, client code is quite simple. It is not smarty-pants code, its sole purpose is to show how to interact with stack. Server code is very similar. Whole source with configuration files and ready to run scripts can be found in our gcode svn.

Syntax highlighter

2010-11-18T05:33:00.000-08:00

Just testing cool tool for syntax.

Test1:

class X implements java.io.Serializable{

    public void makeMyDay()
    {
        System.err.println("PunK");
    }
}

Downside of this, is that for each snippet I need to edit HTML, but still... looks a lot better.Also sometimes "Compose" will still use editor &ltpre> to embed new content.

To use this tool add ref in head of blog template to .js and .css files:

<link href='http://alexgorbatchev.com/pub/sh/current/styles/shCore.css' rel='stylesheet' type='text/css'/>
<link href='http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css' rel='stylesheet' type='text/css'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJScript.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushBash.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCss.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJava.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPhp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCSharp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXml.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushSql.js' type='text/javascript'></script>
<script type='text/javascript'>
  SyntaxHighlighter.config.clipboardSwf = 'http://alexgorbatchev.com/pub/sh/2.0.278/scripts/clipboard.swf';
  SyntaxHighlighter.config.bloggerMode = true;
  SyntaxHighlighter.all(); 
</script>

and follow instructions: found here (look for section with examples).

Mobicents Team building 2010, Antalya, Turkey

2010-10-11T06:39:00.000-07:00

Exactly, that one event in year, when whole team is supposed to have fun and work in close quarters(yes).

The PLACE

Whole event has been organized by Eduardo M. M., big thanks. It was one of best events, if not THE best we had so far. We stayed in 5 start hotel & SPA center. Awesome place to chill out. Just look at pictures:

This year was actually special for two reasons. First reason is the fact that whole team has gathered for the first time. Yes, thats true. During past years we always had bad luck and someone either did not make it, or just couldnt. This year even we met all, for the first time. Even Tom, who works from Brisbane office joined us.

Second reason is fact that some community users and customers joined us on short notice. This proved to be very, very good turn of events.

Most of us arrived on 24th night or evening, so start was a bit slow - simple catching up with cold beer in hand at the bar.

The FUN

Next day was strictly fun day, no work(well we talked about roadmaps on the bus, but that does not count). Rafting time! We took a bus from hotel which drove us somewhere in the mountains. Once the bus stopped we got out, our prayers have been heard, we were alive - seriously if you dont buckle up, go there, have a ride, those guys are insane.
From that spot we took huge rafts and went down the river. It was quite good fun.

The WORK

Now, enough about fun. Since that point, our regular day looked more or less the same: breakfast, work, 1-2h relax time, more work, party till morning.
Total we had three and a half day for our presentations, discussions and everything related. During that period of time, as each year, we went through all projects, their achievements, shortcommings and roadmaps.
Additionally this year some other topic were brought up to attention and discussed - like Clustering or SS7 training session.
Unfortunetly three days were not enough to go through all of our fields of interest. Certainly sign that we should extended next years event. Example topics that were discussed only with beer in hand are for instance: SIP Presence or IPBX.

Our first day started with private sessions during which we discussed some internal stuff, crucial to our future. After that plan looked as follows:

The meeting started with presentations from customers. The talk was mostly on how they are using the Mobicents Platform, what they liked and what they dont. Most important was what they expect from Mobicents in future, how Mobicents fares in competition from peers etc
Business development update: leads, partners, customers, 12 month go-to-market strategy
Lessons learned from customers in past 12 months
Clustering infrastructure
Documentation process review
Diameter Crash Course
Diameter 12 month progress and next 12 months roadmap
Media Server Crash Course Part 1
SS7 Progress
Media Server 12 month progress and next 12 months roadmap
JSLEE 12 month progress and next 12 months roadmap
Sip Servlets 12 month progress and next 12 months roadmap
Sip Servlets review

JSLEE

Eduardo presented our efforts to bring best open soruce JSLEE container :). So....
We had very good year, lots of work, lots of community feedback. Extremly successful 2.x release of container. We completly reworked 2.x core to achieve:

high performance - over 4x compared to 1.x generation of container
low latency
fault tolerance

His presentation covered also major features and development efforts we made, like:

Container's core modularization and SPI
Server's state replication
Fault Tolerant RA API
Congestion Control
Event Router Stats and Execution Mapper
Simplified Global Logging Configuration
New or Reworked RAs (JCC, ISUP, MAP, XCAP Client)
Jopr Web Console
Enhanced or simplified external SLEE Connection.

In the end he covered roadmaps for immediate release and long term efforts:

Mobicents JAIN SLEE 2.2.0

Part I of clustering performance enhancements (8x compared with 2.1.2)
Buddy groups clustering
Twiddle Command Line Interface (CLI), which we believe will be a major tool for developers and platform administrators
Part I of JAIN SLEE 1.1 Extensions, specially the one which allows JAIN SLEE Libraries to depend on other SLEE component types, such as RA Types
Eclipse SLEE Plugin 2.0
SMPP v5 Resource Adaptor
Misc performance optimizations on SLEE facilities, such as Tracers

Mobicents JAIN SLEE 2010/11 Roadmap Draft

JAIN SLEE 1.1 Extensions: Annotations & ConfigProperties
Jopr Web Console 2.x (or something else if we are not able to solve current version limitations)
EclipSLEE 2.1
Mobicents Cluster Framework 3.x with Advanced Buddy Groups features such as high performance intra group broadcasting of notifications
Second wave of SS7 RAs
JSR 309 RA

For detailed info follow Eduardos blog.

DIAMETER

Diameter presentation was a first one I did this year. This was actually a crash course training and as such it can not be disclosed as other presentations.

In crash course Ive covered following:

DIAMETER basics - data structures, encoding, protocol base
DIAMETER domains
Base application
Accounting application
Credit Control Application(rfc4006)
Ro & Rf applications

During Diameter time, Alex covered our development efforts and roadmap.

In short it was quite good year. Roadmap was a bit packed. Only two features did not make it since there was no interest - WS Support and HSS. Major features and development efforts on diameter are as follows:

SOAK testing
CPU and memory stability
XML configurable dictionary and validator
implementation of different applications(Cx/Dx,Sh,Ro,Rf,Cca....) along with JSLEE RAs
FT/HA support
performance improvement( over 4x )
documentation
JOPR console
Improved AVP handling

For next year we plan to split work in two directions. Continue 1.4.x branch with improvements and start new one. The 2.x will be testing field for next gen stack, which should be more user friendly and much more performant.

For 1.4.x we have planned following:

1.4.x

parser separation from stack metadata
testing framework for application sessions
profiling and improving clustering code
improve thread management
IPSEC/TLS support
testing framework for JSLEE RAs
support plugable/configurable load balancing algorithm in stack
integration with SIP loadbalancer
...

This is just a short list, full has much much more, its quite packed and scary.

For 2.x we have planed following:

2.x

redesign API to be user friendly
evaluate IoC as good approach
decouple sessions and message creation
SCTP support
greater perofrmance(over 1k exchanges/s)
....

SS7

During one of my time slots I have conducted quick crash course about SS7 and our progress in this field.

Crash course proved to be a bit confusing for some. But it drove our community guest into discussion, in which they shared their experience, field of interest and expectations. It was quite good and valuable discussion.

SS7 progress during last year is tremendous. We have started very slow and picked up pace.

From almost no working code and experience we finished with support for:

Dialogic and Intel based SS7 cards - this includes implementation of MTP levels
M3UA integration
SCCP
ISUP
TCAP
MAP
USSD Gateway

In future we plan to get SS7 training on operators side to be able to meet production quality with our code. In near future we will stabilize SS7 stack layers and test everything end to end with real hardware in our lab, which is being created.

Last but not least we plan to add more protocols to USSD Gateway we have been developing.

SS7 presentation can be found here.

Media Server

During this event Amit and Oleg presented last years achievements and problems we faced on media field.

In media processing accuracy and predictability is what counts. To address that requirement we had to give away multi threading and java timers. Our work on MMS has been centered around:

stability
predictability
accurate implementation of scheduler(very low overhead, with 1ms precision)
reducing number of active threads - MMS core and MGCP stack
improving performance with 3rd party libraries(like TTS, MBROLA)

The outcome is best performing server on low end machine with 300x concurrent, bidirectional connections!

Future plans for MMS are to split development in two directions. First one is to continue 2.x development and concentrate on stability and perofrmance with voice media.

Second is to start 3.x development which will include video support.

Near future roadmap(2.1.0-B1) includes following:

B-Channel endpoint for SS7
smart voice pool
configurable connection count for endpoints
RTCP support
Audit endpoint support

Thats it. Looking forward for next years TB event. Hope that more community users will show up.

New stuff

2010-10-11T02:31:00.000-07:00

Last week was a bit of hell week. We had two releases going on, one for SS7 project second for SLEE container. So lets see what we managed to push to community.

SS7 includes few fixes, but most important improvements are hidden in SCCP and M3UA/MTP. This release brings two things:
- support for M3UA, now you can integrate our stacks with Dialogic M3UA.
- SCCP routing and service. SCCP layers supports now basic routing. Additionally it has been changed to service, in which for instance JSLEE RAs, can register to receive MU which are targeted for specific address.
Release already happened, shortly there will be new bundle available on sourceforge.net.

JSLEE release brings tons of goodies. Detailed info can be found here, in short:

- Cluster performance optimization, 8x compared with 2.1.2.FINAL
- Support for "Buddy Groups" clusters
- Tracers performance optimization
- Enhanced RA's SleeEndpoint with custom operations to help/optimize
work in cluster mode
- EJB support for SBBs, as defined by JAIN SLEE 1.1 standard
- CMP Field Accessor Methods performance optimization
- SbbContext/ProfileContext JAIN SLEE 1.1 Extension
- ActivityContextInterface JAIN SLEE 1.1 Extension
- Library XML Descriptor References JAIN SLEE 1.1 Extension

Additionally this release comes with Twiddle CLI and refactored Eclipse plugin (EclipseSLEE).

Trip after trip, training gig.

2010-10-11T02:11:00.000-07:00

Its been a while since Ive had some time to blog, high time to catch up.

Sometime ago(end of August I believe) me and Amit had pleasure to perform training in South Affrica.
Training took place in(or near) Johanesburg at CSIR institute.

CSIR stands for Council for Scientific and Industrial Research. Its located in Pretoria, Johanesburg. The CSIRis South Africa's central and premier scientific research and development organisation in Africa. Constituted by an Act of Parliament in 1945 as a science council, the CSIR undertakes directed and multidisciplinary research, technological innovation as well as industrial and scientific development to improve the quality of life of the country’s people. In short, CSIR hosts researches and create technologies which are implemented by SA government.

We had accommodation provided by Meraka. During whole training we stayed in one of houses at Merakas campus. Campus is a huge playground, not only it looks great but it provides also a lot of places to socialize, like:

football field
tenis/squash courts
gym
etc....

Usually core developers do not provide training. However this case was a bit different. Whole training was customized, to address needs of Meraka team.

Training gave me and Amit rare opportunity to interact with users. Whole gig gave us quite good picture of problems and design traps users fall into. Most of them come simply from missing concepts behind specification. This is something we can address in blog posts and documentation. And we will.

CSIR developers are quite experienced. They've been playing with JSLEE container for quite some time now. They already have few Resource Adaptors and services developed on top of JSLEE container. Some of them quite interesting, for instance MOBI4D.

CSIR. Meraka Team, me and Amit.

Mobicents does it again!

2010-08-02T00:51:00.000-07:00

Incredible. Once again we managed to make release, or two. Details below:

Protocol Suite - 1.0.0.B2.
Media Server - 2.0.0.CR3.

Mobicents media server is last CR before FINAL( previously called GA).

Ive mentioned that incubator went live on mobicents.org. Some work has been done there as well, during last few days. roadmaps are alive and beeing updated as in other projects. Also some new projects surfaced there(HA, SIP LoadBalancer, ....).

What is still on "TODO" for incubator? Documentation. It should be linked soon. Stay tuned.

Incubator goes live! Baby projects are official.

2010-07-15T01:51:00.000-07:00

Again its been a while. Shortly traffic will pick up and some tutorial will see the light here. But before that, small update on mobicents.org. Incubator goes live. First Mobicents baby projects hit the light!

http://www.mobicents.org/incubator.html

stream library - proprietary stream library
asn.1 library - library which enables user to encode/decode ASN.1.
set of SS7 stacks.
USSD Gateway

Some more will get promotion to incubator, time will show.

Fresh releases from Mobicents Kitchen

2010-03-18T10:37:00.000-07:00

Last week or two were quite fruitful for mobicents team. What came out from under our hood?
Well:

Jain MGCP Stack RC7 - last RC, more info can be found here.
Diameter 1.2.0 GA - JSLEE 2.x resources, more info can be found here.
MMS 2.0.0.RC1, first Release Candidate from 2.x trunk of MMS, more info can be found here.

More will come.

Maven Archetypes update

2010-03-15T02:52:00.000-07:00

Some changes in maven tools in mobicents platofrm:

fix metadata
add jslee 1.1 service archetype

So now all desired archetypes are there.

Maven archetypes can be found here.

Also there is good article how to use archetypes to quick start projects, it can be found here.

How to use archetype from CLI? Please follow:

checkout
install with mvn install
use following command(for service): mvn archetype:generate -DarchetypeGroupId=org.mobicents.tools.maven.archetype.slee -DarchetypeArtifactId=jain-slee-11-service -DgroupdId=xxx.y -DartifactId=TestSLee11Archetype_service -DarchetypeVersion=1.0.0.BETA2-SNAPSHOT , where:

archetypeGroupId - archetype group
archetypeArtifactId - id of archetype
archetypeVersion - archetype version, once it is released, it should not be required
groupdId - new groupd id of created project
artifactId - new artifact id of created project, also directory name

JSLEE 1.1 service composition vs class loading

2010-03-14T16:00:00.000-07:00

My last post about JSLEE 1.1 describes theory of classloading in v1.1 containers. However, how does it look in practice?

Well, I must say it looks and works much better than earlier model. But.. yes, there is one small "but", due to inheritance restriction it may sometime prove to be problematic, atleast for certain cases.

Case 1: General Class Loading scheme

To make problem a bit closer, lets consider two services, each service is composed from the same sbbs:

- Sbb[1]

- Sbb[2]

- Sbb[3]

Each sbb references the same RA Types and Profiles

- RAType[1]

- Profile[1]

- Profile[2]

To make this a bit more complicated - each service is independent. That is each can be deployed separetly and provide service.

Now lets imagine two things:

SBBs extends super class which provides common fields(RA Type SBB Interface) methods to manipulate profile, etc
There is shared Utility class which manipulate RA Type message factories to create specific messages, manipulate profiles, etc.

Now there is no problem in 1.0 container as classloading was flat. Everything works fine, one or many sbb jars/DUs - it still works.

However when one wants to deploy this set of services in 1.1 container, problem shows. In 1.1 container (as it is a bit more organized) we would like to have everything separated:

library(Library[1]) with: super class of SBBs, Utility classes and similar
sbb-jar.xml, sbb-jar file for each sbb
DU for each somponent - services,library,profile and RA

Since library contains classes each sbb use, each sbb-jar.xml declares dependency on library.

From first glance it looks like this deployment should work from kick. Well, it wont...

Lets consider Utility class, it operates(depends) on:

- RA Type events

- RA Type classes

Sbb super class is very similar in this matter. Both classes are contained in our Library[1].

What is wrong? Library[1] does not have any way of referencing RAType classes. That means that Utility class (as well as Sbb super class) has no access to definition of those classes. This will cause failure during runtime or sbb verification.

Conclusion: using single jar file for sbbs allows to make this problem dormant. However there seem to be more favored way for 1.1 container. That is:

each functional component declares library with classes it uses
functional component declares dependency on its library in its xml file
any other component may ow declare dependency on library to use certain classes

For this example it would mean following:

RA Type[1] Library[1] is declared. LIbrary[1] declares dependency on RA Type[1] Library[1].

Case 2: Event sharing

This problem happens only on shared deployment. That is JSLEE and non JSLEE aplication is deployed in the same container.

Lets consider simple web application which fires event "X" into SLEE. Event "X" is received and processed by SLEE service.

This makes it clear that X.class should be present in two places:

SLEE - since there is service depending on it.
web application archive, since it fires it.

Since JSLEE v1.1 container no longer shares its classes outside container, it is logical to assume that jar containing X.class should be in both: JSLEE and web archive.

Well, logic fails here. It wont work. It will cause well known exception:

ClassCastException: Can't cast X to X

To make this work following steps should be followed:

- jar containing X.class should be in container library directory

- events.jar deployed within SLEE should contain only xml file with even definitions

Thats it.

JSLEE Maven Archetypes

2010-01-25T06:49:00.000-08:00

Sometime ago Eduardo spent some time to create basic maven archetypes for JSLEE. Since 2.x CR1 of JSLEE is going out and there was a lot of google group traffic regarding setting up basic project, I dedicated some time to create similar package for JSLEE 1.1.

Here is wiki page which describes how to use archetypes (iirc). I will update it once I get spare 5 minutes.
Sources can be found here.

MMS v2 Beta3 is out

2010-01-15T03:30:00.000-08:00

It took some time to reach this point. But ... its out. Another 2.x.y media server from mobicents has been born yesterday.

Details can be found in media server blog. In short, what does it bring?

Video support for ISO files
RTSP support - this includes mobicents RTSP stack and MMS Controller
SS7 support preview

Yes, SS7. At the moment its still not full, but allows to do some cool stuff.
Currently SS7 guide is short and can be found here. However next release will incorporate it in regular guide.
Roadmap can be found here.

So what those goodies allow?
Video is self explanatory. RTSP adds live streaming capability(its a bit like showcast radios on winamp with, but bit cooler since it allows operations like: pause, rewind - VCR style).

Finally SS7. We tested with real MSC on operators side. Tests performed:

link setup and stability(long term IN_SERVICE)
streaming
MU validation(it takes time to learn how to read those bits)
SCCP,TCAP and CAMEL testing.

CAMEL test has been performed by JSLEE 1.x.y application with JCC RA( it can be found in svn, code is very simple )

Here is what Media Server Team planned for MMS:

stabilize core for CR1
add other SS7 protocols as independent stacks(that can be used without MMS)
B/D channels endpoints
SS7 RAs for JSLEE 2.x and similar resource for MSS

If everything goes smootly next release will allow JSLEE and MSS to connect to legacy network and provide means of replacing Asterisk.

Big thanks to Vladimir for hand on HDLC part for MTP layers.

Seagull on F12 and GCC 4.3+

2009-11-23T15:12:00.000-08:00

This is going to be short post. Alex made log of his probs working out through compilation of seagull on OS X. For me it turned out to be a bit harder.
Please read his post before going through my notes.

So what is fuss all about?
As it seems, aside all problems Alex had there are few new ones on Fedora 12.

First thing is that Fedora 12 ships with GCC 4.4.something. Since GCC 4.3, gcc becomes more strict. What is significant is that generation does not include standard header files by default. This causes GCC to complain about 'memcpy', 'strncpy' and other function not beeing defined. After going through all files, which cause gcc to fail and adding includes by hand I got a bit pissed of. (not sure if this is the good sollution) Once I boiled up, decided to add includes into common/Utils.hpp file.
File modification includes two lines:
#include "stdio.h"
#include "string.h"

Second thing that poped up was error with parentheses. It seems that Seagull team went the easy way and left a lot of statements like:

if( x = (vv == x))

GCC does not like those anymore and fails. Only sollution is to edit files and add () so ifs look like:
if( (x = (vv == x)))

Now after cleaning it went quite good. To point when linker started its work.

relocation R_X86_64_32 against  - this messages makes it to screen once ld goes into action.

It seems that "-fPIC" has not made it into make file. This seemed a bit odd, but... I got work-${version}/compile.mk into vim, edited and rerun. Again failure. Now, at this point it becomes a question why there are xxx.mk files, which do not affect build?
Sollution is quite simple. Add '-fPIC' to options BUILD_EXE_CC_FLAGS_LINUX and BUILD_LIB_CC_FLAGS_LINUX, present in build.conf.

Now clean compilation worked from kick.

Hope this helps. Cheers

Good stuff comes packed. JSLEE 2.0.00B2 and MMS news

2009-11-18T16:05:00.000-08:00

Its been a while since I had a time to post here. Made myself a promise to post quite few usefull tips regarding JSLEE 2.x but never had time. Why? Because Mobicents team worked quite hard to be able to deliver good news.

So first thing. SLEE 2.0.00B2 is about to be let loose into community!
Made a lot of effort to make it quite a pack.
- HA/FT clustering API
- new HA api for RA implementation
- full replication of data and clustering of JSLEE servers !!!!
- performance improvements
- SIP11 RA tunning(more and more cps)
- BUG fixes

Each topic deserves separate post, once I have a second, I will do that with details and examples guide.

HA/FT clustering API(topic for another post) has ben created to ease development on this "side of moon". It allows quite easy plugability into cluster, making application aware of changes. It is based on JBoss Cache and supports different replication strategies. I will describe it a bit more deeply in another post. If someone feels a desire to play with it I recomend browisng and playing with repository. So far we created a standalone, distributed timers(not tied to any of our project) it is quite good alternative to EJB3 timers and other implentation available(I would say its so far a best sollution, but...).I will describe example in another post(if someone feels like playing in a dark this will help.).

SLEE 1.1 specification is a great improvement since 1.0. Changes are quite significant so I even doubt why its 1.1, not 2.0, but thats just a speculation. However, among all changes there is no definition of HA/FT api aside of Marshaller ( which is of no use without something specific to container). Thats why each implementation of JSLEE specification has to have some specific API to handle replication and FT in RA layer.
So, we had to do it. So far only SIP11 RA is aware of cluster. We have to make some more test, but its working and its quite nice feature, atleast after hours of coding its something that pays of effort.

Full replication. Yes, JSLEE 2.x container is FULLY replicable among cluster. There is no exception. Data and local server resources are handled properly to make SLEE developers work in unified enviroment, even though server runs on mulitple nodes.

Now what about MMS? Well me, Amit and Oleg took our time. All news will be official near release date. But what I can reveal is:
- we are working on video and its going good
- performance improvements - based on media path
- SS7 enabled!, right now we are running test to see how SS7 link is stable, next are tests with CAMEL, ISUP, SCCP.

Thats it for now.

MMS 2.X - Console comes back

2009-09-23T02:30:00.000-07:00

It happened. In 1.X branch we dropped console for some reasons (many discussion, outcome the same). During last MMS chat Oleg spoke words we believed noone will witnes him say: "Maybe its time for..."

Well thats the background. To make it short. We would like to announce that MMS 2.X will have management console. How it will look like? It all depends on feedback we get from users. We have general idea, but feedback and ideas are mostly welcome.
Design Wiki can be found here , public thread can be found here.

MMS - Control Protocols

2009-09-13T11:39:00.000-07:00

In mobicents projects we have different EE:

SLEE
MSS
. . . (maybe more)

In addition we also have Media Server. Media Server is only responsible for media part of applications. To make it short: regardless of application logic, signaling protocol utilized by application, media server role is always the same, to process media.

EE is driven by some sort of protocol chosen by development team - which has complete freedom to choose one protocol over another, restricted only by project requirements. In case of media server it is not that easy. Over time different "parties" created different control protocols for media server (media gateway).
For instance with CISCO equipment media server is controled with MGCP, in IMS environment media server is controled with H.248, in WWW it can be controled with RTSP, etc, etc.

In Mobicents Media Server 1.x.y we support only MGCP (aside of local MSC API), however we felt that this is not enough to meet demand from partners and community (more on this here).
So for MMS 2.x we have more in plans:

RTSP
H.248
MSML
VXML

During Brno we were supposed to iterate over this short list, high light use cases, differences and basic concepts. However we did not have enough time. So in order to compensate I decided to post it here.
Here we go.

Media Server Operation Model

As mentioned above media servers follow certain model of operation. See image below:

Media Server estabilishes only RTP stream exchanged between UAs. To setup streaming application makes use of some dedicated control protocol. Dedicated controler on Media Server side converts control protocol reqeusts into physical setup of underlying resources(generators,detectors, codecs, etc....). This happens regardles of signaling protocol used(on image it is SIP, but in reality it could be any suitable for application).

MSML: Media Server Markup Language

Basic inforamtion:

XML Based
It is independent of transport protocol ( SIP, HTTP, IP, ...)
Follows simple request/response model
Supports transactions
Supports semi-recovery from errors
Requires resource reservation
RTP service oriented

MSML supports something similar to transaction on Media Server side. It is not strictly defined as transaction but has very similar semantic/behaviour. Each MSML request can be seen as set of actions. Each action has arbitrary ID, set by application developer. If particular action fails, error response will contain this ID to make application aware of failure point - this is semi-recovery of error condition. MSML pinpoint exact place of failure, allowing application to free resources (yes, responsibility is pushed to application). This is required since Media Server does not reclaim them (according to MSML specs).

MSML is also RTP service oriented. Protocol does not define endpoint types as MGCP does for instance. It only defines actions that need to be undertaken to produce stream/interaction with user stream.

As protocol MSML is designed to be extensible, just as Diameter does. Functional elements are grouped into package. Each package defines set of primitives which affect Media Server. Prmitives are tags and their parameters which are intepreted by Media Server controler.
MSML allows new packages to be defined along ability to extend already defined. This is how whole language structure is defined. Definition from RFC are grouped as follows:

Core
Dialog-Core
Conf-Core
Audit-Core

Dialog-Core defines primitives to control automated actions of Media Server, it defines also subpackages to extend those capabilities:

Dialog-Base
Dialog-Transform
Dialog-Speech
.....

MSML: Base abstraction

Base MSML abstraction defines functional elements which are aligned as in image below:

conn - connection is logical unit which termiantes all RTP sessions from one UA
operator - logical unit representing DSP
dialog - set of automated actions like: play, DTMF generator/detector, etc...
conf - logical unit which mixes streams

MSML: Protocol use example

Below is use case of MSML encapsulated in SIP protocol.

MSML used inside SIP requires usually dialog to be established between application server and media server. MSML Requests/Answers are embeded in SIP INFO/INFO OK message.

In image above there is only one UA, which awaits video to be played. However for different number of UAS scheme is similar - only difference is dialog time when dialog is estabilished between app server and media server.

In example scenario app server asks Media Server to play announcement like (this is MSML Dialog): "Press one to play movie XXXXX, Press two to play movie xXXYYx" and detect DTMFs. Once UA sends DTMF, Media Server sends DTMF embeded in SIP INFO back to application server and indication that MSML Dialog has ended. Application server decodes INFO, picks file to be streamed back to UA and starts new MSML Dialog: "Play Movie Dialog".

Other protocols will follow in subsequent posts.

Slee 1.1 Classloader demystified!

2009-09-05T02:37:00.000-07:00

Here we go.

During our dev struggle to get v2 of Mobicents JSLEE container operational we encountered quite big problem: Class Loading scheme.
Usually class loaders are organized in classic tree structure:

one root
each leaf can have only one parent
each leaf can be a root of a subtree

This has certain limitations, as proven by our JSLEE 1.0 container. Without classloader repositories/isolation there is no way for two versions of the same ra(service/Sbb/Profile) to be deployed and enabled.
Moreover it is not possible to maintain integrity of classes loaded - consider situation:

DU1 has service using lib.jar
DU2 also has service using lib.jar
order of deply is: DU1,DU2
when DU2 is deployed, classloader finds lib.jar classes and does not load them
DU1 and DU2 services kick in, instances of lib.jar classes are created (from DU1 definition)
now DU1 is undeployed
error on class casting - vague information: can not cast XXYX.class to XXYX.class

Now regarding Mobicents JSLEE v1. JSLEE Specs did not define any way of providing dependency classes. To resolve this problem we altered a bit DU structure, each DU jar could have "library" dir with dependencies for particular DU. This proved to be enough to solve dependencies, however all above problems still apply.
Obviously JSR240 specs lead got a notion that specs lack something valuable here and in 1.1 it has been improved.
In 1.1 container "library" component has been introduced. It is not a functional component/jar - not in terms of slee, like SbbComponent or ProfileCompoment. Its only purpose is to provide standarised and versioned way to provide classes to Slee components. So no more DU/library!!
Now about classloaders. In SLEE v1.1 model has changed as well. Its a bit tricky. Consider classic model - tree, where each classloader with one parent. This is not sufficient for SLEE v1.1. New model allows multiple parent for each leaf to reflect components relation.

Classloaders are defined per component - that is not jar, but actual identifiable component(which has ComopnentID). Component class loader loads all classes from component jar "and" all classes from referenced components.
Consider case of jar file which contains definition of Sbb1, Sbb2 and Sbb3 - all sbb classes are in jar.

So:

three classloaders - Sbb1,Sbb2, Sbb3 - each "has" classes from jar
SbbX classloader has access to all referenced component classloaders

Actually component class loaders deffer queries to jar domain classloader to avoid that vague ClassCastException described above. Through references in xml descriptor classlaoder association is built(multiple parents - Sbb components usually references events, ras, other sbbs, profiles, etc...) - this is place where multiple parents are introduced. See diagram below, this should give a hint:

Mobicents Diameter - reaches 1.0.2.GA !!!

2009-09-04T13:20:00.000-07:00

Yes, thats true. Me and Alex managed to contribute enough time(even though he was sick and I was busy with personal erands) to make another diameter release. Still follow up will contain standalone documentation (yupieeee!!) with examples of configuration and setup.

More about release here.

Would like to make reminder about VM image we created with openIMS predeployed to make users life a bit easier, atleast for testing:

image.
readme.

Thats it for today. Cheers

3rd Annual Mobicents Metting: Brno 2009

2009-09-04T12:22:00.000-07:00

This august was quiet a big deal, Mobicents Team met in Brno office which was kind enough(or else) to host annual meeting. Almost all of us made it to office without any incident, however we still missed three team members which did not make it.
As usual it was tons of work and work. Since last year mobicents grew a lot (maybe not a good estimate but svn code and commits have been more than doubled, with team not expanding at all) so we had a lot of topics to go through. During las year three of our project reached GA status:

Sip Servlets
Media Server
Diameter

Two other has already got successor:

Media Server
JAIN Slee

In short last year achievements are:

JSR 289 certification (Sip Servlets 1.1)
JSR 240 certification( JSLEE 1.1, achieved by container v2.0.0.B1)
Media Server modular architecture
Diameter GA
Seam Telco Framework reaching stability

During meeting four topics reached level of "hot":

SS7 world mobicents role in IMS cloud
JSLEE 1.1 container architecture
HA
Media Server architecture

(See next post for some cool stuff that we talked about or did not talk )
Thats how we spent our time in the office - except me and Amit killing each other bond style(we were supposed to go for paintball, but eventually it has been canceled).

My main project(aside Diameter and JSLEE) is Media Server for the time beeing. Thats the one me and my co-mates were supposed to cover during this meeting.
However one of our MMS team member did not make it to Brno me and Amit were supposed to cover his topics(MMS Architecture & SS7 introduction) - in practice presentations we created were covered by Amit.
Topics that left for me were

Base HA framework - how to achieve HA for non cache replicated resources
MMS Control protocols(which I did not present, see my other posts)

Seems like very abstract topic, atleast first one. Well thats correct. Moreover its not a trivial one (HA). During my preparations for this subject I made a lot of tests and research to get a hint what lies ahead of team to achieve. Its a bit scary I must tell. It gets insanly complicated since Mobicents covers different EE - just consider case when one has different EEs, different protocols and must provide HA and FT balancer for that bunch - feeling that headache comming?
Aside my HA session we had one covered by Jean D and Vladimir R. Outcome? To make it short:

improve JSIP stack
make JSIP stack modular so it supports replication of data
finalize LB strategy
cooperate on Fault Tolertant Framework

What if FTF? Simple acronym that should in future cover some cool features(See next posts :) ).

What about fun part?
It was not bad at all, even though academic year has not started:

Before plunging into disco:
Get up early, go to work, eat late and party till morning. Here we are at eating part, good food, perfect beer, even portugal folks prefered it over wine:

And here we give a go to extreme sports part, carts made it a day, except few of us getting burns blisters from engine, it was worth chasing other team members around track: