Management Console initial commit

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

Value proposition for PNM-enabled services:

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

Service Design Processes and lifecycle at whitelassi !

Hello dear readers, 

This post will describe the requisite processes to be followed by us all to go about our development activities. It is important at this very nascent stage of the project itself to properly and clearly define the processes to be followed by us all to bring some uniformity in our functioning and better co-operation and understanding during development.

You will need some patience to go through this post, as it is very long..so please hold on  

—————————————

Every service that we intend to develop will go through 5 phases of design and development. Let us fix this as  standard processes for systematically designing all our future services.

These phases shall be :—>

1) Service Description and illustration. 

2) High level and Detailed Level software design

3) Implementation over JSLEE

4) Testing and bug fixing.

5) Product release.

These 5 phases will be discussed in detail in the remainder of this post. 

———————————–

A) Service Description and illustration explained:

A1) Stage-1 service description:

Every service should have a description, as perceived by the human user. Such a description is called a stage 1 service description. The stage 1 description of any service should clearly define and present the business use case for that service and how that service will be experienced by the customers in production. This description should clearly present the motivation behind developing such a service. The description should be concise, non technical and understandable to the common man…who may or may not be a developer. Once the stage 1 description is over, the developer is in the correct mindset to pursue his design objectives.

A2) Stage-2 service description:

Upon reaching this stage, we would have completely understood the production environment functioning of the product due to the stage 1 description above. Now we shall examine and document the environment of our product node. The product environment implies the various external and internal interfaces of the product package. External interfaces can be those with other SIP servers over a standardized reference point (such as the IMS ISC reference point with the S-CSCF). Another example of an external interface can be that with a charging platform (over DIAMETER protocol). An external interface can be that with a human user managing the product through a service management point (SMP). Internal interfaces will be something that will need to be decided carefully. Internal interfaces will consist of the internal signaling between the different software components. These components will usally be service building blocks (SBBs), or in certain cases, a management point used for provisioning. Other examples of internal interfaces can be those with databases, remote API calls,  with a statistics collection utility packages, XML document managers and so on. The roles of each and every interface will be captured as a stage-2 description. This will help us immensely while designing the product. The stage-2 description will document all the procedures over each internal and external interface. Special requirements (if any) shall be documented seperately and will be highlighted. 

A3) Stage-3 service description:

Upon reaching this stage, we would have completely understood how the service functions, which are the major actors of the service, what are its major internal packages and external dependencies. Now we will move to the next stage…which can be considered as a pre-design stage. In every telecom service or product, the developer is provided with a set of call flows. These call flows capture the signalling ( in our case it will be SIP and HTTP) between the various network nodes. The call flows go into the minutest of details..at the parameter level. What message enters which node…what changes take place to the message at that node and what message leaves a particular node…everything is captured here. This stage is very important in SIP and IMS, as the call flows will determine the exact FSM (Finite state machine) to be followed at our node, the call context to be maintained at our node and the exact structure of each message request reaching us. The call flows are present in the 3GPP documents most of the times, so we will just need to identify the relevant ones and understand them deeply. If any new call scenarios, outside the standards pop up, we will capture them at this stage.

————————————

B) High level and Detailed Level software design explained:

Most of us are very well versed with HLD and DLD stages. At this stage we will be  identifying and defining the UML use cases, classes and interfaces to be used on the basis of the stage 1,2 and 3 service descriptions done earlier. This will be the correct time to consider any design patterns that may satisy certain scenarios of the product functionality. All the UML diagrams will be drawn by using a standard open source tool called Star UML. Star UML is freely downloadable from here:  http://staruml.sourceforge.net/en/download.php

At this stage we will get a clear picture of our implementation. However, in JSLEE, there will also be a need for correctly identifying the SBBs and defining their relationships correctly. As a matter of fact, a good design will heavily depend upon how efficient our SBB design is. Each class (it may or may not be a SBB) will be represented as a UML diagram complete with its instance variables, methods, their arguments, return types etc. The relationships between various classes and interfaces will also be shown.

 The SBB design practice links are given under the “imp-links” tab and also as points 7 of this post: 

http://whitelassiblog.wordpress.com/2008/09/24/proposed-programming-model-and-user-orientation/ 

Please check it out. 

The SBBs will need to be designed in such a way that they can be reused in any future services if possible. Such design decisions will be taken only after a proper discussion and consensus amongst all. The entire discussion process will be summarized and documented for later reference. 

————————————

C) Implementation over JSLEE: 

This will be the actual implementation stage of the product. During this stage, we will refer back to our design documents and also the procedures given in the 3GPP specifications. The specifications have been written in such a way, that there is no need for making use-case specifications ourselves. We will just follow what is given in the spec…line by line. It will be required to cross refer other 3GPP specs or IETF RFCs during this phase. I will enlist all the resources required as and when the time comes. We will follow a common policy of commenting our code extensively. Whenever we are implementing a certain procedure from the specification/RFC, we will copy and paste that procedure in the code as a means of reference for others. This will make our code readable and understandable for others. Let this commenting policy be followed uniformly by us all. We will also schedule frequent code reviews and discuss each and every line of our implementation, and release a MoM (Minutes of the Meeting). 

————————————

D) Testing and Bug Fixing:

Once the product implementation has reached a certain stage, we will test it thoroughly. We will utilize sipp as a tool for testing SIP based implementations. On the HTTP front, we will use SEAGULL as the testing tool. Unit testing will also take place in the form of JUnit and/or Sip Unit. We will also make a test case document, where we will capture the test name, its nature, expected result and whether or not the test succeeded. If there are any bugs, they will be listed in the document and assigned to the developer. All bug fixes will also be documented alongwith the date on which the bug was fixed. 

