The MS: IP Multimedia Concepts and Services
`
`'3GPP
`Release 5
`
`Release 6
`
`BGPP
`Release 7
`
`BGPP
`Release 3
`
`PacketCable
`2.0
`
`2 Access technology of TISPAN.
`
`and vendors in different ways. [MS vendors will be able to create the functionality once,
`and reuse it later. This means faster time to market, lower research and development cost
`due to eliminated replication effort. From an operator and service provider point of view
`it means that they will have a larger choice of vendors to select from and procurement
`cost of IMS products is lower. During 2007 3GPP and TISPAN made an agreement to
`stop IMS related development in TISPAN and focus all IMS development to 3GPP. Based
`on this agreement lot of functions and procedures developed in TISPAN Release 1 were
`included in 3GPP Release 7. TISPAN Release 2 is expected to be the last TISPAN release
`on IMS matters and functions and procedures are expected to be harmonized in 3GPP
`Release 8. Some Packetcable ‘IMS’ features were already included in 3GPP Release 7
`and additional features and procedures originating from cable operators will be addressed
`in 3GPP Release 8. Harmonization of 3GPP2 MMD and 3GPP IMS is starting in Release
`8. Due to late start full harmonization will probably happen in future 3GPP IMS releases.
`
`Figure 1.5 Road to standardized common IMS standards
`
`1.4.5 3GPP Release 7 and common IMS
`
`3GPP Release 7 functional content was frozen in March 2007. It introduces two more
`access technologies (Data Over Cable Service Interface Specification (DOCSIS)] and
`xDSLZ) and features and procedures originating from those and other general improve-
`ments. This can be considered as a step towards the ultimate goal of single common IMS.
`Major new features in Release 7 are: IMS multimedia telephony including supplemen—
`tary services (see Chapter 9 and Chapter 12), SMS over any IP access (see Chapter 7,
`Section 7.4), Voice Call Continuity (see Section 3.20 and Chapter 13), local numbering
`(see Section 3.16), Combining CS calls and IMS sessions (see Section 3.19), Transit [MS
`(see Section 3.15), Interconnection Border Control Function (IBCF) (see Section 2.2.6.2),
`
`] Access technology of Cablelabs.
`
`APPENDIX L
`
`AT&T, Exh. 1003, p. 590
`
`

