Creating,building,deploying and testing projects with Mobicents JAIN SLEE 2.x.y Series

Introduction:

Mobicents 2.x.y series of the JAIN SLEE platform is fully compliant to JSR-240 specification. It has been released to the community recently and I have observed frequent queries by the community on creating and deploying JAIN SLEE services on this platform.

Some of the queries are a common concern to many community members.

Therefore, I decided to write this tutorial for providing a step-by-step process for developing and deploying components on the JAIN SLEE 2.x.y series of the Mobicents platform.

This post assumes that you have basic working experience with tools such as Eclipse and Maven and you are using the JAIN SLEE 2.0.0GA binary distribution. For getting JAIN SLEE 2.0.0 GA, please visit this link: JAIN SLEE 2.0.0 GA Download

This post will cover the following topics:

a) Setting up your environment.

b) Installing necessary plugins and software.

c) Developing a JAIN SLEE project using maven archetypes.

d) Launching Maven builds from command line and from eclipse.

e) Deploying and testing your JAIN SLEE services using an IMS client.

Setting up your environment and software installation:

Before you start, you need to set up your environment properly and need to download and install the requisite software. This includes the following steps:

1. Download the Java Development Kit and install it on your machine.

You can get the JDK from this link: JDK Download

Select the appropriate package depending upon your operating system and set the JAVA_HOME environment variable and set the PATH variable properly. Follow the instructions given on the SUN website for the same.

2. Download and install Maven-2 or higher.

All Mobicents components are ‘mavenized’. You need to get Maven 2 or higher and install it on your machine. Please download and install maven and set the required environment variables (M2, M2_HOME and M2_REPO). Also set the PATH correctly.

You can get maven 2 from this link: MAVEN2

3. Download and install Mobicents Maven plugins.

Mobicents provides some plugins for development. Even though these components are for the JAIN SLEE 1.x.y application components at the time of this post, the maven plugins for JAIN SLEE 2.x.y are expected to be released soon for use with the JAIN SLEE 2.x.y series.

You can download and install these plugins from here:

a. Mobicents maven library plugin

b. Mobicents maven DU plugin

4. Install Maven archetypes and configure the Maven archetype catalog

You need to get the archetypes from the link provided:

a. Mobicents maven archetypes

Now the archetype-catalog.xml file needs to be configured to include these installed archetypes. This is done by including their entries in this file. This file should be present in the .m2 directory of  your installation.  An example file is shown below:

<?xml version=”1.0″ encoding=”UTF-8″?>

<archetype-catalog>

<archetypes>

<archetype>

<groupId>org.mobicents.tools.maven.archetype.slee</groupId>

<artifactId>jain-slee-11-service</artifactId>

<version>1.0.0.BETA2-SNAPSHOT</version>

<repository>http://repository.jboss.org/maven2</repository&gt;

</archetype>

<archetype>

<groupId>org.mobicents.tools.maven.archetype.slee</groupId>

<artifactId>jain-slee-11-library</artifactId>

<version>1.0.0.BETA2-SNAPSHOT</version>

<repository>http://repository.jboss.org/maven2</repository&gt;

</archetype>

<archetype>

<groupId>org.mobicents.tools.maven.archetype.slee</groupId>

<artifactId>jain-slee-11-ra</artifactId>

<version>1.0.0.BETA2-SNAPSHOT</version>

<repository>http://repository.jboss.org/maven2</repository&gt;

</archetype>

<archetype>

<groupId>org.mobicents.tools.maven.archetype.slee</groupId>

<artifactId>jain-slee-11-profile</artifactId>

<version>1.0.0.BETA2-SNAPSHOT</version>

<repository>http://repository.jboss.org/maven2</repository&gt;

</archetype>

</archetypes>

</archetype-catalog>

Please note, that at the time of writing this post, the jain-slee-11-service archetype is not present in the SVN.  It will be committed in the SVN in the future though. You can use the jain-slee-basic-service archetype for Mobicents 1.x.y and edit the descriptors to make it work with the 2.x.y series.

5. Download and install Eclipse Galileo

