Aayush: weblog

Archive for October, 2009

Integrating Ericsson SDS IMS Simulator with Mobicents and then rocking the house with Eclipse.

Posted by Aayush Bhatnagar on October 17, 2009


In this post, I will explain how to integrate the Service Development Studio (SDS) which emulates the entire IMS core network, the HSS, a DNS server and BGCF etc with the Mobicents communication platform (also called JBCP).

IMS application development and testing could not get any more productive for developers using this combination.

The IMS application server used here on top of Ericsson SDS is the Presence Server deployed on Mobicents.

This post will provide step-by-step instructions to achieve this integration along with informative screenshots:

STEP-1: Download and Install Ericsson Service Development Studio in Eclipse.

I am using Eclipse Galileo for this demonstration.

You can now download the SDS in your eclipse installation by using the Software Updates mechanism (the same way we install plugins). As shown in the figure below, go to HELP and then click on “Install New Software”. Then you add this website for installation:


[I have had queries that this URL is not working when “clicked”. This URL is not supposed to be clicked, but added to the eclipse website updates and installed there]

Once you do so, you should see a list of packages for installation. However, the packages will only be visible if you un-check the option that reads: “Group Items by Category”. Once you do this, you will see the packages that need to be installed.


You will need to accept the license for this software to proceed for installation as shown below:


Once the packages are installed, re-start Eclipse for the changes to take effect. Once you restart Eclipse, you will start seeing the views associated with SDS.

STEP-2: Configure the DNS server of SDS using Eclipse:

Now configure the DNS server with the domain of the Mobicents server hosting the Presence service. For this example I have used a well defined IP address belonging to my laptop. I got this IP by virtue of connecting to the internet. Save the domain name in the DNS server as shown —> presence.mobicents.com


Step-3: Configure the SDS HSS node for service control and service provisioning:

The next step is to configure the HSS.

Go to the HSS view as shown in the figure and configure the Service Trigger Point (SPT) for the Presence Service as shown below. The SPT is for the PUBLISH method, which is used by the presentity to publish their presence status to the server. By defining this SPT, we are telling the S-CSCF to make a routing decision for this message, whenever it is received.


Now, specify the definition of the SPT in the HSS view as shown. Define an initial filter criteria for this service, the SIP application server to be contacted (Mobicents in our case) and the default handling to be undertaken by the S-CSCF, in case Mobicents is not reachable.  The default handling here is SESSION_CONTINUED.


After the initial configurations of the DNS server and the HSS, it is time we start the action.

Step-4: Start the DNS Server:

Start the DNS server by clicking on SDS—>Server—>DNS—->Start DNS as shown in the figure below:


Step-5: Start the Call Session Control Function (CSCF):

Now start the CSCF by navigating to SDS—>Server—>CSCF—>Start CSCF.


Step-6: Start the Test agent acting as an IMS UE:

Now start the test agent by navigating to SDS—>Test Tools—>Start Test Agent as shown below.


Step-7: REGISTER the test agent with the Ericssion IMS SDS core:

Now create a REGISTER request as shown in the figure and register the test agent with the IMS core network. You can provision any number of users in the HSS and register them in the IMS core network.

In the figure, you can see that we can add and remove additional SIP headers as needed by us for testing


After creating the REGISTER request, send it to the IMS core network by clicking on the button and receive the 200 OK. You can also see the call flow in Eclipse that updates itself dynamically as the SIP messaging progresses.


Step-8:  Start Mobicents (JBOSS application server) on your machine:

Here, I am using Mobicents as the application server over IMS. Use the Presence Serve binary given here and start it on your local machine by issuing a run.bat -b <ip-address> command on Windows and a run.sh -b <ip-address> on Linux.

You can download the Presence Server binary from here:


Make sure that JAVA_HOME environment variable is set properly.


Step-9: PUBLISH your presence from the test agent:

Now, using the test agent send a PUBLISH request. Do not forget to add an Event:presence header to the request.


Send the request to the IMS core network. On the basis of our earlier configurations, the PUBLISH message will reach the Presence Server as shown below and is then processed by the Presence Server.


So, you can see, how productive it can be using the right open source tools and projects for IMS service development and testing. It can save you a lot of time and effort by using the right tools.

Instead of struggling with Open IMS core, SDS can be used for IMS emulation. On top of the IMS core, you can use the Mobicents platform for rapid service creation and deployment.

All this can be achieved by JAVA developers using familiar tools (Eclipse workbench) and on the same machine !

So guys, dont wait…try it out !!

Tell me how you liked this demonstration and give me feedback. Please feel free to post here, in case you encountered any problems, or if this demo helped you in any way.

Cheers !

Posted in 3gpp, DNS, Eclipse, Ericsson, HSS, I-CSCF, IMS, Mobicents, P-CSCF, presence, S-CSCF, SDS | 22 Comments »

3GPP IMS Release-9 Highlights and Changes.

Posted by Aayush Bhatnagar on October 13, 2009

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

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

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, postulate 5C, remove any P-Preferred-Identity headers if present.

28. Clarification in postulate 6 of section

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

30. Clarifications for postulate 3 of section

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, P-CSCF now has to remove any P-Preferred-Identity header if present. This is an extra check now.

33. Postulate 3, section, 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 postulate 1A.

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

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

37. Refactoring of point 3 of section 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, 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 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, 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 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, 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 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.

Posted in 3gpp, 3GPP TS 24.229, I-CSCF, IMS, IMS procedures, IMS Release 9, IMS UE, P-CSCF, S-CSCF | 5 Comments »

Introduction to Terminating Identity Presentation/Restriction (TIP/TIR) Service

Posted by Aayush Bhatnagar on October 11, 2009

Similar to OIP and OIR, the TIP and TIR services also have been very common place in legacy networks.

The TIP service enables the calling party to receive the identification information of the remote party from the network. This information is provided to the originating party once the IMS communication has been accepted between the endpoints. The information is delivered regardless of the capability of the handset to process such information at the originating end.

The TIR service provides the terminating party with an option to restrict the identity to be presented to the originating party of the IMS communication.  Logically speaking, it is the reverse of what TIP is.

The TIP and TIR services need some support at the handset’s end as well to function properly. Currently the 3GPP  release is at 8.3 regarding these services.

Posted in IMS, MMTEL, supplementary services, TIP, TIR | Leave a Comment »

Introduction to Originating Identity Presentation/Restriction (OIP/OIR) service

Posted by Aayush Bhatnagar on October 11, 2009

OIP and OIR have been around for a long time in the legacy world.  So, it is no surprise that they have been standardized as part of the IMS architecture.

Even though supplementary services are call control telephony services, and should logically be the part of the CSCF, but they have been pushed to the IMS application layer in the form of a MMtel server.

The OIP service enables the called party to receive a network generated and trusted identity of the calling user on the screen of the mobile device.  The originating user may also present a custom identity to be seen at the called party. The user generated identity is usually screened by the network of the originating user.

The OIR service is invoked when the calling user does not want their identity to be shown to the called party. In such cases, the network of the originating user signals to the network of the called user, to withhold the identity of the calling user.

Both these services are pretty basic in nature, and are being used almost with every mobile phone call we make !

Posted in IMS, MMTEL, OIP, OIR, Services, supplementary services | Leave a Comment »