X.S0013.003 IMS Call Model Final Version

1
13GPP2X.S0013003
2Version1.0.0
3VersionDate:December2003
4
5
6
AllIPCoreNetworkMultimediaDomain
7
8
9
10
IP Multimedia (IMS) session handling;

IP Multimedia (IM) Call Model;
Stage 2
11
12
13
14
15
16
17
18
19
20
COPYRIGHTNOTICE
3GPP2anditsOrganizationalPartnersclaimcopyrightinthisdocumentandindividualOrganizationalPartners
maycopyrightandissuedocumentsorstandardspublicationsinindividualOrganizationalPartner'snamebasedon
thisdocument.Requestsforreproductionofthisdocumentshouldbedirectedtothe3GPP2Secretariatat
secretariat@3gpp2.org.RequeststoreproduceindividualOrganizationalPartner'sdocumentsshouldbedirectedto
thatOrganizationalPartner.Seewww.3gpp2.orgformoreinformation.
21
22
23
1X.P0013-003
1
2
ii
X.P0013-003
Contents
3
4Foreword......................................................................................................................................... 1
51
Scope...................................................................................................................................... 1
62
References.............................................................................................................................. 1
73
Definitions and abbreviations................................................................................................... 2
3.1
Definitions......................................................................................................................... 2
3.2
Abbreviations.................................................................................................................... 3
104
Architecture and information flows for IM multimedia session.................................................4
11
4.1
Architecture for a mobile originated IP multimedia session..............................................4
12
4.2
Architecture for a mobile terminated IP multimedia session.............................................4
13
4.3
Information flow for a mobile originated IP multimedia session........................................4
14
15
4.4
Information flow for retrieval of routing information for mobile terminated IP multimedia
session........................................................................................................................................ 4
16
4.5
175
Information flow for a mobile terminated IP multimedia session.......................................4
Functional requirements of network entities............................................................................5
18
5.1
Architecture for service provision for IP multimedia subsystem........................................5
19
5.2
Service interaction with IP multimedia subsystem............................................................6
206
Functional requirements of serving CSCF...............................................................................8
21
22
23
24
25
26
27
28
29
6.1
Modes of operation of the S-CSCF...................................................................................8
6.1.1
General overview of functional models and modes of operation of the S-CSCF....................8
6.2
Interfaces defined for S-CSCF.......................................................................................... 9
6.2.1
S-CSCF CSCF (Mw) interface..............................................................................................9
6.2.2
S-CSCF Application Server (ISC) interface..........................................................................9
6.2.3
S-CSCF HSS (Cx) interface..................................................................................................9
6.2.4
S-CSCF MRFC (Mr) Interface..............................................................................................9
6.2.5
S-CSCF IP Multimedia Network (Mm) interface.................................................................9
6.3
Handling of SIP registration.............................................................................................. 9
30
6.4
31
32
33
34
35
36
37
6.5
Handling of mobile terminating requests.........................................................................11
6.5.1
Handling of mobile terminating requests, registered user......................................................11
6.5.2
Handling of mobile terminating requests, unregistered user..................................................11
6.6
Handling of IP multimedia session release requests.......................................................11
6.6.1
S-CSCF proxying release request...........................................................................................11
6.6.2
S-CSCF initiating release request...........................................................................................12
6.7
Handling of subscription and notification........................................................................12
38
6.8
39
40
41
42
6.9
Description of subscriber data........................................................................................13
6.9.1
Application Server subscription information.........................................................................13
6.9.2
Filter Criteria..........................................................................................................................13
6.9.3
Authentication data.................................................................................................................14
Handling of mobile originating requests..........................................................................10
S-CSCF handling IMS accounting..................................................................................13
1X.P0013-003
17
Functional requirements of HSS............................................................................................ 14
7.1
3
4
5
6
7
8
7.2
Interfaces defined for HSS.............................................................................................15
7.2.1
HSS CSCF (Cx) interface....................................................................................................15
7.2.2
HSS - Application Server (Sh) interface................................................................................15
7.2.3
Void........................................................................................................................................15
7.2.4
Void.........................................................................................................................................15
7.3
Procedures during IP multimedia registration.................................................................15
7.4
108
Subscriber data related storage requirements for HSS..................................................14
Procedures during IP multimedia sessions.....................................................................15
Functional requirements of the MRFC...................................................................................15
11 8.1
Functionality of the MRFC..............................................................................................15
12
8.1.1
Overview of MRFC Functionality..........................................................................................15
13
8.1.2
Tones and announcements......................................................................................................16
14
8.1.3
Ad hoc conferences (multiparty calls)....................................................................................16
15
8.1.4
Transcoding............................................................................................................................16
16 8.2
Interfaces defined for MRFC...........................................................................................17
17
8.2.1
MRFC S-CSCF (Mr) interface............................................................................................17
189 Generic IP multimedia session handling for SIP Application Servers....................................18
19 9.1
Architecture.................................................................................................................... 18
20
9.1.1
Modes of operation between Application Server and S-CSCF..............................................19
21 9.2
Interfaces defined for a SIP Application Server..............................................................21
22
9.2.1
S-CSCF Application Server (ISC) interface........................................................................21
23
9.2.2
Application Server HSS (Sh) interface................................................................................21
24 9.3
Description of Application Server related subscriber data..............................................21
25
9.3.1
Application server subscription information..........................................................................21
26 9.4
Procedures for multimedia session handling with a SIP based Application Server.........22
27
9.4.1
Application Server handling of mobile originating requests..................................................22
28
9.4.2
Application Server handling of mobile terminating requests.................................................22
29
9.4.3
Application Server handling of SIP registration.....................................................................22
30
9.4.4
Application Server handling of IP multimedia session release requests................................23
31
9.4.5
Application server handling of IP multimedia accounting.....................................................24
3210
Void.................................................................................................................................... 24
3311
IP multimedia session handling with an OSA-Service Capability Server............................24
3412.
IP multimedia session handling with an Charging Server..................................................25
35Annex A (informative): Scalability and deployment considerations for IP multimedia service

36provision....................................................................................................................................... 26
37Annex B (informative): Information flows for example services.....................................................28
38B.1
39
40
41
42
43
44
45B.2
Call forwarding example..................................................................................................... 28

B.1.1
Call forwarding through Application Servers.........................................................................28
B.1.1.1
Service activation and programming..................................................................................29
B.1.1.2
Service invocation and control...........................................................................................29
B.1.2
Assumptions...........................................................................................................................30
B.1.3
UE redirect based call flows...................................................................................................30
B.1.4
S-CSCF based redirect call flows...........................................................................................31
Announcement, conferencing and transcoding examples using MRFC.............................33
ii
X.P0013-003
1
2
3
4
5
6
7B.3
B.2.1
Example information flow for a mobile originated IP multimedia session that results in
playing an announcement.......................................................................................................................33
B.2.2
Example information flow for a mobile originated IP multimedia ad hoc conferencing
session (multiparty call).........................................................................................................................35
B.2.3
Example information flows for a mobile originated IP multimedia session that requires
transcoding.............................................................................................................................................37
Example information flows for a voicemail service.............................................................41
B.3.1
User out of coverage message recording...................................................................41
B.3.2
User IMS registers voice mail service plays back messages......................................43
10Annex C (informative): Example for Initial filter criteria triggering.................................................46

11
iii
1X.P0013-003
1
2
3
4Revision History
5
Revision
0
Changes
Date
TBD 2003
Initial Publication
6
7
iv
Foreword
2
3
This Technical Specification has been produced by the 3 rd Generation Partnership Project 2 (3GPP2)
based on material contained in 3GPP specification TS 23.218.
4
5
6
7
8
9
10
11
This document contains portions of material copied from 3GPP document number(s) TS 23.218. The
copyright on the 3GPP document is owned by the Organizational Partners of 3GPP (ARIB Association of Radio Industries and Businesses, Japan; CWTS China Wireless Telecommunications
Standards group, China; ETSI European Telecommunications Standards Institute; Committee T1,
USA; TTA - Telecommunications Technology Association, Korea; and TTC Telecommunication
Technology Committee, Japan), which have granted license for reproduction and for use by 3GPP2
and its Organizational Partners.
X.P0013-003
11
Scope
2The present document specifies the IP Multimedia (IM) Call Model for handling of an IP multimedia
3session origination and termination for an IP Multimedia subscriber.
4The present document includes interactions between an Application Server and IP multimedia sessions.
5The IP Multimedia (IM) Subsystem stage 2 is specified [3] and the stage 3 for the IP multimedia call
6control based on SIP and SDP is specified in [5].
72
References
8The following documents contain provisions which, through reference in this text, constitute provisions of
9the present document.
10 References are either specific (identified by date of publication, edition number, version number,
11
etc.) or non-specific.
12 For a specific reference, subsequent revisions do not apply.
13 For a non-specific reference, the latest version applies.
14
15[1]
Void.
16[2]
17
3GPP2 S.R0037, IP Network Architecture Model for cdma2000 Spread Spectrum Systems,
Version 3.0, September, 2003.
18[3]
3GPP2 X.S0013-002: " IP multimedia subsystem; Stage 2".
19[4]
Void
20[5]
3GPP2 X.S0013-004: "IP multimedia call control protocol based on SIP and SDP; stage 3".
21[6]
IETF RFC 3261: "SIP: Session Initiation Protocol".
22[7]
3GPP2 X.S0017: "Open Service Access (OSA); Application Programming Interface (API) ".
23[8]
24
3GPP2 X.S0013-005: "IP Multimedia (IM) Subsystem Cx Interface; Signalling flows and message
contents".
25[9]
Void
26[10]
Void
27[11]
3GPP2 S.S0086-0: 3GPP2 IMS Security Framework.
28[12]
Void
29[13]
IETF RFC 3265: "Session Initiation Protocol (SIP) Event Notification".
30[14]
Void
31[15]
IETF RFC 3264: "An Offer/Answer Model with Session Description Protocol".
32[16]
Void
33 [17] 3GPP2 X.S0013-006: "Cx Interface based on the Diameter protocol".

