Brand New logo for the project.
Posted by: whitelassiblog on: May 23, 2009
Hello,
I have uploaded the logo for the project. The colours being used are Red and Blue. I am attaching the logo with this post for your benefit. Please feel free to provide feedback on the logo. The logo signifies simplicity, but in no way compensates on exuberance. 
I hope you like it.
I have also posted the logo on the project group : whitelassi@googlegroups
and at the source code repository: whitelassi@googlecode
IP Short Message Gateway sub-project started.
Posted by: whitelassiblog on: May 22, 2009
Hello,
The IP Short Message Gateway sub-project skeleton was commited in the SVN.
Right now, only the project structure, some JPA classes, project libs and a MySQL script have been commited. In due course of time, the code will start flowing in as per the implementation of the 3GPP standards…
This gateway aims to interwork SMS messages on the SS7 side with the IMS instant messages on SIP. It will also provide deferred deliovery of SIP MESSAGES on the IMS side.
Feel free to browse it at the SVN here: whitelassi-ipsmgw
Feel like contributing ?? Leave a message here, and we can discuss it.
Management Console initial commit
Posted by: whitelassiblog on: April 29, 2009
Some days back, i commited a JSF project skeleton in the SVN, which will eventually become the management console for provisioning and service management.
You can find the commit here: whitelassi-management-console
Contributions in any form are welcome !
The technologies which i plan to use are:
1. JSF RI
2. RichFaces
3. Ajax4JSF
Feel free to chime in with ideas and recommendations for this sub project.
aayush
Managing the whitelassi project using Google Analytics
Posted by: whitelassiblog on: March 15, 2009
Managing an open source project gets easier, when you get to use cool tools such as Google Analytics
I have been monitoring WhiteLassi’s source code repository using Google Analytics service. It provides me with detailed metrics about the project’s visitors and the most browsed and popular content.
Attaching some screenshots of the same :
I get to see detailed metrics about the visitor overview on the GoogleCode project SVN as shown below:
It provides me with a lot of metrics regarding the source of the visits, the aveage pageviews, the viewing time of each page as shown above. I can click on each metric and view more details.
The map overlay feature also lets me know the location of each of the visitors that visited my open source project as shown below:
I also get to see detailed metrics regarding the individual content on the source code repository, by making use of the content mertrics provided by Google Analytics.
I can browse the content by title (most checked out etc) as shown below.
I can also view a consolidated report on the content metrics of the project by having a look at the content overview feature, as shown below:
Moreover, there is a feature of finding out the details on how the visitors came using search engine keywords…..as shown below in the screenshot.
It tells me the traffic distribution, in terms of search engine traffic, referrals and direct visits from other sources. I can get more information on each metric:
One of the most important metrics is visitor loyalty. It shows how many visitors actually come back after visiting my project online. A screen shot of this metric is shown below:
A continuous site benchmark regarding the traffic on the project also helps in finding out the overall popularity of the project over a period of time…as shown in the screenshot below:
Overall, Google analytics provides me with some very valuable information regarding the performance of the project, and the visitors to the project. I strongly recommend all open source projects that are hosted on Google Code, to use this tool and get continuous information regarding project metrics.
Short-term Agenda and roadmap for the project
Posted by: whitelassiblog on: February 5, 2009
Hello,
Since this project has started, there has been steady progress in the form of a healthy code base being setup in the repository in addition to documentation and tutorial links. The core functionality of the PNM registrar is also almost complete. There have been discussions on the group regarding the GUI technology to be used for the PNM communications server.
You can catch the discussions on the GUI HERE and HERE.
Moreover, I have set up the code base for utility SBBs for offline (post-paid) and online (pre-paid) charging on DIAMETER protocol. This is in addition to a utility hook to talk to the IMS HSS. The code and the links to it have been shared on the blog in earlier posts.
I feel this is the right time to consolidate the progress of the project, complete ‘almost completed’ tasks, test them out and chalk out a roadmap for the future, that realizes the final architecture given HERE.
I believe that clubbing together supplementary services from the IMS domain, with a user friendly PNM server will be a good combination. This combination can be made customizable using a GUI console.
Thus, I have chalked out a roadmap and short term agenda for the project:
1. Review the code committed so far.
2. Complete the loose ends.
3. Test the code with sipp scenarios. Fix bugs as and when found.
4. Start the IMS supplementary service design.
5. Finalize the GUI framework and start designing the GUI.
If you feel, that you can contribute in any way to the project, feel free to join in. The GUI is one place where contributions are welcome and needed for example.
Looking forward….
DIAMETER functionality added to PNM Server.
Posted by: whitelassiblog on: January 20, 2009
Hi everyone,
Recently, I have added some support for the DIAMETER interfaces for the PNM Server. As the PNM server behaves as a SIP application server, it needs to account and charge its services over DIAMETER.
The IMS architecture defines 2 interfaces for charging. Pre-paid charging takes place over the Ro Interface, while post-paid charging takes place over the Rf interface.
The SBBs and helper classes for both these interfaces have been commited to the trunk of the googlecode repository.
Moreover, the Sh interface (also on DIAMETER), that the PNM AS shares with the IMS HSS has also been developed and commited to trunk.
The Rf, Ro and Sh interfaces will keep evolving as the Resource Adaptors evolve (Rf RA, Ro RA, DIAMETER base RA, CCA RA and Sh-client RA)
The SIP AS uses the HSS as a metadata repository. A wiki page has been added for explaining the HSS-PNM AS interface. Wiki pages for Ro and Rf interfaces will also be up soon.
Please find below a list of the latest happenings on the forum as well as in the source code trunk:
1. DIAMETER Sh INTERFACE @ GoogleCode
2. DIAMETER Sh INTERFACE POJOS @ GoogleCode
3. DIAMETER Rf INTERFACE @ GoogleCode
4. DIAMETER Ro INTERFACE @GoogleCode
5. DIAMETER Sh interface Wiki page @ GoogleGroups
Check these out…and feel free to contact me in case of any doubts.
In the future, these SBBs will be integrated with call control related SBBs and will integrate to DIAMETER servers (HSS, Online and Offline charging systems)
TODO Activities:
1. Create a WIKI page for DIAMETER Rf interface
2. Create a WIKI page for DIAMETER Ro interface
3. Start the preliminary design tasks for IMS supplementary call-control SBBs.
Any help or contributions are welcome…
Value proposition for PNM-enabled services:
Posted by: whitelassiblog on: December 18, 2008
A fews days ago, I had posted a unified architecture of the whitelassi PNM application server, fully integrated with IMS supplementary services and IMS service enablers such as the XDM server.
The diagram showed the potential of user/device management services such as that of PNM (Personal Network Management). It also gives insight and the value proposition that PNM can enrich and add value to IMS call control services.
The entire architecture can be seen here: PNM-IMS-SERVICE-INTEGRATION
This architecture shows, that a device management framework such as PNM can be leveraged upon to act as a valuable utility for other services as well, especially those services that rely on user preferences and privacy. Some of the services that are shown on the page are listed below. Let us talk about them briefly and discuss the possibilities that they present to us:
1. Wake up Call Reminder service, which the user can configure over SIP or from the GUI.
This service would enable the user to set a wake up call time on the GUI of the PNM server. The PNM application, will read the user’s input from the GUI, and schedule a timer to wake him/her up. This service can also be re-used as a reminder service. Hence, the PNM component here enables the user to manage his preferences and avail of a value added service in the form of Wake up service. The user who owns multiple devices, can also schedule a wake up call on multiple devices if he wishes so !
2. Communication on Hold ( or Call hold) supplementary service.
This is a famous and widely used service in the telecom world. The user can set preferences that whenever an active IMS session is put on hold, a special ringtone is played on the line. These preferences can be set on the GUI and stored as a XML file in the XDM server.
3. Incoming and Outgoing communication barring based on user preferences.
The user can specify preferences on blocking certain numbers (prank callers) on the GUI. Moreover, the PNM controller (master device) can also present restrictions on other devices (PNM controlees), such as those pertaining to parental control.
4. Originating Identity Presentation and Restriction supplementary service.
This is a popular legacy supplementary service that has been carried forward in the SIP and IMS world.
5. Terminating Identity Presentation and Restriction supplementary service.
Same as point 4 above, the only differnence being that this service is invoked for the terminating side of the call.
6. Call Blocking Service (Unconditional and partial)
This is a special variant of communication barring. Similarities can be invstigated further.
7. Intelligent Caller preferences that can be set on SIP or from the GUI.
From the GUI, the user can set multiple preferences, such as those for messaging, call control etc. SIP allows the user to set a variety of preferences to provide a customized experience to the user.
8. Subscriber privacy management based on the rules set on the GUI
The user can set privacy filters on the PNM server, that are enforced during call control. This is an essential enabler for call control supplementary services.
9. Call Screening service (MCID: Malicious Caller Identification)
This service is a variant of lawful intercept. However, it does not intercept the bearer, but only records the call trace and signaling information, that can later be used for security purposes by the operator.
10. Closed User Group Service (CuG), which will drive the Call Forwarding Services, and other group services.
The user can define a closed user group (buddy list) here. This is in addition to the personal network of devices that the user may own. Special services and tariffs can be applied to calls within a CuG.
11. Call Forwarding Service (which has the following variants):
11 a) Call Forwarding Unconditional (CFU)
11 b) Call Forwarding Busy (CFB)
11 c) Call Forwarding No Reply (CFNR)
11 d) Call Forwarding Not Logged in (CFNL)
11 e) Call Forwarding No Reply Conditional (CFNRc)
11 f) Communication Deflection (CD)
This is yet another popular supplementary service: both in the legacy world and the IMS world.
12. Message Waiting Indication service can be coupled with the core PNM logic.
MWI can be extended to all kinds of messages: SMS, IM, MMS and Voicemail. The user can get a reminder or alert that messages are waiting for him to be read/heard !
13. Communication Diversion (CDIV)
Communication sessions can be diverted based on user preferences on the GUI.
14. Explicit Call Transfer (ECT)
This is a variant of third party call control. It enables consultative and immediate transfer of ongoing SIP sessions. The call transfer can be facilitated by the PNM communications server.
So, this is the end game for the PNM server and the actual goal of this open source project:
“To provide value to the users, not by doing something very complicated or great, but by doing the simple things competently. “
By providing the user with simple utilities, everyday services can be enriched and made more user friendly. This is how we can add value to the user-experience for the customer. By clubbing existing services, we can create new ones, while still adding value to existing services.
I invite suggestions/feedback/additions regarding this post and the project in general. Contributions in any form or shape are welcome !!
Best Regards
Aayush
Stage-3 Service description.
Posted by: whitelassiblog on: December 3, 2008
Hello,
We will discuss the Stage-3 service description of the PNM Server in this post. I understand that the Stages 1 and 2 are read and understood.
They can be found here:
It will be helpful if the above two posts are referred in concurrence with this post. It will give a more holistic view of the implementation challenge in front of us.
The Stage-3 service description will be divided into the following parts:
===========================================
AGENDA:
A) Procedures to be implemented as per 3GPP specifications
B) XML Handling procedures
C) Graphical User Interface requirements and integration
D) Forward Path
===========================================
A) Procedures to be implemented as per 3GPP specifications
To put things in perspective, the PNM application server will be acting as a User Agent Server (UAS) in the sense of RFC 3261 and as a third-party registrar. It will also need to initiate SUBSCRIBE requests (UAC) and proxy INVITE requests (proxy server). Procedures of RFC 3261 for these behaviors apply. In addition, the major procedures to be handled by the PNM server are as follows:
1. Accept the REGISTER request from the IMS core network
2. Perform certain checks as per 3GPP TS 24.229 Section 5.7.1, Page 148
3. Schedule a timer for the duration indicated by the REGISTER request
4. Send back a success response to the REGISTER (only if the checks pass)
5. Initiate a SUBSCRIBE request for the ‘reg’ event package
6. Once the subscription is established, schedule a timer for the subscription duration.
7. Expect SIP NOTIFY requests for the duration of the subscription.
8. If a REGISTER with expires=0 is received, cancel the REGISTER timer and also send a SUBSCRIBE with expires = 0 and release the subscription timer.
9. Perform SIP session redirection depending upon the XML policy document stored in the XDM server by the mobile device. This XML document can be seen in 3GPP TS 24.259. All specs can be downloaded from here: WHITELASSI FILES SECTION
10. Point 9 above is subject to defining a new XCAP application usage as given in TS 24.259, in the XDM Server. This is a pending issue and can be viewed here: WHITELASSI ISSUES SECTION
11. Apart from the procedures on SIP, there are procedures that have to be implemented as part of another SBB, which will use the XCAP client resource adaptor and the HTTP servlet Resource adaptor. This SBB will be used to interact with the XDM (XML Document Manager) server for checking the policy document stored as XML and then invoking the relevant procedures on SIP. Details on XCAP protocol are given in RFC 4825. The exact configuration procedures on XCAP are given in 3GPP TS 22.259, 23.259 and 24.259, all of which are downloadable from the WHITELASSI FILES section.
12. Details on what the XDM Server is and how it works are given in the form of a specification in the WHITELASSI FILES section. The document name is OMA-TS-XDM_Core-V2_0-20080916-c.pdf
13. Implement the procedures for a UAC, UAS and proxy servers as per RFC 3261 (keeping them in mind).
The basic call flow is given as below:
—————————————————-
B) XML Handling procedures:
—————————————————-
The very first requirement is to define a new application usage for the XDM server. The XDM server acts as a central XML metadata repository for the PNM Server. The XDM server stores a XML document for each user, which specifies the preferences of the user. During SIP call control, this XML document may be consulted to decide the routing of the call.
For the XDM server to correctly understand and store such per user XML data, an XML application usage has to be added to the XDM server. The procedure for adding an application usage to the XDM server is given here: XDMS application usage addition
Once this application usage is completed, we will need to create a SBB named CallControlSbb. This SBB will take care of the SIP INVITE call control flows and will need to make the InternalXDMClientControlSbb as the child sbb. This child sbb is present in the XDM code.
This CallcontrolSbb will create a child Sbb, which will perform XML lookups during the call to decide the further routing of the call. When we get to implementing the CallControlSbb, i will discuss it in more detail.
————————————————————
C) Graphical User Interface requirements and integration
—————————————————–
The major GUI requirements are outlined here in this thread: GUI Requirements for PNM
The graphical user interface for the PNM server will act as a XCAP client in the context of RFC 4825. The user will log into the GUI, specify his preferences and save them. Upon saving, the GUI application bean class will marshal an XML document as per the XML schema defined in the PNM specifications using the JAXB APIs and create a unique XML document for this user. Then the GUI will insert this document in the XDM server. This will be the PNM user provisioning process flow.
Hence the GUI acts as a XCAP client. The interface between the GUI application and the XDM server is XCAP/HTTP. XCAP is not a seperate protocol in itself, but only rides over HTTP. However, it has its own terminology as explained in RFC 4825. XCAP enables us to create a document tree for the users of PNM server. Each document will be created during the provisioning once, as explained above.
The call controller SBB defined in point B above, will also act as a XCAP client, with the help of InternalXDMClientControlSbb, and will query this document in the XDM server to take routing decisions. Hence from the perspective of the XDM server, there are 2 actors: the GUI applications and the CallControllerSbb, as shown below:
—————————————–
D) FORWARD PATH:
—————————————–
1. Some of the procedures mentioned above are already under works. You can browse the code here: WHITELASSI TRUNK CODE
2. Moreover, it is recommended, that the links given in this post are studied and the documents downloaded from the FILES section.
3. I would be needing help in implementing the CallControllerSbb and integrate it with the Child Sbb.
4. Adding a new XCAP application usage to the XDM Server
5. Start working on the GUI application using JSF/RichFaces technologies and prepare a GUI specification document.
If there are any doubts, leave me a message here.
Regards
Aayush
Project structure and source up in the SVN
Posted by: whitelassiblog on: November 20, 2008
Hello,
The first skeleton of the PNM Server source code has been committed in the Googlecode repository. Now in the coming days, I will be posting the Stage-3 service description, so that members can map the domain knowledge directly with the Source code that has been shared in the SVN
To browse the source code, please visit:
http://code.google.com/p/whitelassi/source/browse/#svn/trunk/whitelassi-PNM-server
I have preserved the entire project structure of a JSLEE project, so that even if you dont have an eclipse plugin installed for JSLEE, you can import the project in eclipse and try it out. However, i recommed that everyone installs the Eclipse plugin. The link can be found in the BLOGROLL on the right side bar of this blog.
For details about the code that has been committed, please refer to this thread:
http://groups.google.com/group/whitelassi/t/ed333a932f3bc287
I invite all members to volunteer to help me out in the coding effort that lies ahead. Any help is appreciated.
Thanks
Aayush
PNM Service: Stage-2 service description
Posted by: whitelassiblog on: October 19, 2008
Hello friends,
I invite a collaborative discussion on the stage-1 service description outlined in this post here:
http://whitelassiblog.wordpress.com/2008/10/05/first-service-personal-network-management-pnm/
Now i will be discussing the Stage-2 service description of the PNM application server. We can club the stage-1 and stage-2 service descriptions together and schedule discussions about the forward path of the project.
This post will provide an introduction of the finer points of the PNM service and will expans further on the actors involved in the development process.
Further blog posts will discuss the call flows and will go to the parameter details.
The stage-2 service description will be divided into the following sections:
————————————————
1) Introduction to Stage-2 service description.
2) The SIP interface and interaction.
3) The XCAP/HTTP interface, interaction and role of XDMS.
4) GUI( Graphical User Interface) requirements for PNM
5) High Level Architectural view.
6) References (domain knowledge)
———————————————–
A) Introduction to Stage-2 service description:
———————————————–
The stage-2 service description will explain the interfaces that the PNM server shares with other IMS network nodes. This service description will also explain the procedures that are to be followed at the given interfaces. The procedures will be followed either on SIP protocol or on HTTP protocol. In the case of IMS, we are XCAP protocol over HTTP. XCAP is totally based upon HTTP protocol and it will be explained in the following sections.
This description will also put into perspective the entire product skeleton and its major functions in an IMS network environment. Wherever possible, the service description will be illustrated with a diagram.
———————————————–
B) The SIP interface and interaction
———————————————–
The Personal Network Management Application server will act as an IMS SIP application server. In the context of IMS, the SIP application servers interact with other IMS elements over the ISC (IMS Service Control) reference point. SIP AS’s are supposed to provide specialized value added services to the customers.
Thus, In our case, the PNM is the service hosted on a SIP AS over the ISC reference point.
An IMS SIP Application server can behave as follows:
1. Terminating User Agent
2. Originating User Agent
3. Proxy Server
4. Back to Back User Agent.
The SIP-AS interacts with the S-CSCF node of the IMS core network. It receives requests from it, and responds to those service requests. When the SIP AS recieves requests, it is known as the Terminating User Agent.
However in certain call scenarios, the SIP AS may even send requests to the IMS core. In such cases, it is known as the originating user agent.
In the case of the PNM server, we will be acting as the terminating user agent as well as the originating user agent.
The PNM AS will receive the SIP REGISTER request from the IMS network (terminating UA). The PNM AS will also send a SIP SUBSCRIBE request to the IMS network (Originating UA). The call flows can be seen at 3GPP TS 23.259. The docs can be downloaded from the trunk at:
http://code.google.com/p/whitelassi/source/browse/#svn/trunk/whitelassi/JSLEEdocs
There are certain call flows that require the PNM AS to behave as a proxy server as well. A proxy server receives requests and proxies them downstream after making some changes to the received request.
———————————————
C) The XCAP/HTTP interface, interaction and role of XDMS.
———————————————
The terminal device (mobile phone) can also directly send requests to the PNM AS. The interface between the mobile terminal and the PNM AS follows the HTTP protocol. However, the mobile terminal uses XCAP as a means of communication over HTTP. XCAP is a protocol based completely on HTTP and borrows its request-response model. The XCAP protocol is used by the terminal to modify configuration settings in the PNM AS. In the context of this service, only the Personal Network Controller (PNC) is authorized to change the configurable settings in the PNM AS. The XCAP protocol is defined in RFC 4825.
In the context of the PNM service, the mobile terminal acts as a XCAP client and the PNM AS acts as a XCAP server. The XCAP server is also known as XDMS (XML Document Management Server). XDM is standardized by the Open Mobile Alliance (OMA) and is recognized as a service enabler. In our case, the service which is being enabled by XDMS is the PNM service. The configuration rules for each user will be stored in the XDMS in XML format by the PNM AS.
The mobile terminal (XCAP client) can change its configurable parameters dynamically by issuing HTTP requests to the XDMS (XCAP server). The resource which is being referred to, by the terminal can be the entire XML document, a particular element of the XML document or even an attribute of a XML element.
An implementation of the XDM server is currently available in the form of Mobicents XDM server. We will reuse it for developing PNM AS.
More details about XCAP and its application to the PNM service is available at these resources:
a) http://www.ietf.org/rfc/rfc4825.txt
b) TS 24.259 @ http://code.google.com/p/whitelassi/source/browse/#svn/trunk/whitelassi/JSLEEdocs
—————————————————-
D) GUI( Graphical User Interface) requirements for PNM
—————————————————-
In order for the mobile terminal to change its configurable information by interacting with the XDMS, a graphical user interface will be needed. This GUI will be rendered on the browser present on the mobile terminal. These are the high level requirements of developing a user friendly GUI for efficient service management by the customers:
1. There shall be 2 user interfaces. One for the customer and one for the operator/administrator.
2. The user will be provisioned manually by the operator using the operator facing interface of PNM AS.
3. The user’s “Service Profile” will be created automatically and stored in the XDM server.
4. The service profile will conform to the XML schema given in 3GPP TS 24.259, Appendix B.
5. Every first time user will be made to register for the PNM service either on the user-facing interface, or the details will be filled in manually by the adminstrator through the operator facing interface. These actions will be carried out by filling up an online form by the user/operator.
6. If the user submits the form, it will be need to be approved by the operator. However, if the operator fills in the details, the service will be provisioned in the XDMS directly.
7. The user will be assigned a username and a password as a result of registration. The user shall use these details to access his personal network information through the browser and make changes to his personal network.
8. After logging into his account, whenever the user SUBMITS any changes to his profile, they will need to be reflected as a XCAP PUT/DELETE etc to the XDM server.
9. The operator facing interface will be used by the operator for managing customers, suspending/activating accounts..collecting statistics..and other administrative actions.
A high level view of the GUI requirements can be seen in the next section.
———————————————-
E) High Level Architectural view
———————————————-
The figure below shows the ecosystem of the PNM application server and its major componants:
The PNM Service consists of the Service Building Blocks that comprise of the PNM service. These Sbbs are deployed on the JSLEE container.
The PNM GUI is the user interface made in either JSPs or JSF.
The XDM server is also a collection of Sbbs, and is presently available to be integrated with the PNM service.
The diagram also shows the various external interfaces of the PNM server and the protocol to be used at each interface. There are predominantly 2 interfaces, namely SIP and XCAP over HTTP as shown:
This diagram seems to be a very simplistic view of the PNM server. As we go along, these functional blocks will keep on growing. Our focus area is the PNM Application Server highlighted in pink colour above.
——————————————-
F) References (domain knowledge)
——————————————-
These are the places to go about understanding the stage-2 service description of PNM:
1) The docs should be downloaded from the SVN repo from here:
http://code.google.com/p/whitelassi/source/browse/#svn/trunk/whitelassi/JSLEEdocs
This location consists of the JSLEE standard, the XDM doc and the 3GPP docs referred above.
2) RFC 4825 for XCAP ( http://www.ietf.org/rfc/rfc4825.txt )
3) XCAP and XDMS important links: http://groups.google.com/group/whitelassi/t/62f95b52ddbbe502
4) RFC 3261 to get conversant with SIP ( www.faqs.org/rfcs/rfc3261.html) as mentioned in some of my previous posts.
I invite comments/ discussions on Stage-1 and Stage-2 service descriptions ! 
Best Regards
Aayush
Blog feed..
- Brand New logo for the project. May 23, 2009 whitelassiblog
- IP Short Message Gateway sub-project started. May 22, 2009 whitelassiblog
- Management Console initial commit April 29, 2009 whitelassiblog
- Managing the whitelassi project using Google Analytics March 15, 2009 whitelassiblog
- Short-term Agenda and roadmap for the project February 5, 2009 whitelassiblog
Recent Comments