IMS-Part6 User Profile and Provision of Services

Study Program Master Telecommunications and Internet Technologies
Course Application Prototyping
LECTURE NOTE 6
Version: Datum: 2.1 30. 03. 2009
IP MULTIMEDIA SUBSYSTEM (IMS)

User Profile and Provision of Services
Dipl.-Ing. Franz Edler
Part 6: User Profile and Provision of Services
CONTENTS:
1. Overview ....................................................................................................................................... 3 1.1. Content of the course ............................................................................................................. 3 1.2. Structure of the course ........................................................................................................... 3 1.3. Preconditions and further readings and exercises ................................................................. 3 1.4. Questions and exercises ......................................................................................................... 4 1.5. Target audience ...................................................................................................................... 4 2. User Profile ................................................................................................................................... 5 2.1. Structure of the User Profile .................................................................................................. 5 2.2. Filter Criteria.......................................................................................................................... 6 3. A Service Example ....................................................................................................................... 9 4. Application servers .....................................................................................................................11 4.1. Application Server interfaces ..............................................................................................11 4.2. Integration of Application Servers and Application Routing..............................................12 4.3. Limitations of the trigger model ..........................................................................................13 4.4. Operation modes of Application Servers ............................................................................14 4.4.1. Application Server Acting as a SIP User Agent...........................................................14 4.4.2. Application Server Acting as a SIP Proxy Server ........................................................16 4.4.3. Application Server Acting as a SIP Redirect Server ....................................................16 4.4.4. Application Server Acting as a SIP B2BUA ................................................................17 4.5. Dynamic Service Activation Info (DSAI) ...........................................................................18 4.6. Service Capability Interaction Manager (SCIM) ................................................................19 4.7. Identification of IMS communication Services ...................................................................20 5. SIP Servlets .................................................................................................................................22 5.1. SIP or IMS application server .............................................................................................22 5.2. SIP Servlet API is a Java API..............................................................................................22 5.3. The SIP Servlet Container ...................................................................................................23 5.4. Message Processing methods ..............................................................................................23 5.5. Sessions and state ................................................................................................................24 5.6. Lifecycle methods ................................................................................................................24 5.7. Deployment descriptor.........................................................................................................24 5.8. Building, packaging and deploying .....................................................................................25 5.9. Converged applications .......................................................................................................25 5.10. Practical experience ...........................................................................................................25 6. The Exercises and Questions ......................................................................................................26 7. References ...................................................................................................................................28 7.1. Books on Session Initiation Protocol ..................................................................................28 7.2. Books on IP Multimedia Subsystem ...................................................................................28
Author: Dipl.-Ing. Franz Edler
page: 2 / 28
1. OVERVIEW
1.1. CONTENT OF THE COURSE
The course offers in depth knowledge on the IP Multimedia Subsystem (IMS). IMS means the architecture and concepts of the new Internet based communications networks, which will replace the traditional TDM1 based fixed and mobile networks in the coming years. The IP Multimedia Subsystem is based on SIP2 and therefore will provide not only voice services (telephony) but also multimedia communications. The IMS further on enables the integration of all available internet protocols and services even if not known today.
1.2. STRUCTURE OF THE COURSE

The course actually comprises the following parts: 1. IMS Overview and Standards 2. Basic Technologies: SIP recap and new protocols and extensions 3. IMS network architecture 4. IMS Identities, Authentication and Registration 5. Basic Session Control 6. User Profile and Provision of Services 7. Charging and Security Architecture 8. Access networks and PCC 9. Presence and Push-to-Talk 10. PSTN Simulation and Emulation 11. IP-TV
1.3. PRECONDITIONS AND FURTHER READINGS AND EXERCISES

The students should have as precondition for this course a solid background in basic internet technologies, in SIP and some of the SIP protocol extensions. Part 2 of this course (Basic Technologies) covers some of the mentioned technologies more as a short recap without offering all details. The student is encouraged to recap the knowledge from other courses, other literature or the Internet3. The author also encourages the students to look up in the mentioned standards, because this is the only firm basis in case of some issues and discussions in your future professional career. There are also some books available, which give deep insight into IMS. Two of them (the yellow and the red book) are preferred by the author. But of course there are more books available meanwhile and further books will come up in the future (see chapter 7). For the best result of the course practical exercises should be done in parallel. The Open IMS Core project of Fraunhofer Fokus4 (an Open Source project) offers an ideal basis to challenge
1 2
TDM = Time Division Multiplex SIP = Session Initiation Protocol, RFC 3261 3 I strongly recommend the Tech-Invite portal http://www.tech-invite.com/ 4 Open IMS Core project of Fraunhofer Fokus http://www.openimscore.org/
page: 3 / 28
Part 6: User Profile and Provision of Services the theoretical knowledge. Due to the limited amount of time for the course the author can only give some hints and examples how to handle the Open IMS Core software on Linux. To overcome the barriers of installation a VMware image of Open IMS Core is also available for download including some How-To instructions. There is also an implementation of OpenIMSCore on a public server of the University available, which gives a more realistic environment for e.g. development of master theses of students.
1.4. QUESTIONS AND EXERCISES

At the end of each part the student can find some questions which should help to get feedback on the core points of the course. The student should be able to answer the questions and exercises at the end of the course.
1.5. TARGET AUDIENCE

The target audience of this course are students on bachelor degree in the upper classes on telecommunications systems and students for the master degree of Telecommunications und Internet-technology.
page: 4 / 28
2. USER PROFILE
The user profile contains all data necessary to serve the user. It is stored in the HSS and downloaded to the S-CSCF during registration as a part of the diameter SAA message (UserData AVP)5.
2.1. STRUCTURE OF THE USER PROFILE