34[18]
35
3GPP2 X.S0013-010: "IP Multimedia Subsystem (IMS) Sh Interface; Signalling flows and message
contents".
36[19]
3GPP2 X.S0013-011: "Sh Interface based on the Diameter protocol".
37[20]
3GPP2 X.S0013-007: " Accounting Architecture and stage 2 Description".
1X.P0013-003
1[21]
3GPP2 X.S0013-008: " IP Multimedia subsystem Accounting stage 3".
23
Definitions and abbreviations
33.1
Definitions
4For the purposes of the present document, the terms and definitions given in [2] and the following apply:
5
6Application Server Incoming Leg Control Model (AS-ILCM): models AS behavior for handling SIP
7information for an incoming leg.
8
9Application Server information (AS-info): AS-info contains individualized information concerning one
10particular Application Server entry.
11This information contains e.g. Application Server Address (6.9.2.1) and it's corresponding Default IP
12Multimedia Handling information (6.9.2.2).
13
14Application Server Outgoing Leg Control Model (AS-OLCM): models AS behaviour for handling SIP
15information for an outgoing leg.
16
17Combined ILSM OLSM Incoming/outgoing Leg State Model: models the behaviour of an S-CSCF
18for handling SIP messages on an incoming and outgoing session leg.
19
20Filter Criteria (FC): the information which the S-CSCF receives from the HSS or the AS that defines the
21relevant SPTs for a particular application.
22They define the subset of SIP requests received by the S-CSCF that should be sent or proxied to a particular
23application.
24
25Incoming Leg Control Model (ILCM): models the behaviour of an S-CSCF for handling SIP information
26sent to and received from an AS for an incoming session leg.
27
28Initial Filter Criteria (iFC): filter criteria that are stored in the HSS as part of the user profile and are
29downloaded to the S-CSCF upon user registration.
30They represent a provisioned subscription of a user to an application.
31
32Initial Request: a SIP request that either initiates the creation of a new dialog or is part of a standalone
33transaction.
34
35IP Multimedia session: IP Multimedia session and IP Multimedia call are treated as equivalent in the
36present document.
37
38IP Transport Subsystem: refers to any collection of network entities that provides the underlying IP
39transport for use to provide connectivity to or between IMS entities.
40
41Outgoing Leg Control Model (OLCM): models the behavior of an S-CSCF for handling SIP information
42received from and sent to an AS for an outgoing session leg.
43
44Private User Identity: a unique global identity defined by the Home Network Operator, as defined in [3].
45
46Public User Identity: the public user identity/identities are used by any user for requesting
47communications to other users and are in the form of a SIP URI or TEL URL as defined in [3].
48
49Service Point Trigger (SPT): a point in the SIP signaling that may cause the S-CSCF to send/proxy the
50SIP message to an SIP AS or an OSA SCS.
51The subset of all possible SPTs which are relevant to a particular application are defined by means of Filter
52Criteria.
X.P0013-003
1
2Service Platform Trigger Points (STP): the points in the SIP signaling that instruct the SIP AS and OSA
3SCS to trigger the service logic.
4
5 Subsequent Filter Criteria (sFC): filter criteria that are signaled from the SIP AS or the OSA SCS to the
6S-CSCF.
7They allow for dynamic definition of the relevant SPTs at application execution time.
8
9Subsequent Request: a SIP request which is part of an existing dialog. This also includes target refresh
10requests as defined in RFC 3261 [6].
11
12Standalone Transaction: a SIP transaction that is not part of an existing dialog and does not initiate the
13creation of a new dialog.
143.2
Abbreviations
15For the purposes of the present document, the following abbreviations apply:
16 API
Application Programming Interface
17 AS
Application Server
18 AS-ILCM
Application Server Incoming Leg Control Model
19 AS-OLCM
Application Server Outgoing Leg Control Model
20 B2BUA
Back-to-Back User Agent
21 ACF
Accounting Collection Function
22 CF
Call Forwarding
23 CFonCLI
Call Forwarding on Calling Line Identification
24 CGI
Common Gateway Interface
25 CPL
Call Processing Language
26 CLI
Calling Line Identification
27 CSCF
Call Session Control Function
28 ECF
Event Charging Function
29 FC
Filter Criteria
30 HPLMN
Home PLMN
31 HSS
Home Subscriber Server
32 IETF
Internet Engineering Task Force
33 I-CSCF
Interrogating CSCF
34 ICID
IMS Charging ID
35 ICN
IP Connectivity Network
36 iFC
Initial Filter Criteria
37 ILCM
Incoming Leg Control Model
38 IM
IP Multimedia
39 IMS
IP Multimedia Subsystem
40 IOI
Inter Operator Identifier
41 IP
Internet Protocol
42 ISC
IP multimedia Service Control
43 MGCF
Media Gateway Control Function
44 MO
Mobile Originating
45 MRFC
Multimedia Resource Function Controller
46 MRFP
Multimedia Resource Function Processor
47 MT
Mobile Terminating
48 OLCM
Outgoing Leg Control Model
49 OSA
Open Service Access
50 PLMN
Public Land Mobile Network
51 P-CSCF
Proxy CSCF
52 RFC
Request For Comments
53 SCF
Session Charging Function
54 SCIM
Service Capability Interaction Manager
1X.P0013-003
1
2
3
4
5
6
7
8
9
10
11
12
SCS
SDP
sFC
SIP
S-CSCF
SPT
STP
UA
UE
URL
URI
XML
Service Capability Server

Session Description Protocol
Subsequent Filter Criteria
Session Initiation Protocol
Serving CSCF
Service Point Trigger
Service platform Trigger Points
User Agent
User Equipment
Uniform Resource Locator
Uniform Resource Identifier
Extensible Markup Language
134
Architecture and information flows for IM multimedia
14session
15Clauses 4.1 and 4.2 show the architecture for handling a basic MO multimedia session and a basic MT
16multimedia session. A basic mobile-to-mobile multimedia session is treated as the concatenation of a MO
17multimedia session and a MT multimedia session.
18Clauses 4.3, 4.4 and 4.5 show the information flows for handling a basic MO multimedia session and a
19basic MT multimedia session.
204.1
Architecture for a mobile originated IP multimedia session
21This is specified in [3].
224.2
Architecture for a mobile terminated IP multimedia session
23This is specified in [3].
244.3
Information flow for a mobile originated IP multimedia session
25The information flow for a MO multimedia session is specified in [3].
264.4
Information flow for retrieval of routing information for mobile
27terminated IP multimedia session
28The information flow for retrieval of routing information for a MT multimedia session is specified in [3].
294.5
Information flow for a mobile terminated IP multimedia session
30The information flow for a MT multimedia session is specified in [3].
X.P0013-003
25
Functional requirements of network entities
35.1
Architecture for service provision for IP multimedia subsystem
AS
11/Sh
AS
SCIM
SIP
SIPApplication
Application
Server
Server
11/Sh
HSS
HSS
12/ISC
S-CSCF
S-CSCF
16/Cx
12/ISC
OSA
OSAservice
service
capability
capabilityserver
server
(SCS)
(SCS)
OSA
OSA
application
application
server
server
8/OSA API
24/Mr
MRFC
MRFC
5
6
7
8
9
NOTE: Not all interfaces shown are within the scope of this document.
Figure 5.1.1: Functional architecture for support of service provision for IP multimedia
subsystem
10Figure 5.1.1 illustrates the architecture with the S-CSCF communicating to Application Servers via the IP
11multimedia service control (ISC) interface. The Application Servers can be:
12 - SIP Application Servers - which may host and execute services. It is intended to allow the SIP
13
Application Server to influence and impact the SIP session on behalf of the services;
14
15
16
17
18
19
20
- the OSA service capability server (OSA SCS) which interfaces to the OSA framework Application
Server and which provides a standardized way for third party secure access to the IM subsystem.
The OSA reference architecture defines an OSA Application Server as an entity that provides the
service logic execution environment for client applications using the OSA API as specified in [7].
This definition of Application Server differs from the definition of Application Server in the context
of service provisioning for the IM subsystem, i.e. the entity communicating to the S-CSCF via the
ISC interface;
21
22
in addition a specialized type of SIP Application Server, the service capability interaction manager
(SCIM) which performs the role of interaction management between other application servers.
23All the Application Servers, (including the OSA SCS) behave as SIP application servers on the ISC
24interface.
25In addition the Application Servers can also interact with the MRFC via the S-CSCF (ISC and Mr
26interfaces) in order to control Multimedia Resource Function processing.
1X.P0013-003
15.2
Service interaction with IP multimedia subsystem
2Service Point Triggers (SPTs) are those points in the SIP signalling on which Filter Criteria can be set. The
3following SPTs are defined:
4 - any initial known or unknown SIP method (e.g. REGISTER, INVITE, SUBSCRIBE, MESSAGE);
5
presence or absence of any header field;
content of any header field or Request-URI;
7
8
direction of the request with respect to the served user either mobile originated (MO) or mobile
terminated (MT) to registered user; or mobile terminated to unregistered user;
NOTE 1: REGISTER is considered part of the Mobile Origination.
10
11
NOTE 2: The S-CSCF shall verify if the end user is barred before checking if any trigger applies for
that end user.
12
session description information.
13A Filter Criteria triggers one or more SPTs in order to send the related request to one specific application
14server. The set of Filter Criteria that is stored for a service profile of a specific user is called "Application
15Server Subscription Information". In order to allow the S-CSCF to handle the different Filter Criteria in the
16right sequence, a priority shall be assigned to each of them. If the S-CSCF can not reach the AS, the S17CSCF shall apply the default handling associated with the trigger. This default handling shall be :
18 - to continue verifying if the triggers of lower priority in the list match; or
19
20
to abandon verification of matching of the triggers of lower priority in the list; and to release the
dialogue.
21Therefore a Filter Criteria shall contain the following information:

22 - address of the Application Server to be contacted;
23
priority of the Filter Criteria providing the sequence in which the criteria shall be applied;
24
25
Trigger Points, which indicate the Service Point Triggers (SPTs) triggered by this Filter Criteria. The
SPTs may be linked by means of logical expressions (AND, OR, NOT, etc.);
26
default handling ( as described above);
27
optional Service Information that shall be added to the message body before it is sent to the AS
28The same priority shall not be assigned to more than one initial Filter Criteria for a given end user.
29The S-CSCF shall request from the HSS the relevant set of iFCs that applies to the end user (i.e., registered,
30unregistered, or both). If the S-CSCF has a set of iFCs that is deemed valid (e.g., from a previous request),
31the S-CSCF need not request a new set.
32In the case that multiple Filter Criteria are sent from the HSS to the S-CSCF when the S-CSCF receives a
33message via the Mw interface [3], the S-CSCF shall check the filter criteria one by one according to their
34indicated priority, i.e. the S-CSCF shall:
35 1. set up the list of filter criteria for that request according to their priority the sequence of the filter
36
criteria shall not be changed until the request finally leaves the S-CSCF via the Mw interface again;
37
38
2. parse the received request in order to find out the Service Point Triggers (SPTs) that are included in
it;
39
40
3. check whether the trigger points of the filter criteria with the next highest priority are matched by
the SPTs of the request and
41
a) if it does not match the S-CSCF shall immediately proceed with step 4;
X.P0013-003
b) if it matches the S-CSCF shall:
1
2
3
4
i) add an indication to the request which will allow the S-CSCF to identify the message on the
incoming side, even if its dialog identification has been changed e.g. due to the AS
performing third party call control;
5
6
7
ii) forward the request via the ISC interface to the AS indicated in the current filter criteria. The
AS then performs the service logic, may modify the request and may send the request back to
the S-CSCF via the ISC interface;
iii) proceed with step 4 if the request was received again from the AS via the ISC interface;
9
10
4. repeat the above steps 2 and 3 for every filter criteria which was initially set up (in step 1) until the
last filter criteria has been checked;
11
5. route the request based on normal SIP routing behaviour.
12If an Application Server decides to locally terminate a request and sends back a final response for that
13request via the ISC interface to the S-CSCF, the S-CSCF shall abandon verification of the matching of the
14triggers of lower priority in the list. The final response shall include the indicator defined in step 3 b) i)
15above, so that the S-CSCF can correlate the messages.
16
Application Server
Service Logic
Service Platform Trigger Points
HSS
SIP Interface
iFC
sFC
SIP
S-CSCF
SIP
17
18
S
P
T
Filter Criteria
SIP
Figure 5.2.1: Application triggering architecture
19Each invoked Application Server/service logic may decide not to be engaged with the invoked session by
20indicating that during the very first SIP transaction when the Record-Route/Route is generated for
21subsequent SIP requests. The denial shall mean that subsequent requests shall not be routed to such
22Application Servers/service logic any more during the lifetime of that session. Any Application Server,
23which has determined that it will not receive subsequent requests for a session cannot revoke this
24determination by means of Initial Filter Criteria (iFC).
1X.P0013-003
1
2
3
4
5
6
7
NOTE:
Care should be taken in design of the Initial Filter Criteria when designing services to avoid
unintended loops being setup, where requests from an Application Server may be sent back to
the same Application Server. This does not imply that it is not allowed for requests to be sent
back to the same Application Server when that is intended behaviour as part of the design of
the service and the Application Server is able to handle this correctly. Special care should be
taken for the case when an Application Server may act as an originating UA or B2BUA and
may originate an initial request causing evaluation of Initial Filter Criteria.
96
Functional requirements of serving CSCF
106.1
Modes of operation of the S-CSCF
116.1.1
General overview of functional models and modes of operation of the S-CSCF
Application
Server(s)
HSS
ISC
Cx
ILCM
OLCM
Incoming Leg
Outgoing Leg
Combined ILSM OLSM
Registrar and
Notifier
Call Records
Model
S-CSCF
External Signaling
12
13
14
Internal Processing
Figure 6.1.1.1: S-CSCF functional model with incoming leg control and outgoing leg
control
15Figure 6.1.1.1 identifies the components of a functional model of the S-CSCF.

16 NOTE: These components are defined only as a model of the expected behaviour of the S-CSCF and
17
are not intended to define or constrain the actual implementation.
X.P0013-003
1The components include the Combined ILSM OLSM, the ILCM and OLCM and the Registrar and Notifier.
2There is a single Combined ILSM OLSM, which shall be able to store session state information. It may act
3on each leg independently, acting as a SIP Proxy, Redirect Server or User Agent dependant on the
4information received in the SIP request, the filter conditions specified or the state of the session.
5It shall be possible to split the application handling on each leg and treat each endpoint differently.
6There is a single ILCM, which shall store transaction state information.
7There is a single OLCM, which shall store transaction state information.
8The Registrar component handles registration and subscription to and notification of registration events.
9The Notifier handles subscription to and notification of events.
106.2
Interfaces defined for S-CSCF
116.2.1 S-CSCF CSCF (Mw) interface