Please use Eclipse Galileo, as it supports launching MAVEN builds from inside eclipse and you will not need to use the command line interface. Eclipse Galileo can be downloaded from here:

Eclipse Download

Open eclipse and configure your default workbench location. You should see a screen like this for a new installation:

6. Install the m2Eclipse plugin

After downloading eclipse, you need to install the m2eclipse plugin for maven integration with eclipse.

You can use the update site URL given on this link to install this plugin: m2eclipse

Refer to the screenshot on how to do this below.

Go to help —> install new software and then add the update site url as shown below:

7. Download and install Mobicents JAIN SLEE 2.0.0 GA

Download and install the mobicents container from the link given earlier in this post.

8. Download and install a SIP/IMS client

For testing purposes for the sample project explained later in this post, you will need a SIP or IMS client. I have used the Mercuro IMS client for testing. It is freely available here

Creating a basic Mobicents JAIN SLEE project:

1. Create an maven eclipse project:

Create a new maven project in eclipse by going to File —> New —> Other –> Maven Project. The project wizard launched will guide you in the project creation progress as shown in the screenshot below. You can select the archetypes you need for module creation. You may click on the “configure” button to select your archetype-catalog.xml file to see a list of available archetypes.

In this example, we are using the jain-slee-basic-service archetype, as at the time of writing this post the jain-slee-11-archetype is not ready in SVN.

The project modules created will be of the following structure:

|-du
|—src
|—–main
|——-resources
|———services
|-sbb
|—src
|—–main
|——-java
|———…
|——-resources
|———META-INF

If you look in the filesystem, the project parent (root) will have the following content:

It will contain a parent POM file and two modules by the name of “sbb” and “du”

The parent POM file of our example project looks like this:

<project xmlns=”http://maven.apache.org/POM/4.0.0&#8243; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd”&gt;

<modelVersion>4.0.0</modelVersion>

<packaging>pom</packaging>

<artifactId>mobicents-tutorial-parent</artifactId>

<groupId>org.tutorial</groupId>

<version>0.0.1-SNAPSHOT</version>

<modules>

<module>sbb</module>

<module>du</module>

</modules>

<properties>

<!– JBOSS APP SERVER CONFIG RUNNING MOBICENTS –>

<jboss.config>default</jboss.config>

<mobicents.resources.sip11.version>2.0.0.GA</mobicents.resources.sip11.version>

<mobicents.servers.jainslee.version>2.0.0.GA</mobicents.servers.jainslee.version>

</properties>

<dependencyManagement>

<dependencies>

<!–

IMPORTS MOBICENTS JAIN SLEE SERVER

DEPENDENCY MANAGEMENT

–>

<dependency>

<groupId>org.mobicents.servers.jainslee.core</groupId>

<artifactId>mobicents-slee-core</artifactId>

<version>2.0.0-SNAPSHOT</version>

</dependency>

</dependencies>

</dependencyManagement>

<build>

<plugins>

<!– MOBICENTS MAVEN ECLIPSE PLUGIN – use “mvn mobicents:eclipse” to generate eclipse project files –>

<plugin>

<artifactId>maven-eclipse-plugin</artifactId>

<groupId>org.mobicents.tools</groupId>

<version>1.0.0.BETA2</version>

<inherited>false</inherited>

<executions />

</plugin>

<!– JAVA COMPILER CONFIG –>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

<configuration>

<source>1.5</source>

<target>1.5</target>

<debug>true</debug>

</configuration>

</plugin>

<!– JARS MANIFEST FILE SETUP –>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-jar-plugin</artifactId>

<configuration>

<archive>

<manifest>

<addDefaultSpecificationEntries>

true

</addDefaultSpecificationEntries>

<addDefaultImplementationEntries>

true

</addDefaultImplementationEntries>

</manifest>

</archive>

</configuration>

</plugin>

</plugins>

</build>

<!– JBOSS MAVEN REPOSITORIES –>

<repositories>

<repository>

<id>jboss</id>

<name>JBoss Repository</name>

<url>http://repository.jboss.org/maven2</url&gt;

<snapshots>

<enabled>false</enabled>

</snapshots>

</repository>

<repository>