————————————

E) Product Release:

Finally, when the product has reached a certain level of maturity, it will be released and uploaded to the repository with a user guide giving step by step instructions on how to play around with it. Upon getting feedback from the community, the product will be enhanced further. 

—————————————–

I hope this has set the ball rolling as far as the processes are concerned. 

If there are any doubts, please contact me personally at : abhatnagar192006@gmail.com

Else drop a message at the mailing list: users@whitelassi.dev.java.net 

 

Best Regards

Aayush

Proposed programming model and user orientation.

Hello everyone, 

What i suggest is that you guys join the project at http://whitelassi.dev.java.net and then subsequently subscribe to the mailing list users@whitelassi.dev.java.net 

The projects that will be undertaken by the community members of this open source project will need to first understand the proposed programming model of the services that are going to be built. I will discuss the first service for this project in the coming posts.

Any service delivery platform requires a highly scalable, transactional, highly available and extensible programming model. 

For satisfying the above mentioned requirements, the White Lassi open source project will base its development on the JSLEE (JSR 240) programming model. 

I suggest that you all download the specification from the link given in the blogroll on the right hand side bar. Apart from the specification, also see the online tutorials about JSLEE from the SLEE-Tutorials tab of this blog: http://whitelassiblog.wordpress.com/slee-tutorials/ 

JSLEE is an event driven powerful architecture. An implementation of this standard exists in the form of the Mobicents open source project. The link for Mobicents can also be found from the sidebar. There is another implementation of the JSLEE standard that has been carried out by Open-cloud ( A new zealand based firm). However, it is not open source. However, we can use its documentation links for our understanding.

For new community members the orientation schedule will consist of the following phases: 

A) Acquiring the domain knowledge of JSLEE programming practices and concepts. 

B) Getting conversant with SIP and IMS SIP ( used as a signaling protocol) 

I have mentioned SIP and IMS SIP seperately for a reason. This will be clarified later in this post. 

A)JSLEE Programming model first steps

1) Browse the Mobicents JSLEE FAQs at http://www.mobicents.org-a.googlepages.com/faq.html

and the documentation at http://groups.google.com/group/mobicents-public/web/user-guide?pli=1

2) Download the specification (JSR 240) and get some idea of whats going on in the JSLEE programming model. (download link in blog sidebar)

3) To download the Mobicents binary, which comes bundled with the JBOSS application server (4.2.2 GA currently) from  http://www.mobicents.org/jainsleedownload.html

JBOSS and Mobicents are open source and a part of Red Hat inc. 

4) Download and install the eclipse plugin for JSLEE from: http://nchc.dl.sourceforge.net/sourceforge/mobicents/mobicents-eclipslee-1.2.3.BETA.zip

5) Browse through the example SBBs (Service Building Blocks) which come along with the distribution.

6) Join the Mobicents users forums at: http://forums.java.net/jive/forum.jspa?forumID=55

7) Apart from reading the specification, it is highly recommended that these links are read very carefully and thoroughly. They will provide precious information about the JSLEE model: https://developer.opencloud.com/devportal/display/OCDEV/Hints+and+Tips+for+Writing+Well+Performing+SLEE+Applications

https://developer.opencloud.com/devportal/display/OCDEV/Hints+and+Tips+for+Debugging+SLEE+Applications

and other links on this portal….it will be very useful. 

For getting a hands-on with the SBBs, the best place is the Mobicents binary. It contains some very good examples for getting you started. 

 

Service Building Blocks (SBBs) are a central concept of JSLEE and they contain the actual business logic of any application developed on top of JSLEE.

Any applications that we plan to build on top of JSLEE will be composed of numerous SBBs. The challenge lies in understanding the runtime environment of a SBB, how it functions, its dependancies and its best programming practices. 

 

These steps are important for getting a reasonable grip on the programming subject matter.

B) Getting conversant with SIP and IMS SIP ( used as a signaling protocol) 

The Session Initiation Protocol (SIP) is the protocol used for session setup, maintenance, and teardown. For getting an introduction to SIP, i believe these links will be valubale:

SIP is standardized by RFC 3261: www.faqs.org/rfcs/rfc3261.html

Moreover, if there is any SIP related doubt in RFC 3261 or otherwise, please put it on the mailing list of this project: users@whitelassi.dev.java.net 

SIP as given in RFC 3261 is only VoIP (Voice over IP) SIP. But, in this open source endevour, we have to satisfy the requirements of the IMS(IP Multimedia Subsystem) customer. 

IMS is essentially a wrapper over SIP. The IMS also uses SIP for session setup and teardown, but there are many more RFC’s that are defined as extensions to RFC 3261 for supporting IMS. 

As IMS is being standardized by 3GPP, the standards can be found at: 

http://www.3gpp.org/ftp/Specs/html-info/22-series.htm (Stage 1)

http://www.3gpp.org/ftp/Specs/html-info/23-series.htm  (Stage 2)

and

http://www.3gpp.org/ftp/Specs/html-info/24-series.htm (Stage 3)

However it is not recommended to go through these standards as yet. RFC 3261 is most important to start with. In a subsequent blog post, where i will be describing our first service, I will provide a plan on how to tackle IMS domain knowledge in a concise and systematic way. 

Remember, that if you understand RFC 3261 SIP, then IMS will be easy to understand..as it is TOTALLY based upon SIP. 

I  hope this information was useful and it has defined a logical path to move forward for any community member who wishes to join in this project. 

If there are any questions/queries/confusions….please drop a comment here…and i will respond. 

You can also drop me a mail at: abhatnagar192006@gmail.com 

I will discuss our first MAJOR service in subsequent posts.

Best Regards

Aayush