12The protocol used between two CSCFs is also based on Session Initiation Protocol, which is specified in
13[5].
146.2.2 S-CSCF Application Server (ISC) interface
15The protocol used between the S- CSCF and the Application Servers (ISC interface) is also based on
16Session Initiation Protocol, which is specified in [5].
176.2.3 S-CSCF HSS (Cx) interface
18This interface is used to send subscriber data to the S-CSCF; including Filter criteria, which indicates
19which SIP requests should be proxied to which Application Servers.
20The protocol used between the S-CSCF and HSS (Cx Interface) is specified in [8].
216.2.4 S-CSCF MRFC (Mr) Interface
22The protocol used between MRFC and S-CSCF is based on Session Initiation Protocol, which is specified
23in [5].
24
256.2.5 S-CSCF IP Multimedia Network (Mm) interface.
26The protocol used between S-CSCF and an IP multimedia network is based on Session Initiation Protocol,
27which is specified in [5].
286.3
Handling of SIP registration
29Upon receiving the initial registration request from the user, the S-CSCF shall authenticate the user and
30upon receiving a subsequent registration request containing valid authentication credentials, request the
31HSS to send the relevant service profile(s) for the users subscription. More than one service profile may be
32sent, depending on configuration options for identifying implicitly registered public user identities. For
33further detailed information on registration, profile download and authentication procedures see [5] and
34[11].
35The initial filter criteria (subset of the profile) is stored locally at the S-CSCF, as specified in [5].
36The S-CSCF shall verify if the triggers match, from the highest to the lowest priority (see subclause 5.2).
37After a successfully authenticated registration, the S-CSCF shall download from the HSS all the implicitly
38registered public user identities associated with the registered public user identity. The S-CSCF shall then
39verify, in their order of priority, if the triggers downloaded from the HSS match. If the registration request
40from the user matches a trigger, the S-CSCF performs a third party registration to the application servers
41which are interested to be informed about the user registration event of these public user identities. This
42may trigger services to be executed by an AS.
43The important information carried in the third party REGISTER request is the public user identity, the S44CSCF address and the expiration time. It shall be possible based on operator configuration to use one of
45the implicitly registered public user identities as the public user identity in the To header of the third party
46REGISTER request sent to the Application Server. Additional application server specific data, which is
1X.P0013-003
1associated with the Filter Criteria and obtained from the HSS, is added to the REGISTER request body.
2This data should include the private user identity for Application Servers as received from the HSS.
3This third party registration will include an expiration time that is equal to the expiration time sent to the
4UE by the S-CSCF in the 200 OK response to the incoming REGISTER request
5On receiving a failure response to one of the REGISTER requests, the S-CSCF shall apply the "default
6handling" related with the initial Filter Criterias trigger used (see subclauses 5.2, 6.9.2.2).
7See figure 6.3.1:
HSS
From: UserA
To: User A
Call-ID: X
2. Cx
1. SIP REGISTER
S-CSCF
3. SIP 200 OK
4. Filter Checking
From: S-CSCF
To: User A
Call-ID: Z
Contact: S-CSCF
5.SIP REGISTER
6. SIP 200 OK
Application
Server
From: UserA
To: User A
Call-ID: X
Figure 6.3.1: S-CSCF handling registration
10Application Servers can in addition subscribe to the Public User Identitys Registration Event Package.
11This provides a mechanism for the Application Server to discover all the implicitly registered public user
12identities without requiring multiple Register requests to be sent to the Application Server. The S-CSCF
13will send NOTIFY requests to the Application Server that has subscribed to the registration event package
14for the registered public user identity.
15More information on these procedures is contained in [5].
166.4
Handling of mobile originating requests
17The S-CSCF shall verify if the public user identity is barred. If so, it shall respond with an error code and
18stop further session processing.
19The S-CSCF only looks for initial filter criteria when receiving an initial request.
20The initial filter criteria (subset of the profile) has already been downloaded from the HSS and is stored
21locally at the S-CSCF, as specified in [5].
22When such a session request comes in, the S-CSCF shall first check its trigger points (i.e. this is a mobile
23originating request or a mobile terminating request). This clause describes the requirements for the S-CSCF
24when this request is a mobile originating request. So the S-CSCF shall:
25 - check whether this request matches the initial filter criteria with the highest priority for that user by
26
checking the service profile against the public user identity, which was used to place this request;
27
28
29
if this request matches the initial filter criteria, the S-CSCF shall forward this request to that
application server, then check for matching of the next following filter criteria of lower priority, and
apply the filter criteria on the SIP method received from the previously contacted application server;
30
31
if this request does not match the highest priority initial filter criteria, check for matching of the
following filter criteria priorities until one applies;
32
33
if no more (or none) of the initial filter criteria apply, the S-CSCF shall forward this request
downstream based on the route decision;
34
35
36
in any instance, if the contact of the application server fails, the S-CSCF shall use the "default
handling" associated with the initial Filter Criteria to determine if it shall either terminate the call or
let the call continue based on the information in the filter criteria; if the filter criteria does not
10
X.P0013-003
contain instruction to the S-CSCF regarding the failure of the contact to the application server, the
S-CSCF shall let the call continue as the default behaviour.
1
2
36.5
Handling of mobile terminating requests
46.5.1 Handling of mobile terminating requests, registered user

7The S-CSCF only looks for initial filter criteria when receiving an initial request. A terminating initial
8request may also originate from an Application Server via the ISC interface. Terminating Initial requests
9from an Application Server via the ISC interface also cause the S-CSCF to look for initial filter criteria.
10
11When such a request comes in, the S-CSCF shall first check this is an originating request or a terminating
12request. This clause describes the requirements for the S-CSCF when this request is a terminating request.
13So, if this request is a terminating request, the S-CSCF shall:
14 - use the initial Filter Criteria for the Mobile Terminating request;
15
the subsequent requirements for the S-CSCF are the same as those for handling originating requests.
16It may be possible that originating UE and terminating UE shares the same S-CSCF and AS, therefore the
17shared application server may interact with the S-CSCF twice in one transaction but in originating and
18terminating procedures respectively.
196.5.2 Handling of mobile terminating requests, unregistered user
22The S-CSCF only looks for initial filter criteria when receiving an initial request. A terminating initial
23request may also originate from an Application Server via the ISC interface. Terminating Initial requests
24from an Application Server via the ISC interface also cause the S-CSCF to look for initial filter criteria.
25
26When such a request comes in, the S-CSCF shall first check this is an originating request or a terminating
27request. This clause describes the requirements for the S-CSCF when this request is a terminating request.
28So, if this request is a terminating request, the S-CSCF shall:
29 - if unavailable, download the relevant subscriber profile including the initial filter criteria from the
30
HSS;
31
use the initial Filter Criteria for the Mobile Terminating request to unregistered user;
32
the subsequent requirements for the S-CSCF are the same as those for handling originating requests.
33It may be possible that originating UE and terminating UE shares the same S-CSCF and AS, therefore the
34shared application server may interact with the S-CSCF twice in one transaction but in originating and
35terminating procedures respectively.
366.6
Handling of IP multimedia session release requests
37In handling session release, the S-CSCF may either proxy the release request or initiates a release request.
386.6.1 S-CSCF proxying release request
39When the S-CSCF receives a release request from some entities (etc, application server, user agent) for a
40dialog, it proxies the release request to the destination according to route information in that release
41request.
11
1X.P0013-003
S-CSCF
SIP BYE
1
2
SIP BYE
From: X
To: Y
Call-ID: Z
From: X
To: Y
Call-ID: Z
Figure 6.6.1.1: S-CSCF proxying release request
36.6.2 S-CSCF initiating release request

4For some reason (e.g., administration decision of the network), the S-CSCF may be required to release an
5ongoing dialog. In this case, the S-CSCF shall send a release request to all the entities that are involved in
6this dialog. In a typical AS involved dialog, the S-CSCF should send the release request to the AS and the
7UE it is serving as shown in figure 6.6.2.1.
SIP BYE (To

UE)
8
9
106.7
SIP BYE
(To AS)
S-CSCF
From: X
To: Y
Call -I D: Z
Cseq: A
From: X
To: Y
Call-ID: Z
Cseq: B
Figure 6.6.2.1: S-CSCF initiating release request
Handling of subscription and notification
11The S-CSCF supports subscription to and notification of user registration events by the UE, P-CSCFs and
12Application Servers using the mechanisms specified in [13]. The subscribing entity may subscribe to the
13registration state of individual public user identities for the purpose of discovering the implicitly registered
14public user identities. When notifying a subscribing entity of a change in the registration state of a
15subscribed to public user identity the S-CSCF shall include in the notification all the implicitly registered
16public user identities associated with the registered public user identity in addition to the registered public
17user identity.
Application
Server
From: X
To: Y
Call-ID: Z
SUBSCRIBE
SIP Dialog #1
NOTIFY
SIP Dialog #1
From: X
To: Y
Call-ID: Z
S-CSCF
18
19
Figure 6.7.1: Application Server S-CSCF subscribe notify dialog
12
X.P0013-003
16.8
S-CSCF handling IMS accounting
2In registration processing, a S-CSCF may send a third party REGISTER to an application server, where the
3ICID, IOI and charging function addresses are included in the message.
4During a session, the S-CSCF shall generate the accounting records for accounting purposes.
5In a session originating case, when receiving an incoming initial request, this request will carry the ICID
6generated by the upstream P-CSCF, which is serving the originating user; the S-CSCF shall store the ICID
7for this session and handle this request based on filter criteria. After processing this request the S-CSCF
8shall include the ICID and the accounting function addresses received from the HSS in the outgoing
9message. The accounting function addresses identify on-line, and off-line charging entities in the home
10network. It is implementation dependent how IMS related entities such as P-CSCF in the visited network
11get the local AAA addresses in the case that the P-CSCF is located in the visited network. If this message is
12sent outside the mobile network, S-CSCF shall include Inter Operator Identifier (IOI) that identifies the home network
13into the message. IOI is globally unique identifier for using inter operator accounting purposes. The response to the
14outgoing message may contain a separate IOI that identifies the home network of the called party. The S-CSCF shall
15retain either IOI in the message when contacting the Application Servers. The S-CSCF will receive ICN
16accounting information from subsequent requests and responses, the S-CSCF shall store these parameters
17and shall remove them from the outgoing message if this message is sent to the terminating UE's home
18network or the originating UE's visited network. The ICN accounting information may be sent to
19application servers.
20In a session terminating case, when receiving an incoming initial request, this request will carry the ICID
21generated by the originating UE's P-CSCF; the S-CSCF shall store the ICID for this session and handle this
22request based on filter criteria. After processing this request the S-CSCF shall include the ICID and the
23accounting function addresses received from the HSS in the outgoing message. The accounting function
24addresses identify on-line and off-line accounting entities in the home network. IOI may be received from
25another network or is inserted by the MGCF to identify the originating PSTN/PLMN. If IOI is received at the
26S-CSCF, the S-CSCF shall store the IOI value for the network that sent the request. The response to the incoming
27message may contain a separate IOI that identifies the home network of the S-CSCF. The S-CSCF shall retain either
28IOI in the message when contacting the Application Servers. Afterwards, the S-CSCF shall remove the IOI of the
29requesting network from the message before sending the message further within the network. The S-CSCF will
30receive ICN accounting information from subsequent requests and responses, the S-CSCF shall store these
31parameters and removes them from the outgoing message if this message is sent to the terminating UE's
32visited network or the originating UE's home network. The ICN accounting information may be sent to
33application servers.
34For detailed information on transporting accounting parameters between IMS entities using SIP, see [5].
356.9
Description of subscriber data
366.9.1 Application Server subscription information