<id>jboss-snapshots</id>

<name>JBoss Snapshot Repository</name>

<url>http://snapshots.jboss.org/maven2</url&gt;

<releases>

<enabled>false</enabled>

</releases>

<snapshots>

<enabled>true</enabled>

</snapshots>

</repository>

</repositories>

<pluginRepositories>

<pluginRepository>

<id>jboss</id>

<name>JBoss Plugin Repository</name>

<url>http://repository.jboss.org/maven2</url&gt;

<snapshots>

<enabled>false</enabled>

</snapshots>

</pluginRepository>

<pluginRepository>

<id>jboss-snapshots</id>

<name>JBoss Snapshot Plugin Repository</name>

<url>http://snapshots.jboss.org/maven2</url&gt;

<releases>

<enabled>false</enabled>

</releases>

<snapshots>

<enabled>true</enabled>

</snapshots>

</pluginRepository>

</pluginRepositories>

</project>

This POM files lists its two child modules, the JBOSS repository URLs, the configuration of the target JBOSS AS in which we want to deploy our components, the java compiler configurations and the plugins we need for generating the eclipse files for mobicents projects.

The SBB module will have the following content:

It consists of the src folder. Inside this folder we have a hierarchy. The src/main/java folder contains your source code. The src/main/resources folder contains your sbb-jar.xml deployment descriptor file.

The pom file of the SBB module is as follows:

<project xmlns=”http://maven.apache.org/POM/4.0.0&#8243; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd”&gt;

<modelVersion>4.0.0</modelVersion>

<parent>

<artifactId>mobicents-tutorial-parent</artifactId>

<groupId>org.tutorial</groupId>

<version>0.0.1-SNAPSHOT</version>

</parent>

<artifactId>mobicents-tutorial-sbb</artifactId>

<dependencies>

<dependency>

<groupId>org.mobicents.resources</groupId>

<artifactId>sip11-ratype</artifactId>

<version>2.0.0.BETA2</version>

<scope>runtime</scope>

</dependency>

</dependencies>

</project>

The deployable unit module will have the following structure:

It will consist of the src folder just like the sbb module did. Under the src/main/resources/services folder you will have your JAIN SLEE service.xml file.

The pom file looks like this for this module:

<project xmlns=”http://maven.apache.org/POM/4.0.0&#8243; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd”&gt;

<modelVersion>4.0.0</modelVersion>

<packaging>pom</packaging>

<parent>

<artifactId>mobicents-tutorial-parent</artifactId>

<groupId>org.tutorial</groupId>

<version>0.0.1-SNAPSHOT</version>

</parent>

<artifactId>mobicents-tutorial-du</artifactId>

<dependencies>

<dependency>

<artifactId>mobicents-tutorial-sbb</artifactId>

<groupId>${pom.groupId}</groupId>

<version>${pom.version}</version>

</dependency>

</dependencies>

<build>

<plugins>

<plugin>

<groupId>org.mobicents.tools</groupId>

<artifactId>maven-du-plugin</artifactId>

<extensions>true</extensions>

<configuration />

<executions>

<execution>

<phase>install</phase>

<goals>

<goal>create</goal>

</goals>

</execution>

</executions>

</plugin>

<plugin>

<artifactId>maven-antrun-plugin</artifactId>

<executions>

<execution>

<id>deploy-DU</id>

<phase>install</phase>

<goals>

<goal>run</goal>

</goals>

<configuration>

<tasks>

<copy overwrite=”true” file=”target/${project.build.finalName}.jar” todir=”${jboss.home}/server/${node}/deploy” />

</tasks>

</configuration>

</execution>

<execution>

<id>undeploy-DU</id>

<phase>clean</phase>

<goals>

<goal>run</goal>

</goals>

<configuration>

<tasks>

<delete file=”${jboss.home}/server/${node}/deploy/${project.build.finalName}.jar” />

</tasks>

</configuration>

</execution>

</executions>

</plugin>

</plugins>

</build>

</project>

The project structure is shown below:

2. Populate your SBB code:

Now, we are ready to do some coding. This example contains two event handler methods. The first event handler method is called when the service is first started by the JAIN SLEE container. It is marked as the onServiceStartedEvent (args).