Figure 1 shows the structure of the user profile.
User Profile
Private User Identity Service Profile n Service Profile 2 Public User ID n Service Profile 1 Public User IDUser n ID 2 Public Public User ID n Public User ID 1 Public User ID 2 Barring indication Flag Public PublicUser UserID ID21 Public Barring User ID 1 indication Flag
TEL URI SIP URI TEL URI SIP URI
1 to n 1 to n 1 to n 0 to 1
TEL URI SIPindication URI Barring Flag
Core Network Service Authorization Core Network Service 0 to 1 Authorization Core Network Service 0 to Initial Filter Criteria 1 Authorization Initial Filter Criteria Initial Filter Criteria Initial Filter Criteria Initial Filter Criteria Initial Filter Criteria 0 to n Initial Filter Criteria Initial Filter Criteria Shared Initial Filter Criteria 0 to n Shared Initial Filter Criteria Shared Initial Filter Criteria Shared Initial Filter Criteria 0 to n Shared Initial Filter Criteria Shared Initial Filter Criteria Shared Initial Filter Criteria 0 to n Shared Initial Filter Criteria Shared Initial Filter Criteria
0 to n
0 to n
Figure 1: Structure of the user profile
In case the Service Profile is changed during operation there is a separate Diameter Command PPR (Push Profile Request) to update the Service Profile.
page: 5 / 28
Part 6: User Profile and Provision of Services The user profile is bound to the Private User Identity of a user. One or more Service Profiles may be associated to the Private User Identity if more than one Public User Identity is assigned to the Private User Identity, but only one Service Profile can be assigned to a Public User Identity because the Service Profile assigned to a Public User Identity must be unambiguous. A Service Profile may also be shared between Public User Identities of the same Private User Identity. The service profile consists of the following four parts: The Public User Identities to which it is applied. These may be a SIP or a TEL URI. At least one Public User Identity is assigned to a service profile. Public User Identities may also be barred from service. The Core Network Service Authorization which contains media profile data about media parameters the user is authorized to request. This field is optional. The media profile is policy-checked by the S-CSCF during session setup. The Initial Filter Criteria which determine which SIP Requests trigger the request to be routed to a specific application server. If more than one Initial Filter Criteria is assigned, the filter criteria have a priority assigned and they are checked sequentially according to their priority. The Shared Initial Filter Criteria which are used for convenience in case filter criteria are used by a number of users in common. These are provisioned in HSS and S-CSCF and need not to be downloaded for each user individually but only referenced by an identifier. Again more than one Shared Initial Filter Criteria may be used with priorities.
2.2. FILTER CRITERIA

The Filter Criteria (initial and shared) are among the most important pieces of data within IMS. They determine which services are provided to a user. For historical reasons the filter criteria are called initial Filter Criteria (iFC), but there are no additional subsequent filter criteria6 anymore. The filter criteria are applied to initial SIP requests. What are initial SIP requests? Initial SIP requests are either: - dialog initiating requests (requests which create dialogs like INVITE, SUBSCRIBE) or - standalone requests (requests outside of a dialog like MESSAGE, OPTIONS). The S-CSCF evaluates the filter criteria when it receives an initial request. It does not evaluate the filter criteria when it receives a subsequent request within a dialog (like PRACK, UPDATE and BYE). The filter criteria define the trigger conditions when a request has to be forwarded to a specific application server. Filter criteria are bound to Public User Identities according to the service profile. When an initial request traverses the IMS it is two times checked for matching filter criteria: at the S-CSCF of the originating home network (check for originating services) and at the S-CSCF of the terminating home network (check for terminating services). The following identity information of a SIP request is used to identify the associated services profile: - at the originating half call: the value of the P-Asserted-Identity header field - at the terminating half call: the value of the Request URI.
The concept of initial and subsequent filter criteria was defined in analogy to the intelligent network of PSTN, but it soon turned out, that subsequent filter criteria would violate the core SIP specification.
page: 6 / 28
Part 6: User Profile and Provision of Services In this way originating and terminating services are assigned and handled independently. In general different network operators may be involved. This is the principle of the half-call concept. Figure 2 shows the structure of filter criteria.
Initial Filter Criteria

Priority
Trigger Point Service Point Trigger 1 to n