37The Application Server Subscription Information is the set of all Filter Criteria that are stored within the
38HSS for service profile for a specific user. This information shall be sent by the HSS to the S-CSCF via the
39Cx Interface during registration. More than one set of Filter Criteria may be sent during registration if
40implicitly registered public user identities belong to different service profiles. Filter Criteria shall also be
41sent after registration via the Cx interface when requested, as specified in [8].
426.9.2 Filter Criteria
43This clause defines the contents of the Filter Criteria. This information is part of the Application Server
44Subscription Information. For further information about the XML modelling see [8].
45Filtering is done for initial SIP request messages only.
46The S-CSCF shall apply filter criteria to determine the need to forward SIP requests to Application Servers.
47These filter criteria will be downloaded from the HSS.
48Initial Filter Criteria (iFC) are stored in the HSS as part of the user profile and are downloaded to the S49CSCF upon user registration, or upon a terminating initial request for an unregistered user if unavailable.
50They represent a provisioned subscription of a user to an application. After downloading the User Profile
51from the HSS, the S-CSCF assesses the filter criteria. Initial Filter Criteria are valid throughout the
52registration lifetime of a user or until the User Profile is changed.
13
1X.P0013-003
1Subsequent Filter Criteria (sFC) are not used in this version of this specification.
26.9.2.1 Application Server address
3Address to be used to access the Application Server for a particular subscriber.
46.9.2.2 Default handling
5The default handling procedure indicates whether to abandon matching of lower priority triggers and to
6release the dialogue, or to continue the dialogue and trigger matching.
7Use of the default handling procedure by the AS is not supported in this version of this specification.
86.9.2.3 Trigger point
9Trigger Points are the information the S-CSCF receives from the HSS that defines the relevant SPTs for a
10particular application. They define the subset of initial SIP requests received by the S-CSCF that should be
11sent or proxied to a particular application server. When the S-CSCF receives an initial SIP request, it
12evaluates the filter criteria one by one. If the initial SIP request matches the filter criteria, the S-CSCF
13proxies the SIP request to the corresponding SIP AS/OSA SCS.
146.9.2.4 iFC Priority
15If there are multiple initial Filter Criteria assigned for one subscriber, the priority shall describe the order in
16which the S-CSCF shall assess them, and then contact the Application Servers when the SIP request
17matches the initial filter criteria. In this case, the S-CSCF shall interact with the application server
18associated with the initial matching filter criteria, starting from the filter criteria which has the highest
19priority.
206.9.2.5 Service Information
21Service Information is transparent information, and is not processed by the HSS or the S-CSCF. Service
22Information is optionally part of an initial Filter Criteria. If it is available from the initial Filter Criteria the
23S-CSCF shall include it into the body of the SIP request which is sent from the S-CSCF to the AS to which
24the initial Filter Criteria is pointing to. Service Information is only included by the S-CSCF in REGISTER
25requests where the S-CSCF acts as a UAC.
26
276.9.3 Authentication data
28This clause defines the Authentication Data. This data shall be sent by the HSS to the S-CSCF via the Cx
29Interface during registration.
30For the handling of authentication data, see [11].
317
Functional requirements of HSS
327.1
Subscriber data related storage requirements for HSS
33HSS stores information required by:

34 - S-CSCFs (downloaded via Cx interface). Data model and abstract syntax notation are described in
35
[8];
36
37
Application Servers (downloaded via Sh interface). Signalling flow and message contents are
described in [18].
38The service related data shall be transparent to HSS, this requires the HSS has some means to differentiate
39the source of the request for the data, therefore, the HSS can respond with the data the request asks for.
14
X.P0013-003
17.2
Interfaces defined for HSS
27.2.1 HSS CSCF (Cx) interface

3This interface is used to send subscriber data to the S-CSCF, including Filter Criteria (and their priority);
4which indicates which SIP requests should be proxied to which Application Servers.
5The protocol used between the HSS and CSCF (Cx Interface) is specified in [8] and [17].
67.2.2 HSS - Application Server (Sh) interface
7The Sh interface is between the HSS and the SIP Application Servers and the OSA SCS and may be used
8for transferring User Profile information such as user service related information or user location
9information, or charging function addresses. Requirements for the Sh interface are specified in [3].
10The protocol used between the HSS and AS (Sh Interface) is specified in [18] and [19].
117.2.3
Void
127.2.4
Void
137.3
Procedures during IP multimedia registration
14These procedures are described in [8].
157.4
Procedures during IP multimedia sessions
16These procedures are described in [8].
178
Functional requirements of the MRFC
188.1
Functionality of the MRFC
198.1.1 Overview of MRFC Functionality

20The functionality of the MRFC is defined in [3]. These clauses describe how an Application Server may
21interact with a MRFC. In some cases a UE may interact directly with the MRFC, however these cases are
22outside the scope of this specification and only the cases of Application Server control for service provision
23are considered here. In all cases of Application Server control, all session control requests that are passed
24between the Application Server and the MRFC are sent via the S-CSCF using the ISC interface and the
25interface of the Mr reference point.
26MRFC addresses are made known via peer-to-peer arrangements within the IM CN subsystem.
27Figure 8.1.1.1 describes the relationship of the Application Server with the S-CSCF and MRFC.
15
1X.P0013-003
AS
ISC
Mr
S-CSCF
MRFC
Mp
MRFP
1
2
Figure 8.1.1.1: Relationship of MRFC and MRFP with S-CSCF, and Application Servers
38.1.2 Tones and announcements

4An Application Server is in control of the tone/announcement selection and is aware of MRFC capabilities.
5The MRFC accepts INVITE requests sent from an Application Server, via the S-CSCF, for the purpose of
6applying tones and announcements. The INVITE sent to the MRFC will contain sufficient information to
7play the appropriate tone or announcement.
8The MRFC shall support both the offer/answer as defined in IETF RFC 3264 [15] and the offer/answer
9with preconditions models for SDP negotiation with the AS. However, the offer/answer model for SDP
10negotiation between the AS/S-CSCF and the MRFC is sufficient for applying tones and announcements.
11The MRFC should always grant the requests from the AS (unless there is a resource problem). The receipt
12of the ACK at the MRFC triggers the playing of the tone or announcement.
13The tone or announcement should end when a BYE is received. Alternatively, an expiration time may have
14been specified from the AS within the SDP of the INVITE request. In this case, the MRFC may terminate
15the media on its own and generate and BYE request towards the AS. A tone or announcement may also
16have a pre-determined play time (e.g., confirmation tone), and so there may not be a need for the AS to
17send a request to stop it or to include the play time in the request.
18See annex B for a call flow example of playing an announcement for a mobile originated call.
198.1.3 Ad hoc conferences (multiparty calls)
20An Application Server can control an Ad Hoc conference (multiparty call) and is aware of MRFC
21capabilities.
23managing ad hoc conferences. The INVITE sent to the MRFC shall contain sufficient information to
24initiate, add and remove parties from the conference. Re-INVITE requests can also be sent for managing
25floor control and for parties to leave and rejoin the media path.
27with preconditions models for SDP negotiation with the AS. However, the offer/answer model for SDP
28negotiation between the AS/S-CSCF and the MRFC is sufficient for managing ad hoc conferences. The
29MRFC should always grant the requests from the AS (unless there is a resource problem). The MRFC will
30reserve the requested local resources and return the appropriate resource identifiers in the 200 response.
31See annex B for a call flow example of an Ad Hoc Conference (Multiparty Call).
328.1.4 Transcoding
33An Application Server can control a transcoding session and is aware of MRFC capabilities.
16
X.P0013-003
2transcoding. The INVITE sent to the MRFC shall contain sufficient information to associate the two
3sessions that require transcoding.
5with preconditions models for SDP negotiation with the AS. Either may be necessary for SDP negotiation
6between the AS/S-CSCF and the MRFC. The MRFC should always grant the requests from the AS (unless
7there is a resource problem).
8For the offer/answer model, the MRFC responds to the INVITE request with a 200 response indicating the
9selected media in the SDP. The MRFC will also reserve the requested local resources at that time and return
10the appropriate resource identifiers in the 200 response.
11For the offer/answer with preconditions model, the MRFC responds to the INVITE request with a 183
12response indicating the list of codecs supported by the MRFC. When the PRACK is received indicating the
13selected media in the SDP, the MRFC will reserve the requested local resources at that time and return the
14appropriate resource identifiers in the 200 response.
15See annex B for call flow examples of providing transcoding.
168.2
Interfaces defined for MRFC
178.2.1 MRFC S-CSCF (Mr) interface

18The protocol used between MRFC and S-CSCF is based on Session Initiation Protocol, which is specified
19in [5].
17
1X.P0013-003
19
Generic IP multimedia session handling for SIP Application
2Servers
39.1
Architecture
4This clause describes the functional architecture needed to support interactions between the S-CSCF in the
5IP Multimedia Subsystem and the Application Server(s). This clause relates to the generic behaviour of SIP
6Application Servers, which since SIP is the ISC interface protocol shall be considered to apply to all
7application servers, (which also includes the SIP behaviour of the OSA SCS). The detailed models for
8service provision are described in the clauses below. These models shall apply to the SIP behaviour of the
9OSA SCS and all the Application Servers.
10
Application Server
HSS
Sh
Application Logic
AS-ILCM
AS-OLCM
ISC
S-CSCF
11
12
Figure 9.1.1: Application Server functional model
13Figure 9.1.1 identifies the components of a functional model of the AS.

14 NOTE: These components are defined only as a model of the expected behaviour of the AS on the
15
ISC interface and are not intended to define or constrain the actual implementation.
16The components include the AS-ILCM, the AS-OLCM and the Application Logic. The AS-ILCM shall
17store transaction state, and may optionally store session state depending on the specific service being
18executed. The AS-ILCM interfaces to the S-CSCF (ILCM) for an incoming leg.
19The AS-OLCM shall store transaction state, and may optionally store session state depending on the
20specific service being executed. The AS-OLCM interfaces to the S-CSCF (OLCM) for an outgoing leg.
21The Application Logic provides the service(s) and interacts between the AS-ILCM and AS-OLCM.
22The Application Server can access the HSS via the Sh interface to access subscriber related data specific to
23the service or application including the address of the S-CSCF.
18
X.P0013-003
19.1.1 Modes of operation between Application Server and S-CSCF

2An Application Server can utilize five basic modes of operation for processing SIP Requests. Services can
3be built using combinations of these five modes of operation between the Application Server and the S4CSCF. An application Server can transition from one mode of operation to another during the lifetime of a
5multimedia session it is managing.
69.1.1.1 Application Server acting as terminating UA, or redirect server
Application
Server
From: X
To: Y
Call-ID: Z
SIP dialog #1
7
8
SIP dialog
#1
S-CSCF
From: X
To: Y
Call-ID: Z
Figure 9.1.1.1.1: Application Server acting as terminating UA, or redirect server
9In this mode of operation the incoming SIP Request is proxied by the S-CSCF to the Application Server,
10which then acts as either a UA or Redirect Server as specified in IETF RFC 3261 [6].
119.1.1.2 Application Server acting as originating UA
Application
Server
From: X
SIP dialog To: Y

#1
Call-ID: Z
S-CSCF
From: X
To: Y
Call-ID: Z
12
13
SIP dialog #1
Figure 9.1.1.2.1: Application Server acting as originating UA
14In this mode of operation the Application Server acts as a UA as specified in IETF RFC 3261 [6] and
15generates a SIP Request which it sends to the S-CSCF which then proxies it towards the destination.
19
1X.P0013-003
19.1.1.3 Application Server acting as a SIP proxy
Application
Server
SIP dialog From: X

To: Y
#1
SIP dialog
From: X
#1
Call-ID: Z
To: Y
Call-ID: Z
S-CSCF
SIP dialog #1
2
3
From: X
To: Y
Call-ID: Z
SIP dialog #1
From: X
To: Y
Call-ID: Z
Figure 9.1.1.3.1: Application Server acting as a SIP proxy
4In this mode of operation the incoming SIP Request is proxied by the S-CSCF to the Application Server
5which then acts as a proxy as specified in IETF RFC 3261 [6] proxying the request back to the S-CSCF
6which then proxies it towards the destination. During the proxy operation the Application Server can add,
7remove or modify the header contents contained in the SIP request according to the Proxy rules specified in
8IETF RFC 3261 [6].
99.1.1.4 Application Server performing third party call control/ B2BUA mode
10
Application
Server
From: P
SIP dialog To: Q

#2
Call-ID: R
SIP dialog
From: X
#1
To: Y
Call-ID: Z
SIP dialog #1
11
12
S-CSCF
From: X
To: Y
Call-ID: Z
SIP dialog #2
From: P
To: Q
Call-ID: R
Figure 9.1.1.4.1: Application Server performing third party call control
13In this mode of operation the incoming SIP Request is proxied by the S-CSCF to the Application Server
14which then generates a new SIP request for a different SIP dialog which it sends to the S-CSCF which then
15proxies it towards the destination. In this mode the Application Server behaves as a B2BUA for the
16multiple SIP dialogs as specified in IETF RFC 3261 [6].
20
X.P0013-003
19.1.1.5 Application Server not involved or no longer involved
SIP dialog #1
From: X
To: Y
Call-ID: Z
2
3
4
S-CSCF
SIP dialog #1
From: X
To: Y
Call-ID: Z
Figure 9.1.1.5.1: A SIP leg is passed through the S-CSCF without Application Server
involvement
5In this mode of operation the Application Server was either never involved in the SIP session signalling or
6has determined to be no longer involved. The incoming SIP Request is proxied by the S-CSCF towards the
7destination. The Application Server can maintain itself in the SIP session signalling path by inserting itself
8in a Record-Route Header as specified in IETF RFC 3261 [6]. If the Application Server does not insert
9itself in a Record Route header then this mode of operation shall be used for all subsequent requests related
10to this SIP dialog.
119.2
Interfaces defined for a SIP Application Server
129.2.1 S-CSCF Application Server (ISC) interface