In this event we check whether it is our service that is starting and attach to the service activity if that is the case.

This event is declared in the sbb-jar.xml file as follows:

<event event-direction=”Receive” initial-event=”True”>

<event-name>ServiceStartedEvent</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>

The source code for this event is generated by the maven plugin.

The second event handler of our project is the onRegisterEvent. This event is supposed to send back a 200 OK for the incoming request on the SIP server transaction activity and then construct and send a MESSAGE to the SIP client on the client transaction activity.

This method is declared in the sbb-jar.xml as follows:

<event event-direction=”Receive” initial-event=”True”>

<event-name>RegisterEvent</event-name>

<event-type-ref>

<event-type-name>javax.sip.message.Request.REGISTER</event-type-name>

<event-type-vendor>net.java.slee</event-type-vendor>

<event-type-version>1.2</event-type-version>

</event-type-ref>

<initial-event-select variable=”ActivityContext” />

</event>

The source code for this method is as follows:

public void onRegisterEvent(RequestEvent event, ActivityContextInterface ac)

{

tracer.info(“REGISTER REQUEST RECEIVED AT MY SBB”);

Request register = event.getRequest();

ServerTransaction st = event.getServerTransaction();

FromHeader from = (FromHeader) register.getHeader(FromHeader.NAME);

ContactHeader contact = (ContactHeader)register.getHeader(ContactHeader.NAME);

tracer.info(“SENDING REPONSE TO THE REGISTER REQUEST”);

try{

st.sendResponse(messageFactory.createResponse(Response.OK, register));

tracer.info(“SENDING AN INSTANT MESSAGE TO THE CLIENT”);

Address fromNameAddress = addressFactory

.createAddress(“sip:mobicents-jain-slee@mobicents.org”);

fromNameAddress.setDisplayName(“Mobicents JAIN SLEE 2.0.0″);

FromHeader fromHeader = headerFactory.createFromHeader(

fromNameAddress, Utils.getInstance().generateTag());

List<ViaHeader> viaHeaders = new ArrayList<ViaHeader>(1);

ListeningPoint listeningPoint = provider.getListeningPoints()[0];

ViaHeader viaHeader = provider.getHeaderFactory()

.createViaHeader(listeningPoint.getIPAddress(),

listeningPoint.getPort(),

listeningPoint.getTransport(), null);

viaHeaders.add(viaHeader);

ContentTypeHeader contentTypeHeader = headerFactory

.createContentTypeHeader(“text”, “plain”);

CSeqHeader cSeqHeader = headerFactory.createCSeqHeader(2L,

Request.MESSAGE);

MaxForwardsHeader maxForwardsHeader = headerFactory

.createMaxForwardsHeader(70);

provider.getNewClientTransaction(messageFactory.createRequest(contact.getAddress().getURI(),

Request.MESSAGE, headerFactory.createCallIdHeader(“mobicents”+System.currentTimeMillis()),

cSeqHeader, fromHeader, headerFactory.createToHeader(from.getAddress(),null),

viaHeaders, maxForwardsHeader, contentTypeHeader, “Welcome to Mobicents JAIN SLEE 2.0 series”))

.sendRequest();

}catch(Exception ex){

ex.printStackTrace();

}

tracer.info(“REQUEST GREETING SENT..”);

}

The other important method of this SBB is the setSbbContext method. This is where we populate the resources being used in the SBB including JAIN SLEE facilities and Resource Adapter factories.

The code for this method looks like this:

/**

* Called when an sbb object is instantied and enters the pooled state.

*/