Request URI SIP Method SIP Header
Service Point Trigger
Session Case Request URI Service Point Trigger SIP Method Session Description Request URI SIP Header SIP Method Session Case SIP Header Session Description Session Case Session Description
Application Server
SIP URI Default Handling Service Information
Figure 2: Structure of Initial Filter Criteria The first field of a filter criterion is the Priority. In case of more than one initial filter criterion assigned within a service profile the iFCs are evaluated sequentially according to their priority. A Trigger Point expression is constructed out of atomic expressions (the Service Point Triggers) linked by Boolean operators AND, OR and NOT. It determines when an initial request is forwarded to an application server. A trigger point is evaluated and the result is either true or false. If an IFC is defined without a trigger point the initial request is forwarded unconditionally to the application server.
page: 7 / 28
Part 6: User Profile and Provision of Services Trigger Points are structured in (either/or) - CNF conjunctive normal form: conjunction of disjunctions (OR ) AND ( OR ) - DNF disjunctive normal form: disjunction of conjunctions (AND ) OR ( AND ) including negations. Service Point Triggers are atomic logical expressions like Method = INVITE. Service Point Triggers may access different fields in a SIP request: The value of the request URI example: Request URI = sip:alice@home.net The method of the SIP request example: Method = INVITE The presence or absence of a header field and optionally the partial or full match of the content example: (header field = Event) and (content = *presence.*) The session case, whether the trigger is to be applied on originating or terminating requests of the served user, if it is registered or not registered example: SessionCase = Originating_Session The session description example: m = video
The last field of a filter criterion covers information about the application server handling the request in case of a match of the criterion. It contains the address of the application server (SIP URI), the Default Handling in case the AS does not answer (terminate or continue) and an optional Service Information. The Service Information may carry transparent information for the AS in some cases7. Details on the user profile and the filter criteria can be found in 3GPP TS 29.2288 and TS 29.2299.
7 8
The use of Service Information field is restricted to REGISTER requests. 3GPP TS 29.228: Cx and Dx interfaces; Signalling flows and message contents 9 3GPP TS 29.229: Cx and Dx interfaces based on the Diameter protocol; Protocol details
page: 8 / 28
3. A SERVICE EXAMPLE
The following example shows a simple initial filter criterion implementing a blacklist service. It is assigned to the user sip:good_guy@example.com as a terminating service and contains only one trigger point with priority zero. The filter criterion is evaluated whenever an initial request is received by the S-CSCF with a request URI with the value sip:good_guy@example.com. The trigger point matches in case of a session setup from sip:bad_guy@example.com and forwards the call to an application server (sip:as1.example.com) which will presumably render an appropriate and polite announcement to the caller. The trigger point will look like:
(method = INVITE) AND (P-Asserted-Identity = sip:bad_guy@example.com) AND (SessionCase = TERMINATING_REGISTERED)
This trigger point matches when the user sip:badguy@example.com calls the served user when it is registered. The whole user profile (in XML format) containing the filter criteria is shown in Figure 4. The message scenario in case of a filter criteria match is depicted in Figure 3.
AS
MRFC
3. INVITE 4. INVITE 7. 200 OK 8. 200 OK
1. INVITE 10. 200 OK bad_guy P-CSCF
2. INVITE 9. 200 OK S-CSCF orig media stream MRFP S-CSCF term good_guy
Figure 3: Service example (blacklist service) In case of a terminating session setup (INVITE request) to good_guy originated from bad_guy the INVITE request is forwarded to the application server. The application server forwards (re-targets) the INVITE request to a specific announcement for bad_guy. Figure 4 shows the content of the user profile of good_guy which is downloaded during registration. The user profile is structured as XML coded data and is carried in the User-Data AVP of the diameter SAA message. The structure of the XML data corresponds to the structure shown in Figure 1 and Figure 2.
6.
20
E IT NV I 5.
O K
page: 9 / 28

<?xml version="1.0" encoding="UTF-8"?> <testDatatype xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <IMSSubscription> <PrivateID>private_good_guy@example.com</PrivateID> <ServiceProfile> <PublicIdentity> <Identity>sip:good_guy@example.com</Identity> </PublicIdentity> <InitialFilterCriteria> <Priority>0</Priority> <TriggerPoint> <ConditionTypeCNF>1</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <SIPHeader> <Header>P-Asserted-Identity</Header> <Content> "sip:bad_guy@example.com" </Content> </SIPHeader> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <SessionCase>l</SessionCase> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:as1.example.com</ServerName> <DefaultHandling>1<DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </ServiceProfile> </IMSSubscription> </testDatatype>
Figure 4: Example of a User Profile
page: 10 / 28
4. APPLICATION SERVERS
The main goal of IMS is to provide innovative services for the users. Services are provided by application servers which are triggered by initial filter criteria. The following chapter describes IMS application servers and the way how these application servers interact within the IMS architecture.
4.1. APPLICATION SERVER INTERFACES

In part 3 of the script three different types of application servers have been already introduced: - the SIP Application Server - the OSA-SCS (Open Service Access Capability Server) - IM-SSF (IP Multimedia Service Switching Function) The OSA-SCS and the IM-SSF are specified as gateways to the existing service environment of a service provider, only the SIP-AS is defined as a pure SIP application server without legacy burden. For the rest of this chapter we will only refer to the SIP Application server. The communication mechanism in case the other two types of application server are used is similar and therefore not considered anymore. Figure 5 shows the interfaces which a SIP application server will use.
IMS Home Network
SIP-AS
Ut
ISC
Sh
Mw P-CSCF S-CSCF
Cx HSS
Figure 5: Application Server Interfaces The IMS service control interface (ISC) is the main interface of an application server in IMS. It connects the AS with the S-CSCF and enables the S-CSCF to route requests to the AS in case of a matching filter criterion. The ISC is (simply) a SIP based interface like the Mw interface between P-CSCF and S-CSCF. A further interface Ut enables the IMS terminal to directly provision service data at the SIP-AS. A typical example for using this interface is the activation of a call diversion service by the user or modifications in a network based address book. In the PSTN there was only a limited control for services offered to the user. This was enabled via special dialling codes containing * and # symbols. But the Ut interface is much more flexible, because it is based on the XCAP Author: Dipl.-Ing. Franz Edler page: 11 / 28
Part 6: User Profile and Provision of Services protocol. XCAP (XML Configuration Access Protocol) is defined by RFC 4825 and is based on HTTP. It enables read and write operations to single elements of an XML file and upload and download of whole XML files. The last interface of the SIP-AS is the Sh-interface. This is an optional diameter interface towards the HSS and it allows if enabled by the service provider access to the HSS database. It allows an AS to retrieve certain data fields (e.g. location data) of the user profiles and state information and also to upload and download transparent data. Besides the basic diameter messages UDR (User Data Request) and UDA (User Data Answer) there is also the possibility for the application server to get a notification when some data fields are changed. For further details see part 2 of the script and 3GPP TS 29.32810. The SIP-AS can be owned and operated by the service provider himself, in which case it is part of the trusted area of the home network. As an alternative it is also possible, that a SIP-AS is provided by a 3rd party. In this case there is usually no trusted relationship and therefore the Shinterface is not offered.
4.2. INTEGRATION OF APPLICATION SERVERS AND APPLICATION ROUTING