13This interface can be used by the Application Server to control an IP Multimedia session via a S-CSCF.
14Transactions between the S-CSCF and the Application Server on this interface are initiated either as a result
15of the S-CSCF proxying a SIP request to the Application Server or by the Application Server initiating by
16generating and sending a SIP request to the S-CSCF. This interface is based on SIP.
179.2.2 Application Server HSS (Sh) interface
18The Sh interface is between the HSS and the SIP Application Servers and the OSA SCS and may be used
19for transferring User Profile information.
209.3
Description of Application Server related subscriber data
219.3.1 Application server subscription information

22This clause defines the general contents of the Subscription Information that may be required by the
23Application Server. The AS shall obtain this information from the HSS via the Sh interface or by other
24operator defined methods. The subscription information may be retrieved during registration or at any other
25time dependent on AS and service requirements.
269.3.1.1 Void
279.3.1.2 Service platform trigger points (STP)
28Service Platform Trigger Points (STP) are the points in the SIP signalling that instruct the Application
29Server to trigger the service logic.
309.3.1.3 Service scripts
31The Application Server can utilize a call processing script (e.g. in CGI, CPL, Java Servlets, or another
32proprietary language), which may be obtained from the HSS via the Sh interface or by other operator
33defined methods.
21
1X.P0013-003
1
2
3
4
NOTE:
Java is the trade name of a product supplied by Sun Microsystems. This information is
given for the convenience of users of the present document and does not constitute an
endorsement by 3GPP2 of the product named. Equivalent products may be used if they can
be shown to lead to the same results.
59.4
Procedures for multimedia session handling with a SIP based
6Application Server
79.4.1 Application Server handling of mobile originating requests
8The functional mode of application server is shown in figure 9.1.1.
9For an originating request, the AS-ILCM may interact with the application logic reporting call state
10information. Depending on the service that is being provided, the application logic may instruct the AS11OLCM to modify the request if needed (e g. by inserting itself in the Record-Route etc). After processing
12the request the AS-OLCM may send this request back to the S-CSCF.
13When the AS acts as a B2BUA, the application server shall maintain and correlate the multiple dialogues
14that it creates. It shall be responsible for correlating the dialogue identifiers and shall decide when to
15translate a message from one dialog to the other, or when to perform other functions based on the
16instruction from the application logic.
179.4.2 Application Server handling of mobile terminating requests
18The handling of mobile terminating requests is similar with the handling of mobile originating requests as
19defined in clause 9.4.1.
209.4.3 Application Server handling of SIP registration
21When the user is registered with the network and has been assigned a S-CSCF, the application servers,
22which are interested to know about the user registration events, should get a third party registration request
23generated by the S-CSCF. When the application server receives the request, the AS may perform a service
24triggered by a REGISTER. If the application server doesn't support this mechanism, it shall send back an
25error response to the S-CSCF. If the application server supports this mechanism, it shall treat this request as
26a notification from the network about the user's registration event and extract the important information
27from this request.
28The application server will also expect to receive REGISTER requests indicating re-registration or
29deregistration events from the S-CSCF, so that the application server can update or release user's
30registration information.
31The important information carried in the third party registration request are, the public user identity, the S32CSCF address, and the expiration time.
33
34Application Servers can also subscribe to the S-CSCF Registration Event Package after receiving the third
35party registration request. After subscribing to the event package with the S-CSCF, the application will
36expect to receive the notifications from the S-CSCF, which may carry the user's implicitly registered public
37user identities and user's registration event information.
38The application server can also obtain the user's implicitly registered public identities by accessing the HSS
39via Sh interface.
40An application server will require knowledge of a user's IMS subscription information if they are to
41correctly apply services. This information can be provided to the application server in two ways, either:
42 a) Manually by provisioning. This is outside of the scope of this specification.
43 b) Automatically from the HSS via the Sh interface.
44More information on these procedures is contained in [5].
22
X.P0013-003
19.4.4
Application Server handling of IP multimedia session release requests
29.4.4.1 Session release request terminated at the Application Server

3When the application server receives a session release request, if the application server is acting as a user
4agent or a B2BUA, it shall send 200 OK to the entity that initiated the session release request.
Application Server
SIP BYE
SIP 200 OK
AS-ILCM
AS-Logic
AS-OLCM
5
6
Figure 9.4.4.1.1: Release request terminated at the Application Server
79.4.4.2 Session release request proxied by the Application Server

8When receiving a session release request, the application server may proxy the release request based on the
9route information in that request. This handling is typically used when the application server is in proxy
10mode.
From: A
To: B
Call-ID:Y
Cseq:Z
SIP BYE
Application Server
AS-ILCM
AS-Logic
SIP BYE
AS-OLCM
From: A
To: B
Call-ID:Y
Cseq:Z
11
12
Figure 9.4.4.2.1: Release request proxied by the Application Server
23
1X.P0013-003
19.4.4.3 Session release request initiated by the Application Server

2If needed, the application server may initiate release requests to the entities involved in the dialogs the
3application server manages. Application servers may initiate release requests in either user agent or B2BUA
4mode.
Application Server
AS-ILCM
AS-Logic
SIP BYE
5
6
SIP BYE
AS-OLCM
From: C
To: D
Call-ID:W
Cseq:X
From: A
To: B
Call-ID:Y
Cseq:Z
Figure 9.4.4.3.1: Release request initiated by the Application Server
79.4.5 Application server handling of IP multimedia accounting

8If an application server receives a third party REGISTER from the S-CSCF carrying the ICID, IOI and
9accounting function addresses, the application server may store these parameters for accounting purposes.
10In an originating case, when processing an incoming initial request carrying the ICID, IOI, ICN accounting
11information and accounting function addresses for this session, the application server shall pass these
12parameters in the outgoing message and may store the parameters for accounting purposes.
13In a terminating case, when processing an incoming initial request carrying the ICID, IOI, ICN accounting
14information and accounting function addresses for this session, the application server shall pass these
15parameters in the outgoing message and may store the parameters for accounting purposes.
16When the application server is acting as an originating user agent as described in clause 9.1.1.2 and initiates
17a session or a standalone transaction, it shall generate ICID itself. The application server may retrieve the
18charging addresses on Sh interface.
19When the conflict occurs between the charging function address(es) received over the ISC interface and
20those received over the Sh interface, the address(es) received over the ISC interface should take
21precedence.
22 NOTE: The use of the Sh interface to retrieve charging function addresses is not intended as a
23
general-purpose alternative to receiving charging function addresses from the ISC interfaces.
24
Rather, it is meant to address a special case where the AS needs to interact with the charging
25
system before initiating a request to a user when the AS has not received the third party
26
REGISTER for that user.
27For detailed information on transporting accounting parameters between IMS entities using SIP, see [5].
2810
Void
29
3011
IP multimedia session handling with an OSA-Service
31Capability Server
32This clause describes the functional architecture needed to support interactions with the S-CSCF in the IP
33Multimedia Subsystem and the OSA-SCS. The OSA-Service Capability Server is a SIP Application Server
24
X.P0013-003
1which interfaces SIP to the OSA framework. The generic SIP Application Server behaviour of the OSA2SCS is specified in clause 9 of the present document.
3The detailed OSA-SCS procedures for IMS Application Server are specified in [7].
412.
IP multimedia session handling with an Charging Server
5This clause describes the functional architecture needed to support interactions with the S-CSCF in the IP
6Multimedia Subsystem and Charging Server. The Charging Server is a specific SIP Application Server that
7performs the role of online charging mechanism for the Event Charging Function (ECF) and Session
8Charging Function (SCF).
9The detailed procedures for Charging Server are specified in [20] and [21].
25
1X.P0013-003
1Annex A (informative):
2Scalability and deployment considerations
3multimedia service provision
for IP
4This Annex is intended to guide the reader in deployment and real life issues.
5This specification has provided a set of tools for the application developer and the application integrator to
6utilize in order to develop and deploy applications and provide services for the IP multimedia core network
7subsystem. However, practical deployments will need to consider certain scalability issues with the use or
8misuse of some of the tools specified in this specification.
9The architecture allows for any number of Application Servers to be connected to any number of S-CSCFs
10and any number of Application Servers to be involved in the initiation of a multimedia session. A
11scalability issue may arise if there are a large number of S-CSCF and AS in a network.
12Consideration should be given to the signalling propagation delays introduced when many Application
13Servers add themselves to the route to provide originating and terminating services for the calling and
14called parties.
15A SIP Application Server may act as gateway function by forwarding an incoming request to external ASs
16beyond the IM CN subsystem. An external ASs will also send responses to IM CN subsystem via a SIP AS
17gateway. These other Application Servers can be located externally to the home network, and use the SIP
18Application Server as a gateway to the ISC interface. The interface between the SIP Application Server
19acting as a gateway, and other Application Servers is outside the scope of the present document.
20There is another case where the external AS is connected with S-CSCF (or I-CSCF) via public ISP
21networks depending on the operators desire for network configuration hiding. S-CSCF or entities outside
22the S-CSCF may perform the interworking function.
23Care must also be taken to the priority and order of contact of multiple Application Servers during a session
24in order to account for feature interaction issues.
Sh
HSS
Cx
Other AS 6
ISC
S-CSCF 1
Other AS 5
ISC
S-CSCF 2
SIP AS 1
Other AS 4
ISC
S-CSCF 3
SIP AS 2
ISC
Not specified
25
26
Figure A.1: Example hierarchical architecture for Application Servers
27Figure A.1 depicts a possible solution that shows how a S-CSCF (S-CSCF1 S-CSCF3) could be connected
28to a single AS (SIP AS1), while another (S-CSCF2) could be connected to more than one, in this case it is
29two (SIP AS1, SIP AS2). All S-CSCF will be connected to the HSS via Cx. A SIP AS may be connected to
26
X.P0013-003
1the HSS via Sh. SIP ASs may be connected to the IP network, which could allow them to contact
2Application Servers (e.g., either SIP ASs, or Other ASs).
3Care should be taken to the transaction delays resulting of a high number of S-CSCF and ASs on the
4session signalling path.
5A possible application of this architecture is described below (see figure A.2).
6While some applications need to discover the registration of a user on an event driven basis, many
7applications do not. For many applications an access to the HSS or other database to obtain the address of
8the S-CSCF that serves a user is sufficient to contact and initiate a session to that user, and others (such as
9basic call feature servers) do not require to be informed of the registration state or necessarily even need to
10know the identity of the user. It is therefore possible that the filter criteria are set in such a way that S11CSCF3 does not forward or notify SIP AS 3 of REGISTER requests. SIP AS3 would then need to
12determine registration status via other means (i.e. via IP network) not specified.
13The number of Application Servers receiving REGISTER requests (i.e., SIP AS3) from an individual S14CSCF should be minimized.
Sh
HSS
Cx
Other AS 6
ISC
S-CSCF 1
Other AS 5
ISC
S-CSCF 2
SIP AS 1
Other AS 4
ISC
S-CSCF 3
SIP AS 2
ISC
Not specified
ISC
SIP AS 3
15
16
Figure A.2: Use of a hierarchy in a practical architecture for Application Servers
27
1X.P0013-003
1Annex B (informative):
2Information flows for example
services
3This annex contains some informative example information flows that show the possible flow of
4information for some example services. These examples are intended only to help aid the understanding of
5the behaviour of the S-CSCF, MRFC and Application Servers for service provision for the IM CN
6subsystem and are not intended to recommend or specify how to create such services, (indeed the examples
7given may not even be a good idea for a practical implementation).
8The following modes of operation are shown in these examples:
9 - Third Party Registration to Application Server
Clause B.3.2;
10
Application Server in Originating UA mode
Clause B.3.2;
11
Application Server in Redirect mode
Clause B.1.3;
12
Application Server in Terminating UA mode
Clause B.3.1;
13
Application Server in Proxy mode
Clause B.1.4;
14
Application Server in Third Party Call Control/B2BUA mode
Clauses B.2.1, B.2.2, and B.2.3;
15
Application Server with no involvement
Clause B.1.4.
16
17B.1
Call forwarding example
18B.1.1 Call forwarding through Application Servers

