LECTURE NOTE 6
Version: Datum: 2.1 30. 03. 2009
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
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.
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.
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.
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
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
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.
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.
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
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
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.
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.
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
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
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
AS
3. SUBSCRIBE
4. 200 OK
1. SUBSCRIBE 5. 200 OK
P-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
3. SUBSCRIBE
4. 200 OK
1. SUBSCRIBE 6. 200 OK
I-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
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
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
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
3. INVITE A
7. 200 OK
4. INVITE B
8. 200 OK
5. INVITE B 6. 200 OK
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
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.
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).
12
The SIP-Servlet Specification v1.1 defines an Application Router which is in fact a SCIM function.
page: 19 / 28
AS1
AS2
AS3
P-CSCF
S-CSCF
page: 20 / 28
Specific application
Specific application
Specific application
Multimedia Telephony
Messaging
something new
IMS Commuication Service Identifier
IMS - Stack
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
14 15
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.
SIP Servlet
SIP Servlet
SIP Servlet
Servlet Container
Dialog Management
Transport Layer
UDP
TCP
TLS
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.
17
The corresponding deployment descriptor file of the HTTP servlet API is web.xml.
page: 24 / 28
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
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
page: 28 / 28