The following chapter explains how an application server is integrated into a session setup or into the routing of other standalone messages. The precondition for including an application server is a matching filter criterion. When a filter criterion matches the S-CSCF routes the request to the particular application server. This is done by inserting two Route header fields: the first Route header field points to the application server and the second Route header field points back to the S-CSCF. By these routing mechanisms the S-CSCF can sequentially walk through all matching iFCs of the request according to their priority. When the S-CSCF inserts the second Route header field it also marks the value of the Route header so that it can determine the point where it has to continue to evaluate iFCs. This marking is typically done by either using a pseudo username part of the route address or by adding some parameters to the Route header field. The marking of the Route header field of the second Route header is shown in the two examples below: Example 1: marking the Route header field by an additional pseudo username state20:
Route: <sip:as.home.net;lr>, <sip:state20@scscf.home.net;l r>
Example 2: marking the Route header field by additional header field parameters
Route: <sip:as.home.net;lr>, <sip:iscmark@scscf.home.net;lr;s=1;h=1;d=0>
Figure 6 shows how the application server routing mechanism based on above mentioned Route header fields will work. In this example it is assumed that an initial request (INVITE) matches three iFC and all three iFCs are handled by different application servers (AS1, AS2, AS3). The above mentioned mechanism leads to sequential routing to the three application servers. The inserting of additional Route header fields in an initial request is enabled by the loose routing mechanism of SIP (a similar procedure is used at inserting the value of the Path header field in case of a terminating request).
10
3GPP TS 29.328: Sh interface; Signalling flows and message contents
page: 12 / 28
AS1
AS2
AS3
5. INVITE
6. INVITE
TE VI
8. I NV IT E
IN 3.
1. INVITE
P-CSCF
2. INVITE S-CSCF
7.
IN VI TE
Figure 6: Sequential Routing to different Application Servers
4.3. LIMITATIONS OF THE TRIGGER MODEL

The iFC mechanism can only be applied on initial requests. These are either dialog initiating requests (e.g. INVITE, SUBSCRIBE) or standalone requests (e.g. MESSAGE). But what can an application developer do when the application needs to be invoked e.g. at BYE request, or at a certain SIP response? Historically there was the idea to have also subsequent filter criteria at hand which can be applied at subsequent requests like BYE. But it soon turned out that a trigger on subsequent requests means a violation of the SIP routing mechanism because it is not allowed to change the dialog route during a dialog11. Therefore initial filter criteria are the only ones allowed in IMS now, but the term initial is still used. Coming back to the problem mentioned above (how to trigger on BYE or on a response) the only solution to such a task is to trigger on the initial request and let the application monitor for the exact trigger condition (the BYE request arriving later). This requires that the application server adds a Record-Route header field so that it remains in the signalling path until the end of the dialog. In the real life of an IMS network we therefore will usually find two P-CSCFs, two S-CSCFs, sometimes one or two I-CSCF (topology hiding) and application servers included in the Record-Route header field.
4. IN TE VI
9. INVITE
11
To be fair: The decision on iFCs and sFCs has been done before the decision on the protocol used for ISC.
page: 13 / 28
4.4. OPERATION MODES OF APPLICATION SERVERS

From the signalling point of view an application server can behave differently. It can act like a SIP proxy server, like a SIP User Agent (originating, terminating), like a SIP redirect server or like a B2BUA. The different operation modes are shown in the following chapters. 4.4.1. APPLICATION SERVER ACTING AS A SIP USER AGENT An application server may act as a terminating or originating SIP User Agent. Three examples are illustrated below. Figure 7 shows the application server providing the terminating service in the originating home network.
AS
Originating IMS Home Network
3. SUBSCRIBE
4. 200 OK
1. SUBSCRIBE 5. 200 OK
P-CSCF
2. SUBSCRIBE 5. 200 OK S-CSCF
Figure 7: Application Server acting as terminating SIP UA in originating home network A typical example is the subscription to the presence state of a user. The iFC triggers on a SUBSCRIBE request and redirects the request to the application server acting as a presence agent. The presence agent terminates the SUBSCRIBE request as a user agent. Only the first Route header field of the two entries mentioned in chapter 4.2 is used in this case and the SUBSCRIBE request is not routed back to the S-CSCF. Further requests within the dialog (NOTIFY and SUBSCRIBE refresh requests) are than routed via the dialog route created by record routing. Another configuration of the same service is shown in Figure 8. In this case the iFC trigger matches in the terminating home network. The difference to the iFC used in Figure 7 might be that in the first example an additional condition (Service Point Trigger) in the iFC could be that the target domain (request URI) is the home network of the originator. In case there is no match in the originating network the SUBSCRIBE request is forwarded to the terminating network where perhaps the terminating trigger point will match.
page: 14 / 28
AS
Terminating IMS Home Network
3. SUBSCRIBE
4. 200 OK
1. SUBSCRIBE 6. 200 OK
I-CSCF
2. SUBSCRIBE 5. 200 OK S-CSCF P-CSCF
Figure 8: Application Server acting as terminating SIP UA in terminating home network Another example for an application server acting as a SIP User Agent might be a kind of wakeup call. In this case the AS originates the session as shown in Figure 9.
AS
1. INVITE
6. 200 OK
3. INVITE 4. 200 OK
P-CSCF
2. INVITE 5. 200 OK S-CSCF
Figure 9: Application Server acting as an originating SIP UA Another example may be a notification service where a MESSAGE method is used instead of an INVITE method.
page: 15 / 28
Part 6: User Profile and Provision of Services 4.4.2. APPLICATION SERVER ACTING AS A SIP PROXY SERVER An application server might also act as a simple SIP proxy server following the rules of RFC 3261 for proxying requests. Figure 10 illustrates an example where the application server acts as a proxy in the originating home network.
AS
7. 200 OK
3. INVITE
8. 200 OK
5. INVITE 6. 200 OK
4. INVITE
1. INVITE 10. 200 OK