19Figure B.1.1.1 presents the network configuration for a call-forwarding scenario. Some interfaces between
20nodes have been omitted purely for clarity. In this configuration, the UE1 originates a call to the UE2. The
21UE2 is subscribed to a Call Forwarding (CF) service based on the Calling Line Identification (CLI). The
22CF service logic resides in an Application Server interfacing to the IM CN subsystem via the ISC interface.
23The Application Server is programmed to detect all incoming calls or terminating sessions with UE1's CLI
24and to instruct the S-CSCF to forward the calls/sessions to another destination, UE3, either directly or via
25the UE1. These two session forwarding scenarios are shown by the red and blue coloured flows. When the
26session redirection is carried out directly by the S-CSCF of the UE2, the network may notify the UE1 of its
27call/session redirection.
28As shown in figure B.1.1.1, the Application Server may be a SIP AS, or an OSA AS. The latter Application
29Server interfaces the S-CSCF via the OSA SCS gateway.
28
X.P0013-003
OSA AS
SIP AS
OSA API
OSA SCS
ISC
S-CSCF
Application Servers
HSS
Application Servers
HSS
HSS
I-CSCF
Home Network
UE2
S-CSCF
I-CSCF
Home Network
S-CSCF
UE3
Home Network
UE1
UE3
UE1
2
3
Figure B.1.1.1: Network configuration for the call forwarding examples
4In this configuration, the originating UE1 and the terminating UE3 are assumed to be in their respective
5home network. The UE2, not shown in figure B.1.1.1, may be either at its home network or roaming in a
6visited network.
7The CF feature is invoked based on the detection of the originating party's CLI "pre-activated" for call
8forwarding. Upon invocation of the CFonCLI feature, the call will be forwarded to a pre-specified
9destination. These two steps and a few underlying assumptions are briefly described below:
10B.1.1.1 Service activation and programming
11The UE2 activates its CFonCLI service and programs it with a Forward-to Number which is UE3's number,
12conditioning it to the originating party's line identity, CLI.
13B.1.1.2 Service invocation and control
14The UE1 makes a call to the UE2. The CFonCLI is invoked and the call is forwarded to the
15UE3 following a "Session Redirection" that is initiated by either the S-CSCF or the UE1.
16 NOTE:
[3] lists six redirection procedures as follows:
17
NOTE 1: Session Redirection initiated by S-CSCF to IMS;
18
NOTE 2: Session Redirection initiated by S-CSCF to CS-domain;
19
NOTE 3: Session Redirection initiated by S-CSCF to general endpoint;
20
NOTE 4: Session Redirection initiated by P-CSCF;
21
NOTE 5: Session Redirection initiated by UE;
29
1X.P0013-003
NOTE 6: Session Redirection initiated after Bearer Establishment.
2B.1.2 Assumptions
3For the CFonCLI service invocation and service control procedure, the following are assumed to hold:
4 - Normal case scenario, showing successful cases only;
5
Subscriber data of all three UE1, UE2 and UE3 are stored in their respective HSS;
6
7
All call/session control for the UE1, UE2, and UE3 is done in their respective home network SCSCF;
8
9
The UE2 has already subscribed to the CFonCLI service with a service provider operating an
Application Server where the service control logic resides;
10
11
The pre-selected numbers (e.g., UE3) to which the originated calls are forwarded, are stored by the
CFonCLI service control logic upon activation of the feature by the UE2.
12B.1.3
UE redirect based call flows
13
Terminating UE3
Home Network
Terminating UE2
Home Network
Service
Platform
S-CSCF
Originating UE1
Home Network
HSS
I-CSCF
3. Locate UE2
6. INVITE
S-CSCF
2. INVITE
4. Response
5. INVITE
. 1. INVITE
UE1
Application performs
number translation
(based on CLI)
Redirect
7. 302 Moved Temporarily

8. ACK
Mode 9. 302 Moved Temporarily
11. ACK
12. ACK
14. ACK
15. INVITE
16. INVITE
17. Bearer Establishment & Call Setup
14
15
Figure B.1.3.1: CFonCLI information flows with UE re-direct
16Figure B.1.3.1 presents the information flow diagram for the invocation and control of the CFonCLI
17service based on the configuration of figure B.1.1.1.
30
X.P0013-003
1The UE1 initiates a call to UE2. The CFonCLI service logic is invoked in the Application Server when the
2S-CSCF for UE2 detects that service invocation is required. The call is forwarded to the UE3 by the UE1
3according to the "Session Redirection initiated by UE" procedure. The UE3 accepts the (forwarded) call. A
4detailed description for each flow is given below:
5
1) The S-CSCF of UE1 receives a SIP invite request form UE1.
6
7
2) The I-CSCF of the UE2 receives a SIP INVITE request form the S-CSCF of the originating user,
UE1. UE1's CLI is included in this INVITE request.
3) The I-CSCF of the UE2 queries the HSS to obtain the S-CSCF of the UE2.
4) The HSS returns the S-CSCF location.
10
5) The I-CSCF forwards the INVITE to the S-CSCF of UE2.
11
12
13
14
6) Based on the information obtained from the UE2 Service Profile (during registration), the SCSCF of the UE2 detects that the criteria for certain pre-defined triggers are met. The INVITE
request is forwarded to the Application Server. The service logic is invoked in the Application
Server.
15
16
17
18
7) Based on the outcome of the execution of the service logic, the Application Server instructs the SCSCF to REDIRECT the session to UE3. The behaviour of the Application Server follows the
description of a 'redirect server'. It sends the 302 Move Temporary response with UE3 as the redirect
address to UE1. The Application Server plays no further part in the session establishment.
19
20
8) S-CSCF of UE2 sends ACK back to the Application Server to acknowledge the receiving of the
302 response.
21
9) S-CSCF of UE2 forwards the 302 Move Temporary to the I-CSCF of UE2.
22
10) The I-CSCF of UE2 forwards the 302 Move Temporary to the S-CSCF of UE1.
23
11) The S-CSCF of UE1 sends ACK to acknowledge the receiving of the 302 Move Temporary.
24
12) The I-CSCF of UE2 forwards the ACK to the S-CSCF of UE2.
25
13) The S-CSCF of UE1 forwards the 302 Move Temporary response to the next downstream hop.
26
14) The S-CSCF of UE1 receives the ACK for that 302 response from the downstream hop.
27
15) The UE1 re-issues an INVITE with UE3 as the destination.
28
16) The originating S-CSCF redirects the SIP INVITE request to the UE3's home network.
29
30
31
17) Bearer establishment & call setup between from the UE1 to the UE3 is performed following the
procedure described in the basic call flow sections for originating, inter-network and terminating
segments.
32B.1.4 S-CSCF based redirect call flows

33Figure B.1.4.1 presents the information flow diagram for the invocation and control of the CFonCLI
34service based on the configuration of figure B.1.1.1, where redirection is made by the S-CSCF after
35instructions from the service logic in the Application Servers.
31
1X.P0013-003
Terminating UE3
Home Network
S-CSCF
Terminating UE2
Home Network
HSS
I-CSCF
Service
Platform
S-CSCF
6. INVITE
Application performs
number translation
(based on CLI)
Originating UE1
Home Network
HSS
S-CSCF
1. INVITE UE1
2. INVITE
I-CSCF
3. Locate UE2
4. Response
5. INVITE
7a. 181 Call Is Being Forwarded

7b. 181 Call Is Being Forwarded
7c. 181 Call Is Being Forwarded
8 INVITE
7d. 181 Call Is Being Forwarded
Proxy Mode
10. Locate UE3
9. INVITE
11. S-CSCF UE3
UE3
12a. INVITE
12b. INVITE
No AS involvement
13a. 183 Session Progress)

13b. 183 Session Progress
13c. 183 Session Progress
13d. 183 Session Progress
13e. 183 Session Progress
13f. 183 Session Progress
13g. 183 Session Progress
13h. 183 Session Progress
14. Bearer Establishment & Call Setup
1
2
Figure B.1. 4.1: CFonCLI information flow with S-CSCF redirect
3The UE1 (located in the originating visited network) makes a call to UE2. The CFonCLI is invoked and the
4CFonCLI service logic is executed by an application residing in the Application Server.
5The call is forwarded to the UE3 by the S-CSCF of UE2 according to the "Session Redirection" instructed
6by the Application Server. The S-CSCF sends a SIP 181Call Is Being Forwarded to UE1 and a SIP Invite
7request to UE3. The UE3 accepts the (forwarded) call. A detailed description for each flow is given below:
8
1) - 6) are identical to flows by the same number in the UE Redirect example provided in B.1.3.1
9
10
(7a, 7b, 7c and 7d) The Application Server notifies the UE1 that the call is being forwarded, by
sending a 181 Call Is Being Forwarded response.
11
12
8) The service logic forwards the INVITE request back to S-CSCF modifies the destination address
by inserting the identity of the UE3. The Application Server is in SIP proxy mode.
13
14
9) The S-CSCF of UE2 forwards the modified INVITE request it received from the Application
Server to the I-CSCF of UE3.
15
10) The I-CSCF of the UE3 queries the HSS to obtain the S-CSCF of the UE3.
16
11) The HSS returns UE3's S-CSCF location.
17
(12a and 12b) The I-CSCF forwards the SIP INVITE request the UE3 via its S-CSCF.
18
19
(13a, 13b, 13c, 13d, 13e, 13f, 13g, 13h and 13g) The UE3 accepts the incoming call and sends an
183 Session Progress back to UE1.
32
X.P0013-003
1
2
3
14) Bearer establishment & call setup between from the UE1 to the UE3 is performed following the
procedure described in the basic call flow clauses for originating, inter-network and terminating
segments.
4B.2 Announcement, conferencing and transcoding examples

5using MRFC
6B.2.1 Example information flow for a mobile originated IP multimedia session that
7results in playing an announcement
8The following diagram shows an example of playing an announcement for a mobile originated IP
9multimedia session. An AS (acting as B2BUA) performs third party call control with the MRFC, where the
10S-CSCF is in the signalling path.
11The "[x]" notation in the diagram is an indicator of a unique SIP dialog. The "dot" notation on the AS line
12indicates B2BUA actions are taking place along with AS service logic. The 100 Trying responses are not
13shown in the diagram, but it is assumed that 100 Trying is sent in response to each INVITE request.
14The B2BUA AS interacts with the UE as usual to establish the dialog. The B2BUA AS interacts with the
15MRFC using a third party control model to establish the dialog. The B2BUA AS manages the interactions
16between the two dialogs.
17The offer/answer model as defined in IETF RFC 3264 [15] is used for SDP negotiation between the AS/S18CSCF and the MRFC. The MRFC should always grant the requests from the AS (unless there is a resource
19problem). The MRFC responds to the INVITE request with a 200 response indicating the selected codec in
20the SDP. The MRFC will also reserve the requested local resources at that time. The selected codec is
21included by the B2BUA AS in the 183 response to the UE. The receipt of the ACK at the MRFC triggers
22the playing of the tone or announcement.
33
1X.P0013-003
Home Network for calling party
AS
S-CSCF
MRFC
1. INVITE (UE SDP) [1]

100 Trying is sent
after each INVITE,
but it isn't shown

3. Service Logic
5. Session Failure
6. Session Failure [2]
7. ACK [2]
8. Service Logic
9. INVITE (SDP-A) [3]
10. INVITE (SDP-A) [3]
12. 200 OK (SDP-A) [3]
11. 200 OK (SDP-A) [3]
13. 183 (SDP-A) [1]

14. 183 (SDP-A) [1]
15. PRACK (SDP-A) [1]
16. PRACK (SDP-A) [1]
17. 200 OK (SDP-A) [1]
18. 200 OK (SDP-A) [1]
19. QoS Establishment / Resource Reservation
20. UPDATE(SDP-A) [1]
21. UPDATE(SDP-A) [1]
22. 200 OK (SDP-A) [1]
23. 200 OK (SDP-A) [1]
24. 200 OK [1]
25. 200 OK [1]
26. ACK [3]
27. ACK [3]
29. ACK [1]
28. Play Announcement

30. ACK [1]
1
2
Figure B.2.1.1: Tones and announcements call flow
3Notes for figure B.2.1.1:

4
1) INVITE request is received at the S-CSCF [Call-ID 1].
5
2) INVITE request is forwarded to an AS, based on the filter criteria.
34
X.P0013-003
3) The AS service logic determines to proceed with the call.
2
3
4) New INVITE request is sent towards destination, via the S-CSCF, to establish a new dialog [CallID 2].
5) S-CSCF experiences a failure, such as not being able to determine the next hop for the SIP URI.
6) Session failure returned to the AS.
7) ACK returned to complete this dialog [Call-ID 2].
8) The AS service logic determines to play an announcement to the calling party.
8
9
10
9) New INVITE request is sent to the MRFC, via the S-CSCF, to establish a new dialog for playing
an announcement [Call-ID 3]. Sufficient information is included to specify the details for the
announcement.
11
10) S-CSCF relays INVITE to the MRFC.
12
13
11) The MRFC allocates the requested resource and returns 200 OK, with SDP-A indicating selected
media.
14
12) S-CSCF relays 200 OK to the AS.
15
16
17
13) - 30) The B2BUA AS manages the dialog for Call-ID 1 as normal, with the SDP-A supplied
from the MRFC. The MRFC is instructed to play the announcement using the ACK request at flow
26 for Call-ID 3.
18B.2.2 Example information flow for a mobile originated IP multimedia ad hoc

19conferencing session (multiparty call)
20The following diagram shows an example of an ad hoc conference (multiparty call). An AS (acting as
21B2BUA) performs third party call control with the MRFC, where the S-CSCF is in the signalling path.
25The Application Server is in control of the ad hoc conference, is aware of the MRFC capabilities and is also
26operating as a B2BUA performing third party call control.
27An INVITE request is generated from UE-1 indicating a desire to start a multiparty call (ad hoc conference)
28by taking the existing sessions, between UE-1 to UE-2 and UE-1 to UE-3, and bringing them together. The
29AS uses third party call control to request the conference facilities from the MRFC. A separate dialog is
30established from the AS to the MRFC for each of the three parties (UE-1, UE-2, UE-3). New dialogs are
31also established between the AS and each of the UE endpoints. The media from each UE is connected at the
32conferencing resource at the MRFP. The first INVITE request to the MRFC should receive a response that
33includes the conference identifier. The same conference identifier will be used for subsequent INVITE
34requests to add or drop parties to the conference.
35The offer/answer model as defined in IETF RFC 3264 [15] is used for SDP negotiation between the AS/S36CSCF and the MRFC. The MRFC should always grant the requests from the AS (unless there is a resource
37problem). The MRFC responds to the INVITE request with a 200 response indicating the selected media in
38the SDP. The MRFC will also reserve the requested local resources at that time and return the appropriate
39resource identifiers in the 200 response.
35
1X.P0013-003
AS
S-CSCF
MRFC
Sessions exist between UE-1 and UE-2, and between UE-1 and UE-3 .
Request is to put all parties together for an Ad-hoc conference (multi-party call).
1. INVITE (MPTY)[1]
2. 100 (Trying)
3. INVITE (MPTY)[1]
100 Trying is sent

after each INVITE,
but it isn't shown
4. Service Logic
5. INVITE (UE-2 SDP)[2]
8. 200 OK (UE-2 SDP)[2]
7. 200 OK (UE-2 SDP)[2]
13. 200 OK (UE-2 SDP)[3]

14. ACK (UE-2 SDP) [2]
16. ACK (UE-2 SDP) [3]
12. 200 OK (UE-2 SDP)[3]

15. ACK [2]
17. ACK [3]
21. 200 OK (UE-3 SDP)[4]
20. 200 OK (UE-3 SDP)[4]
26. 200 OK (UE-3 SDP)[5]

27. ACK (UE-3 SDP) [4]
11. Establish path

between UE-2
and MRFP
25. 200 OK (UE-3 SDP)[5]

28. ACK [4]
29. ACK [5]
30. ACK [5]
34. 200 OK (UE-1 SDP)[6]
33. 200 OK (UE-1 SDP)[6]
35. 200 OK (UE-1 SDP) [1]

36. 200 OK (UE-1 SDP) [1]
38. ACK [6]
37. Establish path

between UE-1
and MRFP
39. ACK [6]
40. ACK [1]

41. ACK [1]
1
2
Figure B.2.2.1: Ad hoc conference call flow

4
1) INVITE request received at S-CSCF from UE-1 indicating desire to start ad hoc conference
5
(multiparty call) for the existing sessions between UE-1 to UE-2 and UE-1 to UE-3.
6
2) 100 Trying returned.
3) INVITE forwarded to AS.
36
24. Establish path

between UE-3
and MRFP
X.P0013-003
4) AS performs service logic and allows attempt to start ad hoc conference.
2
3
5-8) New INVITE request sent to MRFC to initiate multiparty call, get conference identifier and
prepare dialog for UE-2 [Call-ID 2].
9-13) Re-INVITE sent to UE-2 to establish dialog between AS and UE-2 [Call-ID 3].
14-17) ACK sent for Call-ID 2 and Call-ID 3.
6
7
18-21) New INVITE request sent to MRFC using the same conference identifier and prepare dialog
for UE-3 [Call-ID 4].
22-26) Re-INVITE sent to UE-3 to establish dialog between AS and UE-3 [Call-ID 5].
10
11
31-34) New INVITE request sent to MRFC using the same conference identifier and prepare dialog
for UE-1 [Call-ID 6].
12
35-36) 200 OK returned to UE-1 with SDP.
13
37) The session is established.
14
15B.2.3 Example information flows for a mobile originated IP multimedia session that
16requires transcoding
17The two figures B.2.3.1 and B.2.3.2 that follow illustrate the MRFC providing transcoding for a mobile
18originated session, where the MRFC is receiving directions from the AS operating as a B2BUA.
22The B2BUA AS interacts with the originating UE as usual to establish the dialog. The B2BUA AS interacts
23with the MRFC using a third party control model to establish the dialog with the called party after receiving
24the initial failure indication. The B2BUA AS manages the interactions between the two dialogs.
25An INVITE request is generated from a UE. A 606 "Not Acceptable" response is received from the called
26party. The AS uses third party call control to request transcoding facilities from the MRFC. A separate
27dialog is established from the AS to the MRFC for each of the two parties. New dialogs are also established
28between the AS and each of the UE endpoints. The media from each UE is connected at the transcoding
29resource at the MRFP.
30In the first figure B.2.3.1 below, the called party returns an indication of an acceptable codec. For this case,
31the request to the MRFC will include the appropriate codec for the called party and the offer/answer model
32as defined in IETF RFC 3264 [15] with the MRFC is used. In figure B.2.3.2 below, the called party does
33not indicate any SDP, which means that more steps will be required on the subsequent INVITE request to
34set up transcoding with the MRFC. An INVITE without SDP is sent to the MRFC to get the list of codecs it
35supports. The AS then sends that list of codecs in the new INVITE that it sends to the called party. The
36B2BUA function of the AS matches up the responses.
37The offer/answer model is used for SDP negotiation between the AS/S-CSCF and the MRFC. The MRFC
38should always grant the requests from the AS (unless there is a resource problem). The MRFC responds to
39the INVITE request with a 200 response indicating the selected codec in the SDP. The MRFC will also
40reserve the requested local resources at that time. The selected codec is included by the B2BUA AS in the
41183 response to the UE. The receipt of the ACK at the MRFC triggers the playing of the tone or
42announcement.
37
1X.P0013-003
AS
S-CSCF
MRFC
1. INVITE (UE SDP)[1]

2. 100 (Trying)
100 Trying is sent,
but isn't shown for
remaining INVITEs

4. Service Logic

7. 606 (Not Acceptable, UA SDP)[2]
9. 606 [2]
8. ACK [2]
10. Service Logic

11. ACK [2]
12. INVITE (UA SDP)[3]
15. 200 OK (UA SDP)[3]
14. 200 OK (UA SDP)[3]
16. ACK [3]
17. ACK [3]
21. 183 (UA SDP)[4]
20. 183 (UA SDP)[4]
22. PRACK (UA SDP)[4]
25. 200 OK (UA SDP) [4]
24. 200 OK (UA SDP) [4]
29. 200 OK (UE SDP)[5]
28. 200 OK (UE SDP)[5]
30. 183 (UE SDP)[1]

31. 183 (UE SDP) [1]
32. PRACK [1]
33. PRACK (UE SDP)[1]
34. 200 OK (UE SDP) [1]
35. 200 OK (UE SDP) [1]
36. ACK [5]
37. ACK [5]

39. UPDATE (UE SDP) [1]
40. UPDATE (UE SDP)[1]
41. UPDATE (UE SDP) [4]

42. 200 OK (UE SDP) [4]
43. 200 OK (UE SDP) [1]

44. 200 OK (UE SDP)[1]
45. 180 (Ringing) [4]
46. 180 (Ringing) [1]
47. 180 (Ringing) [1]
48. 200 OK (Answer) [4]
49. 200 OK [1]
50. 200 OK [1]
51. ACK [1]
52. ACK [1]
53. ACK [4]
Figure B.2.3.1: Transcoding call flow (called party indicates codec)
38
X.P0013-003

2
1) INVITE request received at S-CSCF from UE [Call-ID 1].
3
3) INVITE forwarded to an AS, based on filter criteria.
4) AS service logic determines to proceed with the call.
6
7
6) S-CSCF forwards the INVITE.
9
10
11
7) Called UA returns 606 Not Acceptable in response to the INVITE request. Included in the
response is an indicator that the offered codec is not acceptable plus information on what codec
would be acceptable.
12
8) An ACK is sent to the called UA to complete the dialog for Call-ID 2.
13
9) 606 response is forwarded to the AS.
14
10) AS service logic determines that there is an MRFC that can perform the transcoding.
15
11) ACK sent to S-CSCF to complete the dialog for Call-ID 2.
16
12-17) New INVITE request sent to MRFC to establish transcoding for called UA [Call-ID 3].
17
18
18-25) New INVITE request sent to called UA to establish session between UA and MRF [Call-ID
4].
19
26-29) New INVITE request sent to MRFC to establish transcoding for calling UE [Call-ID 5].
20
21
30-53) Normal call establishment procedures from here on, with B2BUA AS performing the
appropriate signalling translations between the associated dialogs.
39
1X.P0013-003
AS
S-CSCF
MRFC

2. 100 (Trying)
100 Trying is sent,

but isn't shown for
remaining INVITEs
4. Service Logic

7. 606 (Not Acceptable, no SDP)[2]
9. 606 [2]
8. ACK [2]
10. Service Logic

11. ACK [2]
12. INVITE (no SDP)[3]
13. INVITE (no SDP)[3]
15. 183 (MRF SDP)[3]
14. 183 (MRF SDP)[3]
16. INVITE (MRF SDP)[4]
17. INVITE (MRF SDP)[4]
19. 183 (UA SDP)[4]

18. 183 (UA SDP)[4]


25. 200 OK (UA SDP) [3]

24. 200 OK (UA SDP) [3]
27. 200 OK (UA SDP)[4]
26. 200 OK (UA SDP)[4]
29. 200 (Answer) [3]
28. 200 (Answer) [3]
30. ACK [3]
31. ACK [3]
Continue the same as previous scenario (UA SDP returned in 606 response)
1
2
Figure B.2.3.2: Transcoding call flow (called party codec negotiated)

4
1) INVITE request received at S-CSCF from UE [Call-ID 1].
5
3) INVITE forwarded to an AS, based on filter criteria.
4) AS service logic determines to proceed with the call.
8
9
10
6) S-CSCF forwards the INVITE.
11
12
13
7) Called UA returns 606 Not Acceptable in response to the INVITE request. Included in the
response is an indicator that the offered codec is not acceptable but there is no information on what
codec would be acceptable (no SDP).
14
8) ACK sent to called UA to complete the dialog for Call-ID 2.
15
9) 606 response is forwarded to the AS.
16
10) AS service logic determines that there is an MRFC that can perform the transcoding.
40
X.P0013-003
11) ACK sent to S-CSCF to complete the dialog for Call-ID 2.
2
3
12-15) New INVITE request sent to MRFC to establish transcoding for called UA and to get the list
codecs supported by the MRF [Call-ID 3].
4
5
16-19) New INVITE request sent to called UA with SDP for all codecs supported by the MRF to
establish session between UA and MRF [Call-ID 4]. UA returns SDP with acceptable codecs.
6
7
20-27) A new offer with the codecs provided by the UA is sent in PRACK and the 200 OK response
indicates the selected codec.
28-31) Acknowledgements sent to complete Call-ID 3.
9Call establishment procedures from here on are common with the previous transcoding call flow.
10B.3
Example information flows for a voicemail service
11B.3.1 User out of coverage message recording