public void setSbbContext(SbbContext context) {

this.sbbContext = context;

this.tracer = context.getTracer(RootSbb.class.getSimpleName());

try {

sbbEnv = (Context) new InitialContext().lookup(“java:comp/env”);

provider = (SleeSipProvider) sbbEnv.lookup(“slee/resources/jainsip/1.2/provider”);

messageFactory = provider.getMessageFactory();

headerFactory = provider.getHeaderFactory();

addressFactory = provider.getAddressFactory();

tracer.info(“setSbbContext(…)”);

} catch (NamingException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

3. Deployment descriptors:

There are two major deployment descriptors: sbb-jar.xml and service.xml

The sbb-jar.xml file looks like the one shown below. It contains the events that the SBB listens to and the SIP resource adapter configuration:

<?xml version=”1.0″?>

<!DOCTYPE sbb-jar PUBLIC “-//Sun Microsystems, Inc.//DTD JAIN SLEE SBB 1.1//EN”

“http://java.sun.com/dtd/slee-sbb-jar_1_1.dtd”&gt;

<sbb-jar>

<sbb>

<description />

<sbb-name>mobicents-tutorial SBB</sbb-name>

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

<sbb-version>0.0.1-SNAPSHOT</sbb-version>

<sbb-classes>

<sbb-abstract-class reentrant=”False”>

<sbb-abstract-class-name>org.tutorial.mobicents_tutorial.RootSbb</sbb-abstract-class-name>

</sbb-abstract-class>

</sbb-classes>

<event event-direction=”Receive” initial-event=”True”>

<event-name>RegisterEvent</event-name>

<event-type-ref>

<event-type-name>javax.sip.message.Request.REGISTER</event-type-name>

<event-type-vendor>net.java.slee</event-type-vendor>

<event-type-version>1.2</event-type-version>

</event-type-ref>

<initial-event-select variable=”ActivityContext” />

</event>

<event event-direction=”Receive” initial-event=”True”>

<event-name>ServiceStartedEvent</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>

<resource-adaptor-type-binding>

<resource-adaptor-type-ref>

<resource-adaptor-type-name>

JAIN SIP

</resource-adaptor-type-name>

<resource-adaptor-type-vendor>

javax.sip

</resource-adaptor-type-vendor>

<resource-adaptor-type-version>

1.2

</resource-adaptor-type-version>

</resource-adaptor-type-ref>

<activity-context-interface-factory-name>

slee/resources/jainsip/1.2/acifactory

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

<resource-adaptor-entity-binding>

<resource-adaptor-object-name>

slee/resources/jainsip/1.2/provider

</resource-adaptor-object-name>

<resource-adaptor-entity-link>

SipRA

</resource-adaptor-entity-link>

</resource-adaptor-entity-binding>

</resource-adaptor-type-binding>

</sbb>

</sbb-jar>

The JAIN SLEE service.xml descriptor looks like the one shown below:

<?xml version=”1.0″ encoding=”utf-8″?>

<!DOCTYPE service-xml PUBLIC “-//Sun Microsystems, Inc.//DTD JAIN SLEE Service 1.1//EN”

“http://java.sun.com/dtd/slee-service-xml_1_1.dtd”&gt;

<service-xml>

<service>

<description/>

<service-name>mobicents-tutorial SLEE Service</service-name>

<service-vendor>org.tutorial</service-vendor>

<service-version>1.1</service-version>

<root-sbb>

<description/>

<sbb-name>mobicents-tutorial SBB</sbb-name>

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

<sbb-version>0.0.1-SNAPSHOT</sbb-version>

</root-sbb>

<default-priority>0</default-priority>

</service>

</service-xml>

4. Build your code:

For building the project, make sure JBOSS_HOME is set. Then right click on mobicents-tutorial-parent and go to run-as. Now click on maven install.

As a result of this operation, the DU will be compiled and deployed in the JBOSS AS.

Refer to the screenshot below:

5. Deploy your binaries:

If you JBOSS_HOME variable is not set, then the binaries will be copied to the mobicents-tutorial-parent\du\${jboss.home}\server\${node}\deploy directory. You can manually copy and paste this binary to the /deploy directory of JBOSS AS.

6. Test the service:

Use an IMS or a SIP client. I have used Mercuro. Configure 127.0.0.1:5060 as the outbound proxy for the client and then register with Mobicents JAIN SLEE server.

For Mercuro, you will see the result as shown in the screenshot below:

Conclusion:

If you have right tools by your side, then creating projects, developing, deploying and testing your logic can be a smooth process.

If you found this post useful, then please let me know. Your feedback is valuable.

3GPP IMS Release-9 Highlights and Changes.

3GPP IMS Release- 9 has been around for some months now.

From the IMS core network perspective, there have been certain additions and modifications to the procedures given in TS 24.229.

This specification acts as the ‘bible’ for any vendor wishing to implement IMS. This specification also changes and updates itself very frequently and usually comes with scores of additions and modifications in its quarterly minor releases.

Some of the major highlights of Release 9 are discussed.

The current release at the time of this post is 9.1.0 which is being discussed here.

As these changes are very low-level and implementation specific, it seems that there is still heavy refactoring going on in 3GPP for aligning the procedures for IMS and coming out with a stable set of procedures (atleast for the core network entities).

Such changes can be very difficult to spot and implement from the developer’s perspective.  Some changes given below can even force you to modify some of your use cases. Personally speaking, it becomes very frustrating when the procedures change so frequently. Atleast, there should be no changes/bugs in the core procedures of the IMS nodes.

IMPORTANT NOTE: Read on at your own risk. Not for the weak at heart.

Highlights, Changes and Additions:

1. Clarification in UE procedures for sending requests on protected ports to the P-CSCF regarding subsequent registration requests.

2. Addition and clarification in UE procedures regarding the usage of the ‘outboud’ parameter in the Supported header. It also includes a check whether the ‘reg-id’ and “+sip.instance” Contact header field parameters are present in the 200 OK of the REGISTER request.

3. Elaboration on the decision making of the UE regarding the S-CSCF behavior,  if the ‘outbound’ parameter was not present in the 200 ok for the REGISTER.

4. A note providing an implementation option to the UE in case Timer F expires at the SIP Stack.

5.  Change of procedures on the number of REGISTRATION attempts by the UE and in case of failure, the procedures that follow it (exception handling).

6. Removal of procedures at the UE that needed a check for Retry-After header for re-attempts for Registration.

7. Removal of procedures at the UE (2 postulates) when it sends a SUBSCRIBE to the network.

8. Removal of a check at the UE for sending a SUBSCRIBE for the debug event package.

9.  Addition of a postulate for generic procedures except the REGISTER request handling where now the protected port has to be added by the UE in the Contact header.

10. Refactoring of the abnormal exception handling use cases at the UE when it receives 504 error response.

11. Refactoring of procedures for emergency call handling at the UE and parsing responsibilities of the 3GPP IMS XML file received from the network

12. Additional responsibility at the UE to advertize support for draft-ietf-sipcore-keep for emergency IMS sessions.

13. Major refactoring on pages 92 and 94 regarding the interpretation of certain XML elements for emergency sessions initiated by the UE when it was registered using non-emergency registration procedures.

14.  Clarification note in P-CSCF procedures regarding protected ports in section 5.2.2.1

15.  P-CSCF procedural support for draft-ietf-sip-outbound, and addition of the ‘ob’ parameter in the SIP URI.

16. P-CSCF procedural support for draft-ietf-sipcore-keep

17. Clarification on point 6 for P-CSCF registration procedures when the request needs to be sent to an I-BCF

18. Change in point 7 of P-CSCF registration procedures in case the request has to be sent to the I-CSCF

19. Clarifications in points 8 and 9 of P-CSCF registration procedures while dealing with a UE behind a NAT and alignment with draft-ietf-sipcode-keepalive.

20. P-CSCF can now not close the TCP connection with the UE in case it has been detected to be behind a NAT !

21. P-CSCF can add the “received” parameter and the “rport” parameter in case SIP Digest without TLS is being used as the security mechanism with that UE.

22. Additional check at the P-CSCF in case SIP Digest WITH TLS is being used, that the FQDN in the Contact header resolves correctly to the IP Address bound to that TLS session. Here the P-CSCF will perform a reverse DNS query !

23. P-CSCF has to check whether there is an I-BCF in the network while sending out SUBSCRIBES to reg event packages. If there is no I-BCF, do a DNS lookup and send it to the I-CSCF, else send it to the I-BCF.

24. Major refactoring of procedures for the P-CSCF for general request handling in Section 5.2.6.3.1

25. Inspection of the host portion of the sent-by field of the Via header received from the UE at the P-CSCF. Check whether the IP address given there differs from the source IP from where the packet was originally received. Also add the UEs protected server port over there.

26. P-CSCF abnormal cases postulate (a) asks it to add some elements of the 3GPP IM CN subsystem XML body while sending an error response.

27. P-CSCF procedures, initial request for a dialog handling procedures, Section 5.2.6.3.3, postulate 5C, remove any P-Preferred-Identity headers if present.

28. Clarification in postulate 6 of section 5.2.6.3.3.

29. P-CSCF procedures, section 5.2.6.3.11, postulate 2A now asks to remove P-Preffered-Identity header if present

30. Clarifications for postulate 3 of section 5.2.6.3.11

31.  P-CSCF procedures for generic response handling now require the inspection of the rport and received parameters before sending out any responses to the UE.

32.  In section 5.2.6.4.4, P-CSCF now has to remove any P-Preferred-Identity header if present. This is an extra check now.

33. Postulate 3, section 5.2.6.4.4, P-CSCF needs to remove the “comp” SIP URI parameter from the Record-Route header.

34.  P-CSCF needs to remove the P-Preferred-Identity field in section 5.2.6.4.8 postulate 1A.

35. Clarification that the P-CSCF needs to support draft-ietf-sip-outbound in addition to 3261 for section 5.2.6.4.8 while deciding upon the forwarding the request to the UE.

36.  Major refactoring additions of the procedures for the P-CSCF in section 5.2.10.3 postulate 1A. Some 3-4 checks have been added.

37. Refactoring of point 3 of section 5.2.10.3. Point 3 has been changed to align towards draft-ietf-sipcore-keep. So this postulate needs to be re-implemented.

38. Inspection and addition of the 3GPP IMS XML schema elements in section 5.2.10.4, postulate OA, points II and IV.

39.  Major major refactoring, removal and additions in the procedures of the P-CSCF in points 1, 1A, 2 and 3 of section 5.2.10.4. Almost everything has been modified here ! Reimplementation required.

40.  P-CSCF abnormal exception handling procedures aligned to the processing of the 3GPP IMS XML body.

41. S-CSCF procedures for initial registration have to inspect the P-Access-Network-Info header to decide the authentication scheme to use for the UE.

42. S-CSCF procedures for receiving an unprotected register request additions to handle the REGISTER from an MSC enhanced ICS node.

43. S-CSCF derivation of IMPI for NASS IMS bundled authentication in case  the Authorization header is missing.

44. S-CSCF inspection of the “reg-id” parameter, the “ob” parameter and the “outbound” parameter in case of IMS AKA authentication, and sending of a 439 response.

45. S-CSCF procedures section 5.4.1.2.2, point 11 has almost been scrapped and the earlier checks removed.

46.  Digest URI need not match the SIP URI in case a reg-await-auth timer is running and SIP Digest is the mechanism used at the S-CSCF for authentication.

47. Inspection of the Authorization header to contain the “auth-done” parameter at the S-CSCF.

48. Clarification for the <ims-3gpp> element in 3rd party registration procedures.

49. Check for P-Served-User header in S-CSCF procedures section 5.4.3.2 and associated procedures if its not present.

50. Addition of the P-Asserted-Identity header in the 504 response at the S-CSCF and the <ims-3gpp> element as well in the body.

51. Section 5.4.3.3, points 10 a and 10d of S-CSCF procedures have undergone major additions and refactoring. Re-implement it.

52. Removal of authentication parameter checks in point 3 section 5.4.3.6.1 of the S-CSCF procedures.

I hope you all enjoyed this list. What it does to the developer is, that you go in a forced fixing loop and your focus goes away from adding more features…..to fixing existing ones and aligning them to the standard !

I just hope that we do not get a list of such major changes in the procedures in the next incremental release.

Please note, that these changes only account for those in the procedures of the UE, P-CSCF and S-CSCF. I-CSCF was fortunately untouched in this 3GPP Release. There might be many more changes in the procedures of other nodes such as the BGCF, MGCF, I-BCF, E-CSCF etc…which i have not listed here.