P-CSCF
2. INVITE 9. 200 OK S-CSCF
Figure 10: Application Server acting as a SIP Proxy server A service which simply needs to monitor some requests originating in the home network can be implemented by such an application server. The possibilities to modify contents of requests and responses are limited in this case due to the SIP proxy rules of RFC 3261, but the service logic in the AS is very simple. It has to be mentioned that in case of an application server acting as a SIP proxy server the same dialog is maintained troughout the traversal through the application server. All INVITE requests shown in Figure 10 are requests within the same dialog (and of course all other requests and responses within the dialog). 4.4.3. APPLICATION SERVER ACTING AS A SIP REDIRECT SERVER An application server can also act as a SIP Redirect server. Figure 11 shows an example of such an application server offering a redirect service (call forwarding) in the terminating home network. In this case the new target address is pushed back towards the origin.
page: 16 / 28
AS
1. INVITE
2. INVITE 5. 302 Moved Temporarily I-CSCF S-CSCF P-CSCF
6. 302 Moved Temporarily
Figure 11: Application Server acting as SIP Redirect Server
4.4.4. APPLICATION SERVER ACTING AS A SIP B2BUA The last mentioned operating mode of an application server is that of a Back-to-back User Agent. It is probably the most used operating mode because it offers the most flexibility to implement services. Figure 12 depicts a session setup including an application server acting as B2BUA in originating home network.
3. INVITE
4. 302 Moved Temporarily

AS
3. INVITE A
7. 200 OK
4. INVITE B
8. 200 OK
5. INVITE B 6. 200 OK
1. INVITE A 10. 200 OK

P-CSCF
2. INVITE A 9. 200 OK S-CSCF
Figure 12: Application Server acting as B2BUA in originating home network
page: 17 / 28
Part 6: User Profile and Provision of Services Compared with Figure 10 there is no difference at the high level view of messages traversing the network, but the difference is in dialogs. INVITE request 3 and 4 are part of different dialogs and the same is valid for 200 OK responses 7 and 8. Therefore the INVITE requetsts are distinguished as INVITE A and INVITE B. A B2BUA increases the complexity of the application implementation but brings full flexibility on implementing a service. The logic of the B2BUA which is full under control of the designer dictates how requests and responses are mapped. The range of possibilities goes from simple regenerating a request or response to creating new requests, modifying, inserting or deleting header fields and so on. An example for the message flow in Figure 12 might be a prepaid service, where the application server actively terminates a session in case the credit runs out. Another example of an application server acting as B2BUA is shown in Figure 13 this time located in the terminating home network.
AS
3. INVITE A
7. 200 OK
4. INVITE B
8. 200 OK
1. INVITE A 10. 200 OK

I-CSCF
2. INVITE A 9. 200 OK S-CSCF
5. INVITE B 6. 200 OK
Figure 13: Application Server acting as B2BUA in terminating home network A good example for such a service might be an advanced anonymizing service which not only eliminates the P-Asserted-Identity header field but also obfuscates all header fields carrying any hint on the originator and also IP-addresses in SDP. Obviously such a service should not only be limited to terminating requests but also to originating requests.
4.5. DYNAMIC SERVICE ACTIVATION INFO (DSAI)

The default subscription of a service for all subscribers may lead to an unnecessary high load on an application server, if the application is actually only used by a small percentage of active IMS terminals. This can be best explained by the following example. Recently the following instant messaging service has been discussed: In general an instant message is forwarded to the destination terminal instantly. In case the destination terminal is not Author: Dipl.-Ing. Franz Edler page: 18 / 28
Part 6: User Profile and Provision of Services registered an application should store the message and deliver it when the terminal goes on-line again. The application server must therefore detect when the terminal goes on-line again by using an iFC which triggers on the REGISTER request. The consequence is that the iFC on REGISTER has to be set for all users, because it may happen that sometimes an IM will arrive when the terminal is logged off. Imagine a million of IMS terminals active and only a few inactive and only a few of those receiving an IM during off-line status. The application server will unnecessarily receive all re-registration messages of a million of users. This is where the Dynamic Service Activation Info comes in. The DSAI avoids useless triggering of application servers by allowing the application server to activate and de-activate an existing iFC via Sh interface in the HSS. In case of a DSAI is associated with an iFC, the iFC is only downloaded to the S-CSCF if it is not masked. If the DSAI is activated by the AS, the AS informs the HSS and the HSS downloads the iFC spontaneously to the HSS. For user profile updates outside of the registration procedure a separate diameter message is used: Push Profile Request (PPR). For above example this means that the iFC for the REGISTER request is prepared for all users but actually downloaded to the S-CSCF only when needed (dynamically controlled by an application via the DSAI).
4.6. SERVICE CAPABILITY INTERACTION MANAGER (SCIM)