`

`Introduction
`
`Globally Routable User Agent’s URI (see Section 3.5.6 and Section 12.10), IMS emer-
`gency sessions (see Section 3.17), Identification of Communication Services in IMS(see
`Section 12.3.9) and new authentication model for fixed access (see Section 3.21.2.3).
`
`1.4.6 Insight to 3GPlD Release 8
`
`Standardization work on Release 8 is ongoing at the time of writing and work is expected
`to be completed by the end of 2008. This release will introduce a number of novel IMS
`features such as IMS centralized services which enables the use of [MS service machinery
`even though devices are using CS connection (GSM/BG CS radio) towards the network;
`multimedia session continuity which would improve the voice call continuity feature to
`enable continuity of multimedia media streams when I? access is changed; corporate
`access to IMS, a feature that enables integratation of IP—PBX to the [MS network; service
`level interworldng for messaging and number portability.
`
`— charging entity information;
`
`1.5 Why a SIP Solution Based on 3GPP Standards?
`
`IETF is the protocol factory for Internet world and it is doing great work in this space but
`it does not define the ways that they are used, especially in the mobile domain. 3GPP is
`the body that took Session Initiation Protocol (SIP) as the control protocol for multimedia
`communication and 3GPP has built a finite architecture for SIP-based IP multimedia
`
`service machinery (the IMS). It contains a functionality of logical elements, a description
`of how elements are connected, selected protocols and procedures. 3GPP standardized
`solutions are needed to provide: interoperability between terminals from different vendors,
`interoperability between network elements from different vendors, interoperability across
`operator boundaries. The following advantages of 3GPP IMS against a pure IETF SIP
`service model can be listed:
`
`a optimization for wireless usage:
`
`— SIP compression (see Section 3.18);
`— implicit registration (see Section 3.3);
`7 network initiated rte—authentication (see Section 11.142);
`— network initiated deregistration (see Section 11.153);
`0 authentication:
`
`— GPRS—IMS-Bundled Authentication (see Section 11.16);
`— NASS-IMS-Bundled Authentication (see Section 3.21.2.3);
`— ISIMfUSIM authentication (see Section 11.6);
`
`o policy control (see Section 3.10):
`
`— policy control and policy enforcement functions;
`— Rx and GK reference points;
`— quality of Service (Q08);
`
`a charging (see Section 3.11):
`
`n charging correlation (online and offline charging);
`
`APPENDIX L
`
`AT&T, Exh. 1003, p. 591
`
`

`

`The MS: [P Multimedia Concepts and Services
`
`0 services and application server interfaces:
`— ISC interface (see Section 2.3.3);
`— Initial Filter Criteria (see Section 3.12.4);
`- access network information available in MS (see Section 11.11.1);
`o mobility and roaming models defined (see Section 2.1.7);
`- visited network identification (see Section 1111.2);
`0 regulator requirements specified:
`— emergency call (incl. location information) (see Section 3.17);
`— legal interception;
`— number portability.
`
`
`
`AT&T, Exh. 1003, p. 592
`
`APPENDIX L
`
`AT&T, Exh. 1003, p. 592
`
`

`

`THEIMS
`IP MULTIMEDIA CONCEPTS AND
`SERVICES, THIRD EDITION
`
`Miikka Poikselka
`Nokia Siemens Networks, Finland
`
`Georg Mayer
`Nokia, Finland
`
`~WILEY
`
`A john Wiley and Sons, Ltd., Publication
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 593
`
`

`

`This edition first published 2009
`
`© 2009 John Wiley & Sons Ltd
`
`Registered office
`
`John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, P0l9 8SQ, United Kingdom
`
`For details of our global editorial offices, for customer services and for information about how to apply for
`permission to reuse the copyright material in this book please see our website at www.wiley.com.
`
`The right of the author to be identified as the author of this work has been asserted in accordance with the
`Copyright, Designs and Patents Act 1988.
`
`All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in
`any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by
`the UK Copyright, Designs and Patents Act 1988, without the prior pennission of the publisher.
`
`Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be
`available in electronic books.
`
`Designations used by companies to distinguish their products are often claimed as trademarks. All brand names
`and product names used in this book are trade names, service marks, trademarks or registered trademarks of their
`respective owners. The publisher is not associated with any product or vendor mentioned in this book. This
`publication is designed to provide accurate and authoritative information in regard to the subject matter covered.
`It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional
`advice or other expert assistance is required, the services of a competent professional should be sought.
`
`Library of Co11gress Catalogi11g-i11-Publicatio11 Data
`
`Poikselka, Miikka.
`The IMS : IP multimedia concepts and services' I Miikka Poikselka, Georg Mayer. - 3rd ed.
`p. em.
`Rev. ed. of: IMS I Miikka Poikselka ... [eta!.]. 2006
`[ncludes bibliographical references and index.
`ISBN 978-0-470-72 196-4 (cloth)
`l. Multimedia communications. 2. Wireless communication systems. 3. Mobile communication systems. I. Mayer,
`Georg, 1970- 11. IMS. ill. Title.
`TK5l05.15.P65 2008
`621.382' 12- dc22
`
`2008032207
`
`British Library Cataloguing in Publicatio11 Data
`
`A catalogue record for this book is available from the British Library
`
`ISBN 978-0-470-72196-4 (H/B)
`
`Typeset in 10112 Times by Laserwords Private Limited, Chennai, India
`Printed and bound in Great Britain by CPl Antony Rowe, Chippenham, Wiltshire
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 594
`
`

`

`24
`
`The IMS: TP Multimedia Concepts and Services
`
`The P-CSCF is tasked to relay session and media-related information to the PCRF
`when an operator wants to apply policy and charging control. Based on the received
`information the PCRF is able to derive authorized IP QoS information and charging
`rules that will be passed to the access gateway (e.g. GGSN). This concept is covered
`in Section 3.10. Moreover, via the PCRF and P-CSCF the IMS is able to deliver IMS
`charging correlation information to the access network and, similarly, via the PCRF and
`P-CSCF the IMS is able to receive access charging correlation information from the access
`network. This makes it possible to merge charging data records coming from the IMS
`and access networks in the billing system. How this is done is shown in Section 3.1 L.7.
`P-CSCF plays an important role in IMS emergency session handling as the P-CSCF is
`tasked to detect emergency requests in all possible cases. P-CSCF is expected to reject
`emergency attempts based on operator policy (e.g. user is attempting to make emergency
`call via home P-CSCF when roaming) or based on network capability (P-CSCF or the
`rest of the IMS core is pre-Release 7 which do not support IMS functionality.
`
`2.2.1.2
`
`Interrogating Call Session Control Function (1-CSCF)
`
`Interrogating Call Session Control Function (1-CSCF) is a contact point within an opera(cid:173)
`tor's network for all cotmections destined to a subscriber of that network operator. There
`are three unique tasks assigned for the I-CSCF:
`
`• Obtaining the name of the next hop (either S-CSCF or application server) from the
`Home Subscriber Server (HSS).
`• Assigning an S-CSCF based on received capabilities from the HSS. The assignment
`of the S-CSCF will take place when a user is registering with the network or a user
`receives a SIP request while they are unregistered from the network but has services
`related to an unregistered state (e.g., voice mail). This procedure is described in more
`detail in Section 3.9.
`• Routing incoming requests further to an assigned S-CSCF or the application server (in
`the case of public service identity see Section 12.11).
`
`2.2.1.3 Serving Call Session Control Function (S-CSCF)
`
`Serving Call Session Control Function (S-CSCF) is the focal point of the IMS as it is
`responsible for handling registration processes, making routing decisions and maintaining
`session states and storing the service profile(s). When a user sends a registration request it
`will be routed to the S-CSCF, which downloads authentication data from the HSS. Based
`on the authentication data it generates a challenge to the UE. After receiving the response
`and verifying it the S-CSCF accepts the registration and starts supervising the registration
`status. After this procedure the user is able to initiate and receive IMS services. Moreover,
`the S-CSCF downloads a service profile from the HSS as part of the registration process
`and delivers user (e.g. information about implicitly registered identities see Section 3.3)
`and device specific information to the registered UE see Section 3.5.6).
`A service profile is a collection of user-specific information that is permanently stored
`in the HSS. The S-CSCF downloads the service profile associated with a particular public
`user identity (e.g., joe.doe@ims.example.com) when this particular public user identity
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 595
`
`

`

`IP Multimedia Subsystem Architecture
`
`25
`
`is registered in the IMS. The S-CSCF uses information included in the service profile
`to decide when and, in particular, which application server(s) is contacted when a user
`sends a SIP request or receives a request from somebody. Moreover, the service profile
`may contain further instructions about what kind of media policy the S-CSCF needs
`to apply - for example, it may indicate that a user is only allowed to use audio and
`application media components but not video media components.
`The S-CSCF is responsible for key routing decisions as it receives all DE-originated
`and DE-terminated sessions and transactions. When the S-CSCF receives a DE-originating
`request via the P-CSCF it needs to decide if application servers are contacted prior to
`sending the request further on. After possible application server(s) interaction the S-CSCF
`either continues a session in IMS or breaks to other domains (CS or another IP network).
`When the UE uses a Mobile Station ISDN (MSISDN) number to address a called party
`then the S-CSCF converts the MSISDN number (i.e. , a tel URL) to SIP Universal Resource
`Identifier (URI) fom1at prior to sending the request fmther, as the IMS does not route
`requests based on MSISDN numbers. Similarly, the S-CSCF receives all requests which
`will be terminated at the DE. Although, the S-CSCF knows the IP address of the DE
`from the registration it routes all requests via the P-CSCF, as the P-CSCF takes care of
`SIP compression and security functions . Prior to sending a request to the P-CSCF, the
`S-CSCF may route the request to an application server(s), for instance, checking possible
`redirection instructions. Figure 2.7 illustrates the S-CSCF's role in routing decisions.
`In addition, the S-CSCF is able to send accounting-related information to the Online
`Charging System for online charging purposes (i.e., supporting pre-paid subscribers).
`
`2.2.2 Emergency Call Session Control Function (E-CSCF)
`
`E-CSCF is a dedicated functionality to handle IMS emergency requests such as sessions
`towards police, fire brigade and ambulance. The main task of E-CSCF is to select an
`
`~ m ~
`1. m 2. m 4a. m: 6.
`rn: 8a.
`..
`.. -
`.. .
`.. -
`- __ ..,,.....
`r:n: 9a ...... ~
`P-CSCF
`S-CSCF ~
`P-CSCF
`S-CSCF ~
`4b. Possibility to !
`! 8b. Possibility to
`f
`break CS
`
`3. Possibility to!
`contact AS
`
`HSS !
`5.
`
`! 7. Possibility to
`contact AS
`
`1
`
`~
`
`'
`
`1-CSCF
`
`----~~~
`
`(
`
`'
`
`f break CS m
`BGCF i
`t
`
`BGCF! ..
`
`Figure 2.7 S-CSCF routing and basic IMS session setup
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 596
`
`

`

`86
`
`The IMS: IP Multimedia Concepts and Services
`
`Secondary PDP Context 1
`
`Data Conbllner 1
`
`Data Container 2
`
`QoS
`Traffic counters
`Timestamp
`Change coodiUOM
`
`OoS
`Traffic counters
`Times :amp
`Cha~ cond1\IOI'IS
`
`GC/0 1
`GGSNAddross
`oos
`etc
`
`Secondary PDP Context 2
`
`D~tJ Container 1
`
`QoS
`Traflic counters
`Timestamp
`Change condition•
`
`QoS
`Trafl'lc oountera
`Tmestarr9
`Change cond1IJOnl
`
`GCI02
`GGSNAddtess
`QoS
`etc
`
`Figure 3.20
`
`IMS charging correlation
`
`with which it is associated: for example, an ICID assigned for session establishment is
`valid until session termination, etc. We can see from Figure 3.21 that IMS and GPRS
`charging identifiers are exchanged when the bearer is authorized. In addition, Figure 3.21
`indicates when accounting requests are sent to the CDF. The address of the CDF is
`distributed during registration or, alternatively, it is configured in IMS entities.
`
`3.12 User Profile
`3. 12.1
`Introduction
`
`A user profile is a collection of user-specific information that is permanently stored in
`the HSS and downloaded to the S-CSCF when the S-CSCF needs to execute service
`for registered or un-registered user. The user profile contains at least one private user
`identity and single service profi le. Figure 3.22 depicts the general structure of a user
`profile [3GPP TS 29.228]. The private user identity is described in Section 3.5.2, but it
`should be understood that a user profile may contain more than one private user iden(cid:173)
`tity, if e.g. a user is using a shared public user identity as described in Section 3.7.
`Figure 3.4 shows that a single IMS subscription may contain multiple service pro(cid:173)
`files; this allows different treatment for different public user identities as explained in
`Section 3.5.3.
`Operator assigns a user profi le when a user obtains an IMS subscription from an operator.
`The profile is transferred from the HSS to an assigned S-CSCF in two user data-handling
`operations - Server-Assignment-Answer (SAA) and Push-Profile-Request (PPR) - as
`described in Sections 2.3.5.1 and 2.3.5.2. The service profile is carried in one Diameter
`AVP, where it is included as an Extensible Markup Language (XML) document. The
`service profile is further divided into four parts:
`
`• public identification;
`• core network service authorization;
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 597
`
`

`

`IMS Concepts
`
`87
`
`UE# 1 Home Network
`
`fll
`
`S-CSCF
`
`fll
`
`CCF/CGF
`
`fll
`
`1-CSCF
`
`P·CSCF
`
`fll
`..
`Allocate ICID j
`INVITE (ICIIl. SOP)
`l Service Control J
`.. ...
`
`AAR (ICID)
`""' AAA
`
`I INVITE 1101 I ID SOP)
`
`i
`
`rn.
`
`UE#1
`GGSN
`INVITE (SOP)
`
`rJl
`
`PCRF
`
`...
`
`J
`
`.. ...
`
`J
`
`l
`
`Session initiation continues
`
`[ Resource reservation ]
`1 CCR (GCID) ..
`...,. CCA (ICID)
`
`l Resource reservation J
`
`accepted
`UPDATE (SDP)
`
`..
`
`AAR
`
`....
`AAA (GCID).._
`
`F
`
`UPDATE (~ ~10, SOP)
`
`[
`
`Session initiation continue
`
`[ Open G-CDR for each 2nd J
`PDP context (ICID, GCID)
`
`200 OK(INVITE) 200 OK(INVITE)
`~ ACR Start ..
`
`200 OK(INVIl )
`""
`
`_[ Open S-CSCF-CDR
`(ICID, GCID(s)
`
`.... AC
`
`ACR Start
`
`....
`""'
`Session starts
`Partial G-CDR!(ICID, GCID)
`
`ACA
`
`[
`I
`
`[Open P-CSCF-CDR
`(ICID, GCID(s)
`
`I
`
`..
`...
`
`J
`I
`
`Figure 3.21 Distribution of charging information
`
`• initial filter criteria;
`• shared initial filter crite1ia set.
`
`3.12.2 Public Identification
`
`Public Identification identifies one or more identities for which a particular service
`profile will be executed. Identity can be either public user identity or public service
`identity.
`Each public user identity contains an associated barring indication and optional display
`name (e.g. Nokia Corporation). If the barring indication is set, then the S-CSCF will
`prevent that public identity (e.g., a temporary public user identity) from being used in
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 598
`
`

`

`88
`
`The IMS: IP Multimedia Concepts and Services
`
`Figure 3.22 Structure of IMS user profile
`
`any IMS communication other than registrations andre-registrations. If the display name
`is included the S-CSCF will distribute it to UE and P-CSCF during registration and the
`IMS network wiU confirm its usage during session setup i.e. far end can trust also the
`content of display name. In addition each public user identity can be marked to belong to
`a particular alias identity group. Two or more identities are aliases if the identities belong
`to the same implicit registration set, are linked to the same service profile and have the
`same service data configured for each and every service. Practically alias identities are
`expected to be treated in similar manner when operator executes services e.g. appling
`IM/PoC service settings.
`For public service identity Public Identification contains either exactly the public ser(cid:173)
`vice identity (e.g. createconference@conferenceserverl.com) or wildcarded public service
`identity (sip:chatlist!.*! @example.com) that matches to URis which begin with sip:chatlist
`and end with @example.com (e.g. sip:chatlistl@example.com and sip:chatlist.userx@
`example.com). Display name can be bind to public service identities but alias group(cid:173)
`ing and barring indications do not have a meaning in the context of public service
`identities.
`
`3.12.3 Core Network Service Authoriza~ion
`
`Two different capabilities for service authorization have been defined: media policy and
`IMS communication service identifier policy.
`Media policy information contains an integer that identifies a subscribed media profile
`in the S-CSCF (e.g., allowed SDP parameters). This information allows operators to
`define different subscriber profiles in their IMS networks. They may define different
`custo111er classes, such as gold, silver and bronze. Gold could mean that a user is able
`to make video calls and all ordinary calls. Silver could mean that a user is able to use
`wideband Adaptive Multi-Rate (AMR) as a speech codec, but they are not allowed to
`make video calls and so on. Transferring just the integer value between the HSS and the
`S-CSCF saves the storage space in the HSS and optimizes the usage of the Cx reference
`point.
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 599
`
`

`

`-----
`
`IMS Concepts
`
`89
`
`'1'
`
`Allowed media type
`Media profile id
`-
`- f --
`Video,audio, application
`audio, application
`application
`
`HSS
`
`S-CSCF
`
`Figure 3.23 Media authorization in S-CSCF
`
`The S-CSCF needs to have a static database that contains the mapping between the
`integer value and the subscribed media profile. The meaning of the integer value is not
`standardized (i.e., it is operator specific). Figure 3.23 gives an illustrative exan1ple.
`IMS communication service identifier policy contains a list of service identifiers that
`identifies which IMS communication service user is entitled to use. Based on the provided
`list the S-CSCF enforces usage of identifiers in SIP signalling. Details of IMS communi(cid:173)
`cation service identifier are covered in Section 11 .9".
`
`3.12.4 Service-Triggering Information
`
`Service-triggering information is presented in the form of initial filter criteria. Initial
`filter criteria describe when an incoming SIP message is further routed to a specific AS.
`User profile may contain both user specific service-triggering information which is coded
`as Initial Filter Criteria and a reference value to initial filter criteria which are locally
`administrated and stored in S-CSCF. The latter one is called Shared Initial Filter Crite1ia
`and it is encoded as an integer value where the integer value has only meaning inside
`single operator's network. For example, value I could point triggers that take care of
`routing requests to OMA IM, PoC, Presence and XDM applications and value 2 could
`point triggers that take care of routing requests to IMS multimedia telephony application
`and value 3 could point point triggers that take care of routing requests to IP Centrex (see
`Figure 3.24).
`Figure 3.25 shows that user specific Initial Filter Criteria are composed of either zero
`or one instance of a trigger point and one instance of an AS [3GPP TS 29.228]. Each
`initial filter criterion within the service profile has a unique priority value (integer) that
`is utilized in the S-CSCF. When multiple initial filter criteria are assigned the S-CSCF
`assesses them in numerical order: that is, an initial filter criterion with a higher priority
`number will be assessed after one with a smaller priority number.
`
`Value Shared Initial Filter Criteria
`
`'1'
`
`HSS
`
`S-CSCF
`
`'1'
`'2'
`'3'
`
`Triggers for OMA IM, POC, Presence, XDM
`Triggers for IMS Multimedia Telephony
`Triggers for IP Centrex
`
`Figure 3.24 Shared initial filter criteria
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 600
`
`

`

`90
`
`The IMS: IP Multimedia Concepts and Services
`
`Figure 3.25 Structure of initial filter criteria
`
`3.12.4.1 Trigger Point
`
`The trigger point describes conditions that should be checked to discover whether the
`indicated AS should be contacted. The absence of a trigger point will indicate uncondi(cid:173)
`tional triggering to an AS. Each trigger point contains one to multiple instances of the
`Service Point Trigger. Service Point Ttiggers may be linked b)' means of logical expres(cid:173)
`sions (AND, OR, NOT). Section 3.13 will give a more detailed explanation of how trigger
`points are used.
`
`3.12.4.2 Application Server (AS)
`
`The Application Server (AS) defines the AS that is contacted if the trigger points are
`met. The AS may contain information about the default handling of the session if contact
`with the AS fails. Default handling will either terminate the session or let the session
`continue based on the information in the initial filter criteria. In addition, the AS contains
`zero or one instance of the service information. Service information enables provisioning
`of information that is to be transferred transparently via the S-CSCF to an AS when the
`conditions of initial filter criteria are satisfied during registration.
`
`3.13 Service Provision
`3.13.1
`Introduction
`
`Strickly speaking the IMS is not a service in itself; on the contrary, it is a SIP-based
`architecture for enabling an advanced IP service and application on top of the PS net(cid:173)
`work. IMS provides the necessary means for invoking services; this functionality is called
`'service provision'. IMS service provisioning contains three fundamental steps:
`
`1. Define possible service or service sets.
`2. Create user-specific service data in the format of initial filter criteria when a user
`orders/modifies a subscription.
`3. Pass an incoming initial request to an AS.
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 601
`
`

`

`lMS Concepts
`
`91
`
`Item (1) is not addressed in this book because it is up to operators and service providers
`to define what kind of services they are willing to offer their subscribers. The other two
`steps are described next.
`
`3.1 3.2 Creation of Filter Criteria
`
`Whenever a user obtains an IMS subscription and their subscription contains some
`value-added services or an operator is willing to utilize ASs as part of its IMS infrastruc(cid:173)
`ture, they need to create service-specific data. These service-specific data are part of the
`user' s user profile. More precisely, service-specific data are represented as initial filter
`criteria. Hereafter, we only concentrate on initial filter criteria. Section 3.12 describes
`how initial filter criteria fit into a user profile. When constructing initial filter criteria an
`operator needs to consider these questions:
`
`• What is a trigger point?
`• What is the correct AS when the trigger point is met?
`• What is the priority of an initial filter criterion?
`• What should be done if the AS is not responding?
`
`The trigger point is used to decide whether an AS is contacted. It contains one to mul(cid:173)
`tiple instances of a Service Point Trigger [3GPP TS 29.228]. The Service Point Trigger
`comprises the items shown in Figure 3.26:
`
`• Request-URI- identifies a resource that the request is addressed to (e.g., sportnews@
`ims.example.com).
`• SIP Method - indicates the type of request (e.g., INVITE or MESSAGE).
`• SIP Header - contains information related to the request. A Service Point Trigger could
`be based on the presence or absence of any SIP header or the content of any SIP header.
`The value of the content is a string that is interpreted as a regular expression. A regular
`expression could be as simple as a proper noun (e.g., John) in the FROM header that
`indicates the initiator of the request.
`• Session Case- can be any one of four possible values, Originating, Terminating, Origi(cid:173)
`nating_Unregistered or Tenninating_Unregistered, that indicate whether the filter should
`be used by the S-CSCF that is handling the originating service, terminating service or
`originating/tem1inating for an unregistered end user service. An originating case refers
`to when the S-CSCF is serving the calling user. A terminating case refers to when the
`S-CSCF is serving the called user.
`
`Figure 3.26 Structure of service point trigger
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 602
`
`

`

`92
`
`The IMS: IP Multimedia Concepts and Services
`
`• Session Description - defines a Service Point Trigger for the content of any SDP field
`within the body of a SIP Method. Regular expressions can be used to match the
`trigger.
`
`Based on the above an operator could build, for example, initial filter criteria to handle
`unregistered users, such as an IMS user who has not registered any of their public user
`identities. The following initial filter criterion routes an incoming session to a voice mail
`server (sip:vmail@ims.example.com) when the user is not registered. To make this happen
`the operator has to set a SIP Method to match INVITE and a session case to match the
`value of Terminating_ Unregistered (value 2). If the voice mail server cannot be contacted,
`then the default handling should be that the session is terminated (value 1). Initial filter
`criteria are coded in XML, as shown below (see [3GPP TS 29.228] for the exact coding
`rules of initial filter criteria):
`
`<?xml version="l . O" encoding="UTF-8"?>
`<testDatatype xmlns :xsi="http://www.w3.org/2001/XMLSchema- instance"
`x si : noNamespaceSchemaLocation="D:\ CxDataType . xsd">
`<IMSSubscription>
`<Pri vatei D>privatexzyjoe@ims . example . com </Pr ivateiD>
`<ServiceProfile>
`<Publicidentity>
`<Identity>sip: joe . doe@ims . example.com </Identity>
`</Publicidentity>
`<Publicidentity>
`<Identity>tel : +358503334444</Identity>
`</Publ icidentity>
`<InitialFi lterCriteria>
`<Priority>O</Priority>
`<Tri ggerPoint>
`<ConditionTypeCNF>O</ConditionTypeCNF>
`<SPT>
`<ConditionNegated>O </ConditionNegated>
`<Group>O</Group>
`<Method>INVITE< /Method >
`</SPT>
`<SPT>
`<ConditionNegated>O</ConditionNegated>
`<Group>O< /Group>
`<SessionCase>2</SessionCase>
`</SPT>
`</TriggerPoint>
`< ApplicationServer>
`<ServerName>sip:vmai l @ims.example.com< /ServerName>
`<DefaultHandling>l</DefaultHandling>
`</ApplicationServer>
`</InitialFilterCr iteria>
`</ ServiceProfile>
`</IMSSubscription>
`</testDatatype>
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 603
`
`

`

`IMS Concepts
`
`3.13.3 Selection of AS
`
`93
`
`Initial filter criteria are downloaded to the S-CSCF on user registration or on a terminat(cid:173)
`ing initial request for an unregistered user. After downloading the user profile from the
`HSS, the S-CSCF assesses the filter criteria for the initial request alone, according to the
`following steps [3GPP TS 24.229]:
`
`1. Check whether the public user identity is barred; if not, then proceed.
`2. Check whether this request is an originating request or a terminating request.
`3. Select the initial filter criteria for a session case (origjnating, terminating, or origjnat(cid:173)
`ing/terminating for an unregjstered end user).
`4. Check whether this request matches the initial filter criterion that has the highest
`priority for that user by comparing the service profile with the public user identity that
`was used to place this request:
`• if this request matches the initial fi lter criterion, then the S-CSCF will forward
`this request to that AS, check to see whether it rriatcbes the next following filter
`criterion of lower priority and apply the filter criteria on the SIP Method received
`from the previously contacted AS;
`• if this request does not match the highest priority initial filter criterion, then check
`to see whether it matches the following filter criterion's priorities until one does
`match;
`• if no more (or none) of the initial filter criteria apply, then the S-CSCF will forward
`this request based on the route decision.
`
`There exists one clear difference in how the S-CSCF handles originating and terminating
`initial filter criteria. When the S-CSCF realizes that an AS has changed the Request-URI
`in the case of terminating initial filter criteria, it stops checking and routes the request
`based on the changed value of the Request-URI. In an originating case the S-CSCF will
`continue to evaluate initial filter "criteria until all of them have been evaluated.
`If the contacted AS does not respond, then the S-CSCF follows the default-handling
`procedure associated with initial filter ctiteria: that is, either terminate the session or let
`the session continue based on the information in the filter criteria. If the initial filter
`criteria do not contain instructions to the S-CSCF regarding the failure to contact the AS,
`then the S-CSCF will let the call continue as the default behaviour [3GPP TS 24.229].
`According to our initial filter criteria example, incoming INVITE requests will be
`routed to a voice mail server, vmail @ims.example.com, when Joe is not registered in the
`network. In exceptional cases, when the voice mail server is not responding, the S-CSCF
`is instructed to release a session attempt.
`
`(
`
`3.13.4 AS Behaviour
`
`Section 3.13.3 described bow the request is routed to an AS. After receiving the request
`the AS initiates the actual service. To carry the service out the AS may act in three
`different modes:
`
`• Terminating User Agent (UA) - the AS acts as the UE. This mode could be used to
`provide a voice mail service.
`
`APPENDIX M
`
`AT&T, Exh. 1003, p. 604
`
`

`

`94
`
`The IMS: rP Multimedia Concepts and Services
`
`• Redirect server- the AS informs the originator about the user's new location or about
`alternative services that might be able to satisfy the session. This mode could be used
`for redirecting the originator to a particular Web page.
`• SIP p