`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
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 1
`
`
`
`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
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 2
`
`
`
`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
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 3
`
`
`
`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
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 4
`
`
`
`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 di vided into four parts:
`
`• public identification;
`• core network service authorization;
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 5
`
`
`
`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
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 6
`
`
`
`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.
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 7
`
`
`
`-----
`
`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
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 8
`
`
`
`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.
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 9
`
`
`
`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
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 10
`
`
`
`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 </ConditionNega ted>
`<Group>O</Group>
`<Me thod>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>
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 11
`
`
`
`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.
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 12
`
`
`
`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 proxy - the AS processes the request and then proxies the request back to the
`S-CSCF. While processing, the AS may add, remove or modify the header contents
`contained in the SIP request according to the proxy rules specified in [RFC3261].
`• Third-party call control/back-to-back UA- the AS generates a new SIP request for a
`different SIP dialog, which it sends to the S-CSCF.
`
`In addition to these modes, an AS can act as an originating UA. When the application
`is acting as an originating UA it is able to send requests to the users: for example, a
`conferencing server may send SIP INVITE requests to a pre-defined number of people at
`9 am for setting up a conference call. Another example could be a news server sending
`a SIP MESSAGE to a soccer fan to let him know that his favourite team has scored a
`goal. See more examples of AS service execution in Chapters 4,6,7,8 and 9.
`
`3.14 Connectivity between Traditional CS Users and IMS Users
`3.14.1
`Introduction
`
`For the time being, most users utilize traditional CS UE: that is, fixed line telephones
`and all kinds of cellular terminals. Therefore, it is desirable for the IMS to interwork
`with legacy CS networks to support basic voice calls between IMS users and CS network
`users. This requires interworking both at the user plane and the control plane because the
`used protocols are different in both planes. Control-plane interworking is tasked to the
`MGCF. It performs mapping from SIP signalling to the BICC or ISUP used in CS legacy
`networks, and vice versa. The IMS Media Gateway (IMS-MGW), in tum, translates pro(cid:173)
`tocols at the user plane. lt terminates the bearer channels from the CS (PSTN/ISDN/GSM)
`networks as well as media streams from IP or ATM-based PS networks and provides the
`translation between these terminations. Additional functions, such as codec interworking,
`echo cancellation and continuity check, can also be provided. The terminations are con(cid:173)
`trolled by the MGCF. Network configurations for handling both IMS and CS-originated
`calls are explained next.
`
`3.14.2 JMS-Originated Session Toward a User in the CS Core Network
`
`When an IMS user initiates a session she does not need to bother about whether the
`called user is an IMS user or a CS user. She simply makes a call and the IMS takes
`care of finding the called party. The session request from the calling user will always
`arrive at the S-CSCF serving the calling user, based on a route learned during IMS
`registration. When the S-CSCF receives a session request using a tel URL type of user
`identity (tel:+358501234567), it has to perform an ENUM query to convert the tel URI to
`a SIP URI, as IMS routing principles do not allow routing with tel URis. If the S-CSCF
`is able to convert the identity to SIP URI format it will route the session further to the
`target IMS network, and when this conversion fails the S-CSCF will try to reach the
`user in the CS network. To break out to the CS network, the S-CSCF routes the session
`
`AT&T Exhibit 1023
`AT&T v. VoIP, IPR 2017-01383
`Page 13
`
`