When routing from one Application Server to another care has to be taken on feature interaction. There might be situations where one application is in conflict with the other. A typical example is the sequence of two services call forwarding and call screening. When these services are handled by different application servers the following may happen: Based on the initial INVITE request both iFCs might match, but after rewriting the request URI by the first AS handling call forwarding the second iFC for call screening might no longer match. To cope with such conflicting situations the 3GPP has defined a SCIM function (Service Capability Interaction Manager) between the S-CSCF and the application server. The details of the SCIM are still not defined and therefore there is a lot of freedom to implement a SCIM12. The SCIM actually can only be regarded as an awareness of the potential conflicting situations when applying services sequentially. In this case applications have to be handled properly. Figure 14 shows the intermediating function of the Service Capability Interaction Manager.
12
The SIP-Servlet Specification v1.1 defines an Application Router which is in fact a SCIM function.
page: 19 / 28
AS1
AS2
AS3
Service Capability Interaction Manager
P-CSCF
S-CSCF
Figure 14: Service Capability Interaction Manager
4.7. IDENTIFICATION OF IMS COMMUNICATION SERVICES

A rather controversial issue was raised when 3GPP started to define IMS communication Services Identifier (ICSI) and IMS Application Reference Indicators (IARI). The principle idea behind the concept of communication services is to have a kind of shortcut notation for a basic service which is behind an application. An IMS communication service identifier represents the aggregation of certain media components and the principle service logic for managing the service. The ICSI value may be used by user equipments, the S-CSCF and application servers to rapidly identify the resources and the applications necessary for a service. It may also be used for charging purposes and as an indication of resources used in case of interconnection between different operator networks There may be standardised (default) service logic behind a communication service but there is also the possibility to define a specific application via an IMS Application Reference Indicator. The application reference (IARI) only has significance for the user equipment and the application server(s). The concept of a service indicator has been heavily debated within IETF and rejected in its initial scope13. Why? What is so bad with a communication service identifier? The danger with ISCI is that it may restrict the potential of possible services if there are only a few service models invented by network operators. The information carried within an ICSI is redundant and can be derived from other parameters within SIP signalling e.g. the media components used in SDP. The creation of communication services may lead back to the legacy world of operator networks where only operator specified communication services are allowed and supported. The relationship between ICSI and IARI is depicted in Figure 15. ###
13
draft-ietf-sipping-service-identification: Identification of Communications Services in SIP
page: 20 / 28
Specific application
Default application for MMtel
Default application for PoC
Default application f Messaging IMS Application Reference Identifier
Multimedia Telephony
Push-to-Talk over Cellular
Messaging
something new
IMS Commuication Service Identifier
IMS - Stack
Figure 15: Communication Services Identifier and Application Reference Indicators
page: 21 / 28
5. SIP SERVLETS
Application servers are the most important components for innovation and new services in IMS. This chapter will therefore give a short introduction into the most important programming method: SIP Servlets. To be fair, there are also other methods available to create SIP services like - Call Processing Language - SIP CGI - JAIN SIP - JAIN SLEE but the SIP servlet API is the most favoured method for developing IMS applications. The SIP servlet API is a Java based methodology for implementing SIP applications. It is the method which is also offered by most commercial SIP application servers. - JSR 180: SIP API for Java ME - JSR 281: IMS Services API - JSR 325: MS Communication Enablers
5.1. SIP OR IMS APPLICATION SERVER

Is there a difference between a SIP application server and an IMS application server? No because the ISC interface between S-CSCF and a SIP AS is based on pure SIP. There are of course IMS specific extensions which are visible at the ISC interface, but SIP has been designed for extensibility and the IMS extensions follow the rules for extensibility. A P-Asserted-Identity header field is just a header field extension to SIP.
5.2. SIP SERVLET API IS A JAVA API

The SIP Servlet API is an API (Application Programming Interface) developed by the Java Community Process (JCP). The SIP Servlet API v1.0 is available as JSR 116 (Java Specification Request) since 200314. There is actually a SIP Servlet API v1.1 available as a final draft15 which includes some enhancements like a B2BUA-Helper or an Application Router (the previously mentioned SCIM functionality) to make life of programmers easier. The SIP Servlet API has been derived from the HTTP Servlet API for Web service development JSR 15416. This is not surprising as the SIP protocol has been derived from HTTP-Protocol. But there is a slight difference between both APIs: - HTTP servlets are designed to process incoming HTTP requests and send response messages. - SIP Servlets also allow the send out SIP requests, so it is more symmetric. The main advantage of the SIP servlet API is the abstraction of boring protocol details without reducing flexibility in application development. As an example the SIP servlet API cares automatically for inserting a Via header field or copying some header fields of the request to a response and much more
14 15
See http://jcp.org/aboutJava/communityprocess/final/jsr116/ See: http://jcp.org/en/jsr/detail?id=289 16 See: http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html
page: 22 / 28
Part 6: User Profile and Provision of Services The application developer can therefore concentrate on his task without stressing himself with details of the protocol. But to be not misinterpreted: it is very helpful to know the principles of the protocol, otherwise some functions of methods cannot be well understood.
5.3. THE SIP SERVLET CONTAINER