12Figure B.3.1.1 shows a possible scenario of an Application Server, which acting as a terminating UA
13performs the function of a Voicemail Server in order to terminate a call and record a message on behalf of a
14UE that is out of coverage or powered off.
15A S-CSCF is forwarded the initial INVITE destined for a UE that is not currently IMS registered. The
16Default Filter Criteria in the S-CSCF indicates that for the case of an unregistered user the INVITE should
17be forwarded to the Voicemail and Announcement Server.
18Upon receiving the INVITE request the Voicemail and Announcement Server determines that the
19destination UE has subscribed to the Voicemail Service (possibly by downloading some subscriber profile
20information via the Sh interface). The Voicemail and Announcement Server therefore in addition to playing
21an announcement to inform the caller that the called party is either powered off or out of coverage also
22informs the caller that he may leave a message for the called party.
23The calling party leaves a message for the called party and then hangs up the call by sending a BYE.
41
1X.P0013-003
AS (Voicemail
Server)
S-CSCF
1. INVITE
2. INVITE
Voicemail
Application
3. 183 Session Progress

5. PRACK
6. PRACK
7. 200 OK
8. 200 OK
9. QOS Establishment / Resource Reservation
10. UPDATE
11. UPDATE
12. 200 OK
13. 200 OK
14. 200 OK
15. 200 OK
16. ACK
17. ACK
18. Voicemail Server Plays Annoncement

19. Caller Leaves Message
20. BYE
21. BYE
22. 200 OK
23. 200 OK
1
2
Figure B.3.1.1: Voicemail server records messages

4 NOTE: For simplicity the 100 Trying response returned or received by the S-CSCF in reponse to
5
requests is omitted from figure B.3.1.1.
6
1) INVITE request destined for an unregistered user is received at the S-CSCF.
7
8
2) Based on trigger point of the initial Filter Criteria S-CSCF proxies the INVITE request to the AS
(Voicemail Server).
9
10
3-4) The AS starts the voicemail application and responds with a 183 Session Progress containing
SDP which is proxied back to the caller by the S-CSCF.
11
12
5-8) The caller responds with a PRACK containing SDP, which the S-CSCF proxies to the AS and
the AS responds with a 200 OK containing SDP which the S-CSCF proxies back to the caller.
42
X.P0013-003
QOS establishment and resource reservation takes place.
2
3
4
10-13) After completing resource reservation the caller sends a UPDATE containing SDP which is
proxied by the S-CSCF to the AS which responds with a 200 OK containing SDP which is proxied
back to the caller by the S-CSCF.
14-15) The AS then sends a 200 OK to the initial INVITE which the S-CSCF proxies to the caller.
16-17) The caller returns an ACK to the 200 OK.
7
8
18) The AS plays an announcement using the session established indicating that the caller is
powered off but that the caller may leave a message.
19) The caller leaves a message using the session established.
10
20-21) The caller hangs up by sending a BYE which the S-CSCF proxies to the AS.
11
22-23) The AS responds with a 200 OK, which the S-CSCF proxies back to the caller.
12B.3.2 User IMS registers voice mail service plays back messages
13Figure B.3.2.1 shows the scenario when the UE that has subscribed to a voicemail service with a feature
14enabled that contacts the user upon registration informing him of any recorded messages.
15The Filter Criteria downloaded by the S-CSCF indicates that a third party REGISTER request should be
16sent to the Voicemail Server. Upon receiving the third party registration of the UE, the Voicemail Server
17acting as an originating UA contacts the UE by sending an INVITE request to inform him that he has
18voicemail messages recorded while he was not registered.
19The user listens to the messages played back by the voicemail server, (only streaming class QOS is required
20for this session) and then terminates the session with a BYE.
43
1X.P0013-003
AS (Voicemail
Server)
S-CSCF
1. REGISTER
2. 401 Unauthorized
3. REGISTER
4. 200 OK
5. REGISTER
6. 200 OK
7. INVITE
8. INVITE
11. PRACK
12. PRACK
13. 200 OK
14. 200 OK
16. UPDATE
17. UPDATE
18. 200 OK
19. 200 OK
20. 180 Ringing

21. 180 Ringing
22. PRACK
23. PRACK
24. 200 OK
25. 200 OK
26. 200 OK
27. 200 OK
28. ACK
29. ACK
30. User retrieves voicemail messages
31. BYE
32. BYE
33. 200 OK
34. 200 OK
1
2
Figure B.3.2.1: Upon registration voicemail server replays messages
44
X.P0013-003
1
2
NOTE:
For simplicity the 100 Trying response returned or received by the S-CSCF in reponse to
requests is omitted from figure B.3.2.1.
3
4
5
1-4) The UE sends a REGISTER request to the S-CSCF which authenticates with a 401
Unauthorized response challenge with the authentication response being supplied in a second
REGISTER request. The registration completes with a 200 OK from the S-CSCF to the UE.
6
7
8
5-6) The S-CSCF downloads Filter Criteria for the UE from the HSS which indicates the S-CSCF
should send a third party REGISTER request on behalf of the UE to an AS that performs a
voicemail service. The AS responds to the REGISTER request with a 200 OK.
9
10
11
12
7- 8) The AS downloads subscriber data for the subscriber (possibly from the HSS via the Sh
interface) that indicates that the subscriber has enabled a feature that has the voicemail application
contact the subscriber upon registration to deliver recorded messages. The AS sends an INVITE
request containing SDP for the UE to the S-CSCF which proxies it to the UE.
13
14
9-10) The UE responds with 183 Session Progress containing SDP which the S-CSCF proxies to the
AS.
15
16
11-14) The AS sends a PRACK, which the S-CSCF proxies to the UE and the UE respond with a
200 OK which the S-CSCF proxies to the AS.
17
15) QOS establishment and resource reservation takes place.
18
19
16- 19) The AS sends an UPDATE, which the S-CSCF proxies to the UE and the UE responds with
a 200 OK which the S-CSCF proxies to the AS.
20
21
20-21) The UE sends a 180 Ringing indicating that it is alerting the user which the S-CSCF proxies
to the AS.
22
23
22-25) The AS to indicate receipt of the 180 response sends a PRACK which the S-CSCF proxies to
the UE and the UE responds with a 200 OK which the S-CSCF proxies to the AS.
24
25
26-27) When the subscriber answers the UE sends a 200 OK to the initial INVITE which the SCSCF proxies to the AS.
26
28-29) The AS acknowledges the 200 OK with an ACK which the S-CSCF proxies to the UE.
27
28
30) The AS plays an announcement indicating the number of messages stored and then plays back
the messages to the UE using the session established.
29
31-32) The UE hangs up by sending a BYE, which the S-CSCF proxies to the AS.
30
33-34) The AS responds with a 200 OK, which the S-CSCF proxies back to the UE.
45
1X.P0013-003
1Annex C (informative):
2Example for Initial filter
criteria triggering
3This example applies for call originating and terminating procedure both. But we assume this is a call
4originating procedure. User has registered with the network. Its filter criteria and addresses of the assigned
5application servers have been downloaded to its S-CSCF during registration via Cx interface. Also, the
6application server specific data may have been downloaded via the Sh interface to the application server
7during registration.
Sh
AS 1
SIP
Interface
ISC
Incoming Call leg
S
P
I
Sh
HSS
Cx
Service Logic
SIP message possibly

with modification by AS1
AS 2
SIP
Interface
4.a
ISC
Service Logic
5a
INVITE Match Initial Filter Criteria
SIP message possibly

with modification by AS2
Outgoing Call leg
S-CSCF
Initial Filter Criteria XAS1
Initial Filter Criteria YAS2
6a
Filter Criteria4.b
YAS2
8
9
SIP message forwarded by

S-CSCF
SIP message forwarded by

S-CSCF
Figure C.1: Initial Filter Criteria Triggering Example
10There is a flow example in figure C.1:

11In this example, two application servers are assigned to provide additional services to a subscriber and they
12are showed as AS1 and AS2 in this example.
13 1. User initiates a SIP session by sending a SIP initial request to its S-CSCF.
14
15
2. On receiving this request, the S-CSCF evaluates the SPTs and checks if they match the initial filter
criteria X for AS1. If they match, the S-CSCF forwards this request to AS1.
16
17
3. The AS1 performs any needed service logic based on the Service and sends the SIP request possibly
with service related modification back to the S-CSCF.
18
19
20
4.a On receiving the request from the AS, the S-CSCF evaluates the SPTs and checks if they match the
initial filter criteria Y for AS2. If they match the S-CSCF forwards the request to the associated
Application Server AS2.
46
X.P0013-003
1
2
4.b If the request doesn't match any further filter criteria, the S-CSCF forwards this request to the next
hop based on the route decision.
3
4
5.a The AS2 performs any needed service logic based on the Service and sends the SIP request possibly
with service related modification back to the S-CSCF.
5
6
6.a The S-CSCF checks the request sent by AS2 and finds that no initial criteria is matched, then the SCSCF forwards this request to next hop based on the route decision.
47

X.S0013.003 IMS Call Model Final Version

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

X.S0013.003 IMS Call Model Final Version

Uploaded by

Copyright:

Available Formats

1

IP Multimedia (IMS) session handling;

Definitions and abbreviations................................................................................................... 2

Architecture and information flows for IM multimedia session.................................................4

Architecture for a mobile originated IP multimedia session..............................................4

Architecture for a mobile terminated IP multimedia session.............................................4

Information flow for a mobile originated IP multimedia session........................................4

Information flow for a mobile terminated IP multimedia session.......................................4

Functional requirements of network entities............................................................................5

Architecture for service provision for IP multimedia subsystem........................................5

Service interaction with IP multimedia subsystem............................................................6

Functional requirements of serving CSCF...............................................................................8

Handling of mobile originating requests..........................................................................10

S-CSCF handling IMS accounting..................................................................................13

Functional requirements of HSS............................................................................................ 14

Subscriber data related storage requirements for HSS..................................................14

Procedures during IP multimedia sessions.....................................................................15

Functional requirements of the MRFC...................................................................................15

IP multimedia session handling with an OSA-Service Capability Server............................24

IP multimedia session handling with an Charging Server..................................................25

35Annex A (informative): Scalability and deployment considerations for IP multimedia service

Call forwarding example..................................................................................................... 28

User out of coverage message recording...................................................................41

User IMS registers voice mail service plays back messages......................................43

10Annex C (informative): Example for Initial filter criteria triggering.................................................46

3GPP2 X.S0013-002: " IP multimedia subsystem; Stage 2".

IETF RFC 3261: "SIP: Session Initiation Protocol".

3GPP2 S.S0086-0: 3GPP2 IMS Security Framework.

IETF RFC 3265: "Session Initiation Protocol (SIP) Event Notification".

33 [17] 3GPP2 X.S0013-006: "Cx Interface based on the Diameter protocol".

3GPP2 X.S0013-011: "Sh Interface based on the Diameter protocol".

3GPP2 X.S0013-007: " Accounting Architecture and stage 2 Description".

3GPP2 X.S0013-008: " IP Multimedia subsystem Accounting stage 3".

Definitions and abbreviations

Service Capability Server

Architecture for a mobile originated IP multimedia session

21This is specified in [3].

Architecture for a mobile terminated IP multimedia session

23This is specified in [3].

Information flow for a mobile originated IP multimedia session

25The information flow for a MO multimedia session is specified in [3].

Information flow for a mobile terminated IP multimedia session

30The information flow for a MT multimedia session is specified in [3].

Functional requirements of network entities

Architecture for service provision for IP multimedia subsystem

Service interaction with IP multimedia subsystem

presence or absence of any header field;

content of any header field or Request-URI;

NOTE 1: REGISTER is considered part of the Mobile Origination.

session description information.

21Therefore a Filter Criteria shall contain the following information:

default handling ( as described above);

b) if it matches the S-CSCF shall:

5. route the request based on normal SIP routing behaviour.

Figure 5.2.1: Application triggering architecture

Functional requirements of serving CSCF

Modes of operation of the S-CSCF

General overview of functional models and modes of operation of the S-CSCF

15Figure 6.1.1.1 identifies the components of a functional model of the S-CSCF.

Interfaces defined for S-CSCF

116.2.1 S-CSCF CSCF (Mw) interface

Handling of SIP registration