The Servlet Container is the central component of a servlet based application server. The servlet container offers basic functions for the servlet. The container provides many services that an application can take advantage of, such as automatic retries, message dispatching and queuing, forking and merging, and state management. Figure 16 shows the servlet container residing above a SIP stack implementation. The SIP servlets represent the actual code of the application, which are invoked by the container in case certain events occur. These events can be the reception of a SIP request or SIP reponse or e.g. a timeout.
SIP Servlet
SIP Servlet
SIP Servlet
Servlet Container
Dialog Management
Transaction Layer Message Parser SIP Stack
Transport Layer
UDP
TCP
TLS
Figure 16: SIP Servlet Container and SIP Servlets
5.4. MESSAGE PROCESSING METHODS

The SIP servlet API offers a set of message processing methods which cover SIP requests and SIP responses. In SIP servlet API 1.0 the following request processing methods are defined: doInvite for handling SIP INVITE requests doAck for handling SIP ACK requests doOptions for handling SIP OPTIONS requests doBye for handling SIP BYE requests doCancel for handling SIP CANCEL requests doRegister for handling SIP REGISTER requests doPrack for handling SIP PRACK requests doSubscribe for handling SIP SUBSCRIBE requests doNotify for handling SIP NOTIFY requests
page: 23 / 28
Part 6: User Profile and Provision of Services doMessage for handling SIP MESSAGE requests doInfo for handling SIP INFO requests Also the following response handling methods are available: doProvisionalResponse for handling SIP 1xx informational responses doSuccessResponse for handling SIP 2xx responses doRedirectResponse for handling SIP 3xx responses doErrorResponse for handling SIP 4xx, 5xx, and 6xx responses These methods are the basic building blocks of a SIP application. Further methods are available to get access to various header fields (read, write), to create new header fields and so on. An important feature of the SIP servlet API is that due to the abstraction level not every protocol manipulation is allowed. But this is not a restriction but more a benefit for the programmer as it protects the programmer from violating the SIP protocol rules. One might have recognized that there is no doUpdate method available in v1.0. This is due to the time when SIP servlet API was defined. But there is an easy way to implement additional methods.
5.5. SESSIONS AND STATE

Usually each SIP application handles sessions and has some state machine created during design. The SIP servlet API offers suitable language constructs for that. The session concept is supported by two objects: - SipSession representing the SIP session and the dialog - SipApplicationSession representing SIP sessions that belong together Each of the above constructs can hold arbitrary attributes which are defined by the programmer. The container automatically links the correct session data whenever a request or response is received.
5.6. LIFECYCLE METHODS

Lifecycle methods init and destroy are automatically called by the container when a servlet is started up or shut down. This allows easy initialization of data and cares for garbage collection.
5.7. DEPLOYMENT DESCRIPTOR

The deployment descriptor is also a concept taken from HTTP servlet API. Each SIP application is accompanied by deployment descriptor, which is an XML-file sip.xml17. The deployment descriptor contains important information on how the application should be invoked. It allows to initialize parameters and to define which servlet has to be invoked on arrival of certain messages (detailed filtering rules may be specified). A deployment descriptor file usually need not be created by hand but there is normally an editor which allows to set the relevant data.
17
The corresponding deployment descriptor file of the HTTP servlet API is web.xml.
page: 24 / 28
5.8. BUILDING, PACKAGING AND DEPLOYING

After compiling a SIP servlet based application the result is packaged into a SAR file (Servlet Archive)18. This SAR file is than transferred to the SIP application server and stored in a dedicated deployment folder where eventually other applications with their deployment descriptors already reside. After transferring the SAR file the new application is recognized by the container and automatically invoked according to the deployment descriptor.
5.9. CONVERGED APPLICATIONS

Due to the close relationship between HTTP and SIP it is quite natural, that most SIP servlet based application servers also support the HTTP servlet API. This enables a developer to easy add web components to an application. Simple examples of such converged applications are Web based provisioning of call diversion: The user can provide new targets for call diversion via a web interface and activate the diversion. SetUp of a Conferencing service: The user adds the SIP addresses of the participants of a conferencing service on a web interface and starts the conference. The participants are automatically invited by the application. and much more
5.10. PRACTICAL EXPERIENCE

The author himself is not a very experienced programmer but was very amazed how easy it is to develop IMS applications with the help of SIP servlet technology. It is quite astonishing that with today available technologies for a student it is possible to develop, test and deploy IMS applications on a single notebook computer. The ingredients the author used were: OpenIMScore: the open source IMS platform developed by Fraunhofer FOKUS institute http://www.openimscore.org/ VMware software for running a Linux environment on a WindowsXP based notebook computer. VMware offers a free downloadable VMware player at http://www.vmware.com/ IMS user agents: The IMS communicator is an open source implementation of an IMS user agent: http://imscommunicator.berlios.de/ Eclipse development environment for developing Java applications. The SIP application server from Micromethod which was used offers a comfortable Eclipse Plug-in, where one can debug the SIP servlet in real-time: http://www.eclipse.org/ SIP application server: The SIPmethod ACE an application server Plug-In for Eclipse from Micromethod http://www.micromethod.com/
A VMware image for OpenIMScore is available so that the first steps into the world of IMS applications are a little bit easier.
18
The SAR file coresponds the WAR file (Web Application Archive) of the HTTP servlet API.
page: 25 / 28
6. THE EXERCISES AND QUESTIONS

After studying this part of the lecture you should be able to answer the following questions: Chapter 2 User Profile: When is the User Profile downloaded to the S-CSCF? Explain the structure of the User Profile! Which data are included? What relationship is between Service Profiles and Public User Identities? How many Service Profiles can be assigned to a Public User Identity? What is the Core Network Service Authorization field used for? How are iFCs handled in case of more than one is iFC is triggered? What are Shared Initial Filter Criteria and what is their purpose? What are initial SIP requests? Which network nodes evaluates iFCs and when? Which address fields (identities) are relevant for evaluating the iFCs? How is the half call concept mapped to iFCs? Describe the data structure of iFCs! Describe a Trigger Point! Describe Service Point Triggers! What does the default handling parameter of the data of an application server in an iFC mean?
Chapter 3 A Service Example: Describe a simple service example based on an iFC (e.g. blacklist service)!
Chapter 4 Application servers: What interfaces does an application server usually support? Which one is optional (why)? What is the purpose of the Ut interface, and what protocol is it based on? What is the purpose of the Sh interface, and what protocol is it based on? Describe the request routing mechanism between S-CSCF and AS! How can applications for non initial requests or responses be invoked? What are the roles from SIP protocol point of view that an AS can play? Describe potential advantage and disadvantage! Describe an example of an application server acting as a terminating user agent! Describe an example of an application server acting as an originating user agent!
page: 26 / 28
Part 6: User Profile and Provision of Services Describe an example of an application server acting as a proxy server! Describe an example of an application server acting as a B2BUA! What is the purpose of the Dynamic Service Activation Information (DSAI)? Explain the mechanism! What is the Service Capability Interaction Manager (SCIM) used for? Where is the function located?
Chapter 5 SIP Servlets: Explain the difference of the SIP servlet API compared with HTTP servlet API! What is the advantage of using the SIP servlet API for an application programmer? What services does a SIP servlet container offer? What are converged applications?
page: 27 / 28
7. REFERENCES
7.1. BOOKS ON SESSION INITIATION PROTOCOL
Henry Sinnreich und Alan B. Johnston: Internet Communcications Using SIP Wiley & Sons, ISBN-10: 0471776572 2nd edition: 2006 Alan B. Johnston: SIP Understanding the Session Initiation Protocol Artech House, ISBN 1-58053-168-7 2. Auflage November 2003
Henry Sinnreich, Alan B. Johnston und R. Sparks: SIP beyond VoIP VON Publishing LLC, www.vonmag.com ISBN: 0-9748130-0-1
7.2. BOOKS ON IP MULTIMEDIA SUBSYSTEM

The yellow book: G. Camarillo, M. Garcia-Martin: The 3G IP Multimedia Subsystem (IMS) Wiley & Sons, ISBN-10: 0470516623 ISBN-13: 978-0470516621 3rd Edition, Nov. 2008 The red book: M.Poikselka, G.Mayer, H. Khartabil: The IMS - IP Multimedia Concepts and Services Wiley & Sons, ISBN-10: 0470721960 ISBN-13: 978-0470721964 3rd Edition, March 2009
page: 28 / 28

IMS-Part6 User Profile and Provision of Services

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IMS-Part6 User Profile and Provision of Services

Cargado por

Copyright:

Formatos disponibles

Study Program Master Telecommunications and Internet Technologies

Course Application Prototyping

IP MULTIMEDIA SUBSYSTEM (IMS)

Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

1.2. STRUCTURE OF THE COURSE

1.3. PRECONDITIONS AND FURTHER READINGS AND EXERCISES

Author: Dipl.-Ing. Franz Edler

1.4. QUESTIONS AND EXERCISES

1.5. TARGET AUDIENCE

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

2.1. STRUCTURE OF THE USER PROFILE

TEL URI SIPindication URI Barring Flag

Figure 1: Structure of the user profile

Author: Dipl.-Ing. Franz Edler

2.2. FILTER CRITERIA

Author: Dipl.-Ing. Franz Edler

Initial Filter Criteria

Trigger Point Service Point Trigger 1 to n

Service Point Trigger

Author: Dipl.-Ing. Franz Edler

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

3. INVITE 4. INVITE 7. 200 OK 8. 200 OK

1. INVITE 10. 200 OK bad_guy P-CSCF

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

Figure 4: Example of a User Profile

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

4.1. APPLICATION SERVER INTERFACES

IMS Home Network

4.2. INTEGRATION OF APPLICATION SERVERS AND APPLICATION ROUTING

3GPP TS 29.328: Sh interface; Signalling flows and message contents

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

Figure 6: Sequential Routing to different Application Servers

4.3. LIMITATIONS OF THE TRIGGER MODEL

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

4.4. OPERATION MODES OF APPLICATION SERVERS

Originating IMS Home Network

2. SUBSCRIBE 5. 200 OK S-CSCF

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

Terminating IMS Home Network

2. SUBSCRIBE 5. 200 OK S-CSCF P-CSCF

Originating IMS Home Network

2. INVITE 5. 200 OK S-CSCF

Author: Dipl.-Ing. Franz Edler

Originating IMS Home Network

1. INVITE 10. 200 OK

2. INVITE 9. 200 OK S-CSCF

Author: Dipl.-Ing. Franz Edler

Part 6: User Profile and Provision of Services

2. INVITE 5. 302 Moved Temporarily I-CSCF S-CSCF P-CSCF

6. 302 Moved Temporarily

Figure 11: Application Server acting as SIP Redirect Server

Terminating IMS Home Network

4. 302 Moved Temporarily

Originating IMS Home Network