TIA-873.003-B

tukwilagleefulInternet and Web Development

Oct 31, 2013 (3 years and 11 months ago)

215 views



X.S0013
-
003
-
B v1.0

i


1

All
-
IP Core Network Multimedia Domain

2

IP Multimedia Subsystem


IP Multimedia Call Model; Stage 2

3


4

Contents

5


6

Foreword

................................
................................
................................
................................
....
iv

7

Revision History

................................
................................
................................
..........................
iv

8

1

Scope

................................
................................
................................
................................
..

1

9

2

References
................................
................................
................................
...........................

1

10

3

Definitions and abbreviations

................................
................................
................................
.

2

11

3.1

Definitions
................................
................................
................................
......................

2

12

3.2

Abbreviations

................................
................................
................................
.................

3

13

4

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

4

14

4.1

Architecture for a mobile originated IP multimedia session

................................
................

4

15

4.2

Architecture for a mobile terminated IP multimedia session

................................
...............

4

16

4.3

Information flow for a mobile originated IP multimedia session

................................
..........

4

17

4.4

Information flow for retrieval of routing information for mobile terminated IP multimedia
18

session

................................
................................
................................
................................
....

4

19

4.5

Information flow for a mobile
terminated IP multimedia session

................................
.........

4

20

5

Functional requirements of network entities

................................
................................
............

5

21

5.1

Architecture for service provision for IP

multimedia subsystem

................................
..........

5

22

5.2

Service interaction with IP multimedia subsystem

................................
.............................

6

23

6

Functional requirements of serving CSCF

................................
................................
..............

9

24

6.1

Modes of operation of the S
-
CSCF

................................
................................
..................

9

25

6.1.1

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

.............................
9

26

6.2

Interfaces defined for S
-
CSCF

................................
................................
......................

10

27

6.2.1

S
-
CSCF


CSCF (Mw) interface

................................
................................
................................
.............
10

28

6.2.2

S
-
CSCF


Application Server (ISC) interface
................................
................................
.......................
10

29

6.2.3

S
-
CSCF


HSS (Cx) interface

................................
................................
................................
..................
10

30

6.2.4

Void

................................
................................
................................
................................
..............................
10

31

6.2.5

Void

................................
................................
................................
................................
..............................
10

32

6.3

Handling of SIP registration
................................
................................
...........................

10

33

6.4

Handling of mobile originating
requests

................................
................................
.........

11

34

6.5

Handling of mobile terminating requests

................................
................................
........

12

35

6.5.1

Handling of mobile terminating requests, registered user

................................
................................
...
12

36

6.5.2

Handling of mobile terminating requests, unregistered user

................................
..............................
12

37

6.6

Handling of IP multimedia session release requests

................................
.......................

13

38

6.6.1

S
-
CSCF proxying release request

................................
................................
................................
............
13

39

6.6.2

S
-
CSCF initiating release request

................................
................................
................................
............
13

40

6.7

Handling of subscription and notification

................................
................................
........

14

41

6.8

S
-
CSCF handling IMS accounting

................................
................................
.................

14

42

X.S0013
-
003
-
B v1.0

ii

6.9

Description of subscri
ber data

................................
................................
.......................

15

1

6.9.1

Application Server subscription informat ion

................................
................................
........................

15

2

6.9.2

Filter Criteria
................................
................................
................................
................................
...............

15

3

6.9.3

Authentication data

................................
................................
................................
................................
....

16

4

7

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

16

5

7.1

Subscriber data related storage r
equi rements for HSS

................................
....................

16

6

7.2

Interfaces defined for HSS

................................
................................
............................

16

7

7.2.1

HSS


CSCF (Cx) interface
................................
................................
................................
......................

16

8

7.2.2

HSS
-

Application Server (Sh) interface

................................
................................
................................

16

9

7.2.3


Void

................................
................................
................................
................................
.............................

16

10

7.2.4

Void

................................
................................
................................
................................
..............................

16

11

7.3

Procedures during IP multimedia registration
................................
................................
..

16

12

7.4

Procedures during IP multimedia sessions

................................
................................
.....

16

13

8

Functional requirements of the MRFC

................................
................................
..................

17

14

8.1

Functionality of the MRFC

................................
................................
.............................

17

15

8.1.1

Overview of MRFC Functionality

................................
................................
................................
..........

17

16

8.1.2

Tones and announcements
................................
................................
................................
........................

17

17

8.1.3

Ad hoc conferences (multiparty calls)

................................
................................
................................
....

18

18

8.1.4

Transcoding
................................
................................
................................
................................
.................

18

19

8.2

Interfaces defined for MRFC

................................
................................
.........................

18

20

8.2.1

MRFC


S
-
CSCF (Mr) interface

................................
................................
................................
.............

18

21

9

Generic IP multimedia session handling for SIP Application Servers
................................
.......

19

22

9.1

Architecture
................................
................................
................................
..................

19

23

9.1.1

Modes of operation between Application Server and S
-
CSCF

................................
..........................

20

24

9.2

Interfaces defined for a SIP Application Server

................................
...............................

23

25

9.2.1

S
-
CSCF


Application Server (ISC) interface

................................
................................
......................

23

26

9.2.2

Application Server


HSS (Sh) interface

................................
................................
...............................

23

27

9.3

Description of Appl
ication Server related subscriber data

................................
................

23

28

9.3.1

Application server subscription information

................................
................................
.........................

23

29

9.4

Procedures for multimedia ses
sion handling with a SIP based Application Server

.............

23

30

9.4.1

Application Server handling of mobile originating requests

................................
..............................

23

31

9.4.2

A
pplication Server handling of mobile terminating requests

................................
.............................

24

32

9.4.3

Application Server handling of SIP registration

................................
................................
...................

24

33

9.4.4

Appl
ication Server handling of IP multimedia session release requests

................................
..........

24

34

9.4.5

Application server handling of IP multimedia accounting

................................
................................
.

25

35

10

Void

................................
................................
................................
................................

26

36

11

IP multimedi a session handling with an OSA
-
Service Capability Server
...............................

26

37

1
2.

IP multimedi a session handling w
ith an
Charging

Server

................................
....................

26

38

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

................................
................................
................................
................................
.................

27

40

Annex B (informative): Information flows for example services

................................
......................

29

41

B.1

Call forwarding example

................................
................................
................................
...

29

42

B.1.1

Call forwarding through
Application Servers

................................
................................
.......................

29

43

B.1.1.1

Service activation and programming

................................
................................
................................
..

30

44

B.1.1.2

Service invocation and control

................................
................................
................................
............

30

45

B.1.2

Assumptions
................................
................................
................................
................................
................

31

46



X.S0013
-
003
-
B v1.0

iii

B.1.3

UE redirect based call flows

................................
................................
................................
.....................
31

1

B.1.4

S
-
CSCF based red
irect call flows

................................
................................
................................
............
32

2

B.2

Announcement, conferencing and transcodi ng examples using MRFC
................................

34

3

B.2.1

Example information flow for a m
obile originated IP multimedia session that results in playing
4

an announcement
................................
................................
................................
................................
..........................
34

5

B.2.2

Example information flow for a mobile originated IP multimedia ad hoc conferencing session
6

(mult iparty c
all)

................................
................................
................................
................................
............................
36

7

B.2.3

Example information flows for a mobile originated IP multimedia session that requires
8

transcoding

................................
................................
................................
................................
................................
....
38

9

B.3

Example i
nformation flows for a voicemail service
................................
..............................

42

10

B.3.1

User out of coverage message recording

................................
................................
...

42

11

B.3.2

User IMS registers voice mail
service plays back messages

................................
........

44

12

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

................................
...................

47

13


14

15

X.S0013
-
003
-
B v1.0

iv

Foreword

1


2

(This foreword is not part of this document)

3


4

This document was prepared by 3GPP2 TSG
-
X.

5


6

This document contains major modifications from the previous revision.

7


8

This document is part of the series of documents X.S0013.

9


10

This document contains portions of material copied from 3GPP document number(s)

TS 23.218 v 6
.
4
.0. The
11

copyright on the 3GPP document is owned by the Organizational Partners of 3GPP (ARIB
-

Association of
12

Radio Industries and Businesses, Japan;
CCSA
-

the China Communications Standards Association
, China; ETSI
13



European Telecommunica
tions Standards Institute; ATIS, USA
-

Alliance for Telecommunication Industry
14

Solutions; TTA
-

Telecommunications Technology Association, Korea; and TTC


Telecommunication
15

Technology Committee, Japan), which have granted license for reproduction and for u
se by 3GPP2 and its
16

Organizational Partners

17


18

Revision History

19


20

Revision

Changes

Date

0 v1.0

Initial Publication

December 2003

0 v2.0

Adding release 5 CRs

July 2005

A v1.0

Release A

November 2005

B

v
0.1

Release
B
with approved
release 6
CRs

from CT # 3
2

June 2006

B v1.0

Release B V&V version

August 2006

B v1.0

Release B publication

December 2007


21

22



X.S0013
-
003
-
B v1.0

1


1

Scope

1

The present document specifies the IP Multimedia (IM) Call Model for handling of an IP multimedia
2

session origination and termination for an IP Mu
ltimedia subscriber.

3

The present document includes interactions between an Application Server and IP multimedia sessions.

4

The IP Multimedia (IM) Subsystem stage 2 is specified [3] and the stage 3 for the IP multimedia call
5

control based on SIP and SDP is

specified in [5].

6

2

References

7

2.1

Normative References

8

The following documents contain provisions, which, through reference in this text, constitute provisions of
9

the 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]

Void

17

[3]

3GPP2

X.S0013
-
002
-
A v1.0: " IP multimedia subsystem; Stage

2".

18

[4]

Void

19

[5]

3GPP2

X.S0013
-
004
-
A v1.0: "IP multimedia call control protocol based on SIP and SDP; stage 3".

20

[6]

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

21

[7]

3GPP2 X.S0017: "Open Service Access (OSA); Application Programming Interface (API) "
.

22

[8]

3GPP2 X.S0013
-
005
-
A v1.0: "IP Multimedia (IM) Subsystem Cx Interface; Signalling flows and
23

message contents".

24

[9]

Void

25

[10]

Void

26

[11]


3GPP2 S.R0086
-
A v1.0: “3GPP2 IMS Security Framework”.

27

[12]

Void

28

[13]

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

29

[14]

Void

30

[15]

IETF RFC 3264: "An Offer/Answer Model with Session Description Protocol".

31

[16]

Void

32


[17]

3GPP2 X.S0013
-
006
-
A v1.0: "Cx Interface based on the Diameter protocol".

33

[18]

3GPP2 X.S0013
-
010
-
A v1.0: "IP Multimedia Subsyst
em (IMS) Sh Interface; Signalling flows and
34

message contents".

35

[19]

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

36

X.S
0013
-
003
-
B v1.0

2


[
20
]

3GPP2 X.S
0013
-
007
-
A v1.0: "
IP Multimedia Subsystem


Charging Architecture

".


1

[
21
]

3GPP2 X.S0013
-
0
08
-
A v1.0:

"

IP Multimedia Subsystem


Offline Accounting Information Flows and
2

Protocol

".

3

3

Definitions and abbreviations

4

3.1

Definitions

5

For the purposes of the present document, the terms and definitions given in [
3
] and the following apply:

6


7

Application Server
Incoming Leg Control Model (AS
-
ILCM):

models AS behavior for handling SIP
8

information for an incoming leg.

9


10

Application Server information (AS
-
info):

AS
-
info contains individualized information concerning one
11

particular Application Server entry.

12

This infor
mation contains e.g. Application Server Address (6.9.2.1) and it's corresponding Default IP
13

Multimedia Handling information (6.9.2.2).

14


15

Application Server Outgoing Leg Control Model (AS
-
OLCM):

models AS behaviour for handling SIP
16

information for an outgoin
g leg.

17


18

Combined ILSM OLSM


Incoming/outgoing Leg State Model:

models the behaviour of an S
-
CSCF for
19

handling SIP messages on an incoming and outgoing session leg.

20


21

Filter Criteria (FC):

the information which the S
-
CSCF receives from the HSS or the AS tha
t defines the
22

relevant SPTs for a particular application.

23

They define the subset of SIP requests received by the S
-
CSCF that should be sent or proxied to a particular
24

application.

25


26

Incoming Leg Control Model (ILCM):

models the behaviour of an S
-
CSCF for ha
ndling SIP information
27

sent to and received from an AS for an incoming session leg.

28


29

Initial Filter Criteria (iFC):
filter criteria that are stored in the HSS as part of the user profile and are
30

downloaded to the S
-
CSCF upon user registration.

31

They represe
nt a provisioned subscription of a user to an application.

32


33

Initial Request:

a SIP request that either initiates the creation of a new dialog or is part of a standalone
34

transaction.

35


36

IP Multimedia session:
IP Multimedia session and IP Multimedia call are t
reated as equivalent in the
37

present document.

38


39

IP Transport Subsystem:

refers to any collection of network entities that provides the underlying IP
40

transport for use to provide connectivity to or between IMS entities.

41


42

Outgoing Leg Control Model (OLCM):

mo
dels the behavior of an S
-
CSCF for handling SIP information
43

received from and sent to an AS for an outgoing session leg.

44


45

Private User Identity:

a unique global identity defined by the Home Network Operator, as defined in [3].

46


47

Public User Identity:
the pu
blic user identity/identities are used by any user for requesting
48

communications to other users and are in the form of a SIP URI or TEL URL as defined in [3].

49


50



X.S0013
-
003
-
B v1.0

3


Service Point Trigger (SPT):

a point in the SIP signaling that may cause the S
-
CSCF to send/prox
y the
1

SIP message to an SIP AS or an OSA SCS.

2

The subset of all possible SPTs which are relevant to a particular application are defined by means of Filter
3

Criteria.

4


5

Service Platform Trigger Points (STP):

the points in the SIP signaling that instruct the
SIP AS and OSA
6

SCS to trigger the service logic.

7


8


Subsequent Filter Criteria (sFC):
filter criteria that are signaled from the SIP AS or the OSA SCS to the
9

S
-
CSCF.

10

They allow for dynamic definition of the relevant SPTs at application execution time.

11


12

Subs
equent Request:

a SIP request which is part of an existing dialog. This also includes target refresh
13

requests as defined in RFC 3261 [6].

14


15

Standalone Transaction:

a SIP transaction that is not part of an existing dialog and does not initiate the
16

creation o
f a new dialog.

17

3.2

Abbreviations

18

For the purposes of the present document, the following abbreviations apply:

19

API

Application Programming Interface

20

AS

Application Server

21

AS
-
ILCM

Application Server Incoming Leg Control Model

22

AS
-
OLCM

Application Server Outg
oing Leg Control Model

23

B2BUA

Back
-
to
-
Back User Agent

24

CF

Call Forwarding

25

CFonCLI

Call Forwarding on Calling Line Identification

26

CGI

Common Gateway Interface

27

CPL

Call Processing Language

28

CLI

Calling Line Identification

29

CSCF

Call Session Control Function

30

ECF

Event Charging Function

31

FC

Filter Criteria

32

HPLMN

Home PLMN

33

HSS

Home Subscriber Server

34

IETF

Internet Engineering Task Force

35

I
-
CSCF

Interrogating CSCF

36

ICID

IMS Charging ID

37

ICN

IP Connectivity Network

38

iFC

Initial Filter Criteria

39

ILCM

Incoming Leg Control Mod
el

40

IM

IP Multimedia

41

IMS

IP Multimedia Subsystem

42

IOI

Inter Operator Identifier

43

IP

Internet Protocol

44

ISC

IP multimedia Service Control

45

MGCF

Media Gateway Control Function

46

MO

Mobile Originating

47

MRFC

Multimedia Resource Function Controller

48

MRFP

Multimedia Reso
urce Function Processor

49

MT

Mobile Terminating

50

OLCM

Outgoing Leg Control Model

51

OSA

Open Service Access

52

PLMN

Public Land Mobile Network

53

P
-
CSCF

Proxy CSCF

54

X.S
0013
-
003
-
B v1.0

4


RFC

Request For Comments

1

SCF

Session Charging Function

2

SCIM

Service Capability Interaction Manager

3

SCS

S
ervice Capability Server

4

SDP

Session Description Protocol

5

sFC

Subsequent Filter Criteria

6

SIP

Session Initiation Protocol

7

S
-
CSCF

Serving CSCF

8

SPT

Service Point Trigger

9

STP

Service platform Trigger Points

10

UA

User Agent

11

UE

User Equipment

12

URI

Uniform Resource
Identifier

13

URL

Uniform Resource Locator

14

XML

Extensible Markup Language

15

4

Architecture and information flows for IM multimedia
16

session

17

Clauses 4.1 and 4.2 show the architecture for handling a basic MO multimedia session and a basic MT
18

multimedia session
. A basic mobile
-
to
-
mobile multimedia session is treated as the concatenation of a MO
19

multimedia session and a MT multimedia session.

20

Clauses 4.3, 4.4 and 4.5 show the information flows for handling a basic MO multimedia session and a
21

basic MT multimedia s
ession.

22

4.1

Architecture for a mobile originated IP multimedia session

23

This is specified in [3].

24

4.2

Architecture for a mobile terminated IP multimedia session

25

This is specified in [3].

26

4.3

Information flow for a mobile originated IP multimedia session

27

The

information flow for a
n

MO multimedia session is specified in [3].

28

4.4

Information flow for retrieval of routing information for mobile
29

terminated IP multimedia session

30

The information flow for retrieval of routing information for a
n

MT multimedia session

is specified in [3].

31

4.5

Information flow for a mobile terminated IP multimedia session

32

The information flow for a
n

MT multimedia session is specified in [3].


33

34



X.S0013
-
003
-
B v1.0

5



1

5

Functional requirements of network entities

2

5.1

Architecture for service provision for IP m
ultimedia subsystem

3


4


5

NOTE: Not all interfaces shown are within the scope of this document.

6


7

Figure 5.1.1: Functional architecture for support of service provision for
IP
m
ultimedia
8

subsystem

9

Figure 5.1.1 illustrates the archite
cture with the S
-
CSCF communicating to Application Servers via the IP
10

multimedia service control (ISC) interface. The Application Servers can be:

11

-

SIP Application Servers
-

which may host and execute services. It is intended to allow the SIP
12

Application S
erver to influence and impact the SIP session on behalf of the services;

13

-

the OSA service capability server (OSA SCS) which interfaces to the OSA framework Application
14

Server and which provides a standardized way for third party secure access to the IM su
bsystem.
15

The OSA reference architecture defines an OSA Application Server as an entity that
provides the
16

service logic execution environment for client applications using the OSA API as specified in [7].
17

This definition of Application Server differs from t
he definition of Application Server in the context
18

of service provisioning for the IM subsystem, i.e. the entity communicating to the S
-
CSCF via the
19

ISC interface;

20

-

in addition a specialized type of SIP Application Server, the service capability interacti
on manager
21

(SCIM) which performs the role of interaction management between other application servers.

22

All the Application Servers, (including the OSA SCS) behave as SIP application servers on the ISC
23

interface.

24

In addition the Application Servers can also

interact with the MRFC via the S
-
CSCF (ISC and Mr
25

interfaces) in order to control Multimedia Resource Function processing.

26

X.S
0013
-
003
-
B v1.0

6


5.2

Service interaction with IP multimedia subsystem

1

Service Point Triggers (SPTs) are those points in the SIP signalling on which F
ilter Criteria can be set. The
2

following SPTs are defined:

3


4

-

any initial known or unknown SIP method (e.g. REGISTER, INVITE, SUBSCRIBE, MESSAGE);

5

-

registration type


indicates if the REGISTER request is initial registration, re
-
registration, or de
-
6

regis
tration;

7

-

presence or absence of any known or unknown header field;

8

-

content of any known or unknown header field or Request
-
URI;

9

-

direction of the request with respect to the served user


either mobile originated (MO) or mobile
10

terminated (MT) to regi
stered user; or mobile terminated to unregistered user; see [8] for the details
11

of the direction information in service point trigger;

12

NOTE 1:

REGISTER is considered part of the Mobile Origination.
See [5] for further information
13

about how to determine MO

or MT.

14


15

NOTE 2: The S
-
CSCF shall verify if the end user is barred before checking if any trigger applies for
16

that end user.

17

-

session description information.

18

A Filter Criteria triggers one or more SPTs in order to send the related request to one specific

application
19

server. The set of Filter Criteria that is stored for a service profile of a specific user is called "Application
20

Server Subscription Information". In order to allow the S
-
CSCF to handle the different Filter Criteria in the
21

right sequence, a p
riority shall be assigned to each of them.
If the S
-
CSCF can not reach the A
pplication
22

S
erver
, the S
-
CSCF shall apply the default handling associated with the trigger. This default handling shall
23

be :

24

-

to continue verifying
if
the triggers of lower priori
ty in

the list match; or

25

-

to abandon verification of matching of the triggers of lower priority in the list; and to release the
26

dialogue.

27

Therefore a Filter Criteria shall contain the following information:

28

-

address of the Application Server to be contac
ted;

29

-

priority of the Filter Criteria providing the sequence in which the criteria shall be applied;

30

-

Trigger Points, which indicate the Service Point Triggers (SPTs) triggered by this Filter Criteria.
31

The SPTs may be linked by means of logical expressio
ns (AND, OR, NOT, etc.);

32

-

default handling
( as described above
)
;

33

-

optional Service Information that shall be added to the message body before it is sent to the
34

Application Server.

35

The same priority shall not be assigned to more than one initial Filter C
riteria for a given end user.

36


37

The S
-
CSCF shall request from the HSS the relevant set of iFCs that applies to the end user (i.e., registered,
38

unregistered, or both). If the S
-
CSCF has a set of iFCs that is deemed valid (e.g., from a previous request),
39

the
S
-
CSCF need not request a new set.

40


41



X.S0013
-
003
-
B v1.0

7


In the case that multiple Filter Criteria are sent from the HSS to the S
-
CSCF, the S
-
CSCF shall check the
1

filter criteria one by one according to their indicated priority, when the S
-
CSCF receives a message via the
2

Mw in
terface.

3


4

On reception of a REGISTER request, the S
-
CSCF shall send a third
-
party REGISTER request to each
5

Application Server that matches the Filter Criteria sent from the HSS for the REGISTER event.

6


7

On an event that causes network
-
initiated deregistrati
on, the S
-
CSCF shall send a third
-
party REGISTER
8

request to each Application Server that matches the Filter Criteria sent from the HSS as if a equivalent
9

REGISTER request had been received from the user deregistering that public user identity, or combinati
on
10

of public user identities

11


12

On reception of any other request the S
-
CSCF shall:

13


14

1.

set up the list of filter criteria for that request according to their priority


the sequence of the filter
15

criteria shall not be changed until the request finally leave
s the S
-
CSCF via the Mw interface again;

16

2.

parse the received request in order to find out the Service Point Triggers (SPTs) that are included in
17

it;

18

3.

check whether the trigger points of the filter criteria with the next highest priority are matched by
19

the SPTs of the request and

20

a)

if it does not match the S
-
CSCF shall immediately proceed with step 4;

21

b)

if it matches the S
-
CSCF shall:

22

i)

add an indication to the request which will allow the S
-
CSCF to identify the message on the
23

incoming side, even if
its dialog identification has been changed e.g. due to the Application
24

Server performing third party call control;

25

ii)

forward the request via the ISC interface to the AS indicated in the current filter criteria. The
26

Application Server then performs the se
rvice logic, may modify the request and may send the
27

request back to the S
-
CSCF via the ISC interface;

28

iii)

proceed with step 4 if the request was received again from the Application Server via the ISC
29

interface;

30

4.

repeat the above steps 2 and 3 for every

filter criteria which was initially set up (in step 1) until the
31

last filter criteria has been checked;

32

5.

route the request based on normal SIP routing behaviour.

33

If an Application Server decides to locally terminate a request and sends back a final res
ponse for that
34

request via the ISC interface to the S
-
CSCF, the S
-
CSCF shall abandon verification of the matching of the
35

triggers of lower priority in the list. The final response shall include the indicator defined in step 3 b) i)
36

above, so that the S
-
CSC
F can correlate the messages.

37


38

X.S
0013
-
003
-
B v1.0

8


1


2

Figure 5.2.1: Application triggering architecture

3

Each invoked Application Server/service logic may decide not to be engaged with the invoked session by
4

indicating that during the very first SIP tr
ansaction when the Record
-
Route/Route is generated for
5

subsequent SIP requests. The denial shall mean that subsequent requests shall not be routed to such
6

Application Servers/service logic any more during the lifetime of that session. Any Application Serve
r,
7

which has determined that it will not receive subsequent requests for a session cannot revoke this
8

determination by means of Initial Filter Criteria (iFC).

9

NOTE:

Care should be taken in design of the Initial Filter Criteria when designing services to av
oid
10

unintended loops being setup, where requests from an Application Server may be sent back
11

to the same Application Server. This does not imply that it is not allowed for requests to be
12

sent back to the same Application Server when that is intended behavi
our as part of the
13

design of the service and the Application Server is able to handle this correctly. Special care
14

should be taken for the case when an Application Server may act as an originating UA or
15

B2BUA and may originate an initial request causing ev
aluation of Initial Filter Criteria.

16


17



X.S0013
-
003
-
B v1.0

9


6

Functional requirements of serving CSCF

1

6.1

Modes of operation of the S
-
CSCF

2

6.1.1

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

3

4


5

Figure 6.1.1.1: S
-
CSCF
f
unctional model with incoming leg control and outgoing leg
6

control

7

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

8

NOTE:

These components are defined only as a model of the expected behaviour of the S
-
CSCF and
9

are not intended

to define or constrain the actual implementation.

10

The components include the Combined ILSM OLSM, the ILCM and OLCM and the Registrar and Notifier.
11

There is a single Combined ILSM OLSM, which shall be able to store session state information. It may act
12

on
each leg independently, acting as a SIP Proxy, Redirect Server or User Agent dependant on the
13

information received in the SIP request, the filter conditions specified or the state of the session.

14

It shall be possible to split the application handling on ea
ch leg and treat each endpoint differently.

15

There is a single ILCM, which shall store transaction state information.

16

There is a single OLCM, which shall store transaction state information.

17

X.S
0013
-
003
-
B v1.0

10


The Registrar and Notifier component handles registration and subs
cription to and notification of
1

registration events.

2

6.2

Interfaces defined for S
-
CSCF

3

6.2.1

S
-
CSCF


CSCF (Mw) interface

4

The protocol used between two CSCFs is also based on Session Initiation Protocol, which is specified in
5

[5].

6

6.2.2

S
-
CSCF


Applicati
on Server (ISC) interface

7

The protocol used between the S
-

CSCF and the Application Servers (ISC interface) is also based on
8

Session Initiation Protocol, which is specified in [5].

9

6.2.3

S
-
CSCF


HSS (Cx) interface

10

This interface is used to send subscriber

data to the S
-
CSCF; including Filter criteria, which indicates
11

which SIP requests should be proxied to which Application Servers.

12

The protocol used between the S
-
CSCF and HSS (Cx Interface) is specified in [8].

13

6.2.4

Void

14


15

6.2.5

Void

16


17

6.3

Handling of S
IP registration

18

Upon receiving the initial registration request from the user, the S
-
CSCF shall authenticate the user and
19

upon receiving a subsequent registration request containing valid authentication credentials, request the
20

HSS to send the relevant ser
vice profile(s) for the user’s subscription. More than one service profile may be
21

sent, depending on configuration options for identifying implicitly registered public user identities. For
22

further detailed information on registration, profile download and
authentication procedures see [5] and
23

[11].

24

The initial filter criteria

(subset of the profile) is stored

locally
at the S
-
CSCF, as specified in
[5].

25

The S
-
CSCF shall verify if the triggers match, from the highest to the lowest priority (see subclause 5.2)
.

26


27

After a successfully authenticated registration, the S
-
CSCF shall download from the HSS all the implicitly
28

registered public user identities associated with the registered public user identity. The S
-
CSCF shall then
29

verify, in their order of priority, i
f the triggers downloaded from the HSS match.
For each service profile in
30

the implicit registration set, i
f the registration request from the user matches a trigger, the S
-
CSCF performs
31

a third party registration to the application servers which are intere
sted to be informed about the user
32

registration event of these public user identities. This may trigger services to be executed by an Application
33

Server.

34


35

The important information carried in the third party REGISTER request is the public user identity, th
e S
-
36

CSCF address and the expiration time. It shall be possible based on operator configuration to use one of
37

the implicitly registered public user identities as the public user identity in the To header of the third party
38

REGISTER request sent to the Appl
ication Server. Additional application server specific data, which is
39

associated with the Filter Criteria and obtained from the HSS, is added to the REGISTER request body.
40

This data should include the private user identity for Application Servers as receiv
ed from the HSS.

41

This third party registration will include an expiration time that is equal to the expiration time sent to the
42

UE by the S
-
CSCF in the 200 OK response to the incoming REGISTER request

43

On receiving a failure response to one of the REGISTER
requests, the S
-
CSCF shall apply the "default
44

handling" related with the initial Filter Criteria’s trigger used (see sections 5.2, 6.9.2.2).

45

See figure 6.3.1:

46



X.S0013
-
003
-
B v1.0

11


1


2

Figure 6.3.1: S
-
CSCF
handling registration

3

Application Servers can i
n addition subscribe to the Public User Identity’s Registration Event Package.
4

This provides a mechanism for the Application Server to discover all the implicitly registered public user
5

identities without requiring multiple Register requests to be sent to
the Application Server and to obtain the
6

current capabilities of the UE as well as be notified about refresh registrations and de
-
registrations. The S
-
7

CSCF will send NOTIFY requests to the Application Server that has subscribed to the registration event
8

pa
ckage for the registered public user identity.

9


10

NOTE:


When the Application Server maintains a persistent subscription to the reg
-
event
11

Registration Event Package it is not necessary for the Application Server to receive third
12

party registration requests
from the S
-
CSCF in response to refresh and de
-
registration events
13

as these are communicated to the Application Server in the Registration event notifications. It
14

is therefore recommended in this case that Filter Criteria is used to only trigger a third par
ty
15

registration in response to an initial registration (see section 5.2).

16


17

More information on these procedures is contained in [5].

18

6.4

Handling of mobile originating requests

19

The S
-
CSCF shall verify if the public user identity is barred. If so, it shall
respond with an error code and
20

stop further session processing.

21

The S
-
CSCF only looks for initial filter criteria when receiving an initial request.

22

The initial filter criteria

(subset of the profile) has already been downloaded from the HSS and is stored

23

locally
at the S
-
CSCF, as specified in
[5].

24

When such a session request comes in, the S
-
CSCF shall first check whether this is an originating request
25

or a terminating request
in order to perform the matching procedure with SPTs within initial filter crite
ria
.
26

This clause describes the requirements for the S
-
CSCF when this request is a mobile originating request.
27

So, if this request is a mobile originating request, the S
-
CSCF shall:

28


29

-

check whether this request matches the initial filter criteria with the
highest priority for that user by
30

checking the service profile against the public user identity, which was used to place this request;

31

-

if this request matches the initial filter criteria, the S
-
CSCF shall forward this request to that
32

application server,
then check for matching of the next following filter criteria of lower priority, and
33

apply the filter criteria on the SIP method received from the previously contacted application server;

34

-

if this request does not match the highest priority initial filter

criteria, check for matching of the
35

following filter criteria priorities until one applies;

36

X.S
0013
-
003
-
B v1.0

12


-


if no more (or none) of the initial filter criteria apply, the S
-
CSCF shall forward this request
1

downstream based on the route decision;

2

-

in any instance, if
the contact of the application server fails, the S
-
CSCF shall use the "default
3

handling" associated with the initial Filter Criteria to determine if it shall either terminate the call or
4

let the call continue
based on the information in the filter criteria
; if the filter criteria does not
5

contain instruction
to the S
-
CSCF regarding the failure of the contact to the application server,

the
6

S
-
CSCF shall let the call continue as the default behaviour.

7

6.5

Handling of mobile terminating requests

8

6.5.1

Handling
of mobile terminating requests, registered user

9

The S
-
CSCF shall verify if the public user identity is barred. If so, it shall respond with an error code and
10

stop further session processing.

11

The S
-
CSCF only looks for initial filter criteria when receiving
an initial request. A terminating initial
12

request may also originate from an Application Server via the ISC interface. Terminating Initial requests
13

from an Application Server via the ISC
interface also causes

the S
-
CSCF to look for initial filter criteria.

14


15

When such a request comes in, the S
-
CSCF shall first check whether this is an originating request or a
16

terminating request. For terminating initial requests the S
-
CSCF shall first perform any routing of the
17

request to Application Server based on matching

of initial Filter Criteria before performing other routing
18

procedures towards the terminating UE, (e.g. forking, caller preferences, etc). This section describes the
19

requirements for the S
-
CSCF when this request is a terminating request. So, if this requ
est is a terminating
20

request, the S
-
CSCF shall:

21

-

if unavailable, download the relevant subscriber profile including the initial filter criteria from the
22

HSS;

23

-

use the initial Filter Criteria for the Mobile Terminating request;

24

-

in case the Request
-
URI chang
es when visiting an Application Server, terminate the checking of
25

filter criteria, route the request based on the changed value of the Request
-
URI and not execute the
26

subsequent steps;

27

-

the subsequent requirements for the S
-
CSCF are the same as those for
handling originating requests.

28

It may be possible that originating UE and terminating UE shares the same S
-
CSCF and Application
29

Server, therefore the shared application server may interact with the S
-
CSCF twice in one transaction but in
30

originating and ter
minating procedures respectively.

31

6.5.2

Handling of mobile terminating requests, unregistered user

32

The S
-
CSCF shall verify if the public user identity is barred. If so, it shall respond with an error code and
33

stop further session processing.

34

The S
-
CSCF onl
y looks for initial filter criteria when receiving an initial request. A terminating initial
35

request may also originate from an Application Server via the ISC interface. Terminating Initial requests
36

from an Application Server via the ISC interface also cau
se the S
-
CSCF to look for initial filter criteria.

37


38

When such a request comes in, the S
-
CSCF shall first check this is an originating request or a terminating
39

request. This clause describes the requirements for the S
-
CSCF when this request is a terminating

request.
40

So, if this request is a terminating request, the S
-
CSCF shall:

41


42

-

if unavailable, download the relevant subscriber profile including the initial filter criteria from the
43

HSS;

44

-

use the initial Filter Criteria for the Mobile Terminating request to
unregistered user;

45



X.S0013
-
003
-
B v1.0

13


-

in case the Request
-
URI changes when visiting an AS, terminate the checking of filter criteria, route
1

the request based on the changed value of the Request
-
URI and do not execute the subsequent steps;

2

-

the subsequent requirements for
the S
-
CSCF are the same as those for handling originating requests.

3

It may be possible that originating UE and terminating UE shares the same S
-
CSCF and Application
4

Server, therefore the shared application server may interact with the S
-
CSCF twice in one t
ransaction but in
5

originating and terminating procedures respectively.

6

6.6

Handling of IP multimedia session release requests

7

In handling session release, the S
-
CSCF may either proxy the release request or initiates a release request.

8

6.6.1

S
-
CSCF proxying

release request

9

When the S
-
CSCF receives a release request from some entities (etc, application server, user agent) for a
10

dialog, it proxies the release request to the destination according to route information in that release request.

11


12

Figure 6.6.1.1: S
-
CSCF proxying release request

13

6.6.2

S
-
CSCF initiating release request

14

For some reason (e.g., administration decision of the network), the S
-
CSCF may be required to release an
15

ongoing dialog. In this case, the S
-
CSCF shall send a
release request to all the entities that are involved in
16

this dialog. In a typical AS involved dialog, the S
-
CSCF should send the release request to the AS and the
17

UE it is serving as shown in figure 6.6.2.1.

18


19

Figure 6.6.2.1: S
-
CSCF initiating release request

20

X.S
0013
-
003
-
B v1.0

14


6.7

Handling of subscription and notification

1

The S
-
CSCF supports subscription to and notification of user registration events by the UE, P
-
CSCFs and
2

Application Servers using the mechanisms specified in [13]. The subscribin
g entity may subscribe to the
3

registration state of individual public user identities for the purpose of discovering the implicitly registered
4

public user identities. When notifying a subscribing entity of a change in the registration state of a
5

subscribed

to public user identity the S
-
CSCF shall include in the notification all the implicitly registered
6

public user identities associated with the registered public user identity in addition to the registered public
7

user identity.

8


9

F
igure 6.7.1: Application Server


S
-
CSCF subscribe notify dialog

10

6.8

S
-
CSCF handling IMS accounting

11

In registration processing, a S
-
CSCF may send a third party REGISTER to an application server, where the
12

ICID, IOI and charging function addresses are inclu
ded in the message.

13

During a session, the S
-
CSCF shall generate the accounting records for accounting purposes.

14

In a session originating case, when receiving an incoming initial request, this request will carry the ICID
15

generated by the upstream P
-
CSCF, wh
ich is serving the originating user; the S
-
CSCF shall store the ICID
16

for this session and handle this request based on filter criteria. After processing this request the S
-
CSCF
17

shall include the ICID and the accounting function addresses received from the
HSS in the outgoing
18

message. The accounting function addresses identify on
-
line, and off
-
line charging entities
in the home
19

network
.

It is implementation dependent how IMS related entities such as P
-
CSCF

in the visited network
20

get the local
AAA

addresses

i
n the case that the P
-
CSCF is located in the visited network
.
If this message is
21

sent outside the
mobile
network, S
-
CSCF shall include Inter Operator Identifier (IOI)
that identifies the
22

home network
into the message. IOI is
globally

unique

identifier for
using inter operator accounting
23

purposes.
The response to the outgoing message may contain a separate IOI that identifies the home
24

network of the called party. The S
-
CSCF shall retain either IOI in the message when contacting the
25

Application Servers. The S
-
CSCF will receive ICN accounting information from subsequent requests and
26

responses, the S
-
CSCF shall store these parameters and shall remove them from the outgoing message if
27

this message is sent to the terminating UE's home network or the originating UE
's visited network. The ICN
28

accounting information may be sent to application servers.

29

In a session terminating case, when receiving an incoming initial request, this request will carry the ICID
30

generated by the originating UE's P
-
CSCF; the S
-
CSCF shall st
ore the ICID for this session and handle this
31

request based on filter criteria. After processing this request the S
-
CSCF shall include the ICID and the
32

accounting function addresses received from the HSS in the outgoing message. The accounting function
33

add
resses identify on
-
line and off
-
line accounting entities
in the home network
. IOI may be received from
34

another network or is inserted by the MGCF to identify the originating PSTN/PLMN.
If
IOI is received at
35

the S
-
CSCF
,
the
S
-
CSCF shall store the IOI
value
for the network that sent the request. The response to the
36

incoming message may contain a separate IOI that identifies the home network of the S
-
CSCF. The S
-
37



X.S0013
-
003
-
B v1.0

15


CSCF shall retain either IOI in the message when contacting the Application Servers. Afterwards, th
e S
-
1

CSCF shall

remove

the IOI of the

requesting network
from the message
before sending the message

further
within
2

the
network.
The S
-
CSCF will receive ICN accounting information from subsequent requests and responses,
3

the S
-
CSCF shall store these paramete
rs and removes them from the outgoing message if this message is
4

sent to the terminating UE's visited network or the originating UE's home network. The ICN accounting
5

information may be sent to application servers.

6

For detailed information on transporting
accounting parameters between IMS entities using SIP, see [5].

7

6.9

Description of subscriber data

8

6.9.1

Application Server subscription information

9

The Application Server Subscription Information is the set of all Filter Criteria that are stored within the

10

HSS for service profile for a specific user.
This information shall be sent by the HSS to the S
-
CSCF via the
11

Cx Interface during registration. More than one set of Filter Criteria may be sent during registration if
12

implicitly registered public user identi
ties belong to different service profiles. Filter Criteria shall also be
13

sent after registration via the Cx interface when requested, as specified in [8].

14

6.9.2

Filter Criteria

15

This clause defines the contents of the Filter Criteria. This information is pa
rt of the Application Server
16

Subscription Information. For further information about the XML modeling see [8].

17

Filtering is done for initial SIP request messages only.

18

The S
-
CSCF shall apply filter criteria to determine the need to forward SIP requests to
Application Servers.
19

These filter criteria will be downloaded from the HSS.

20

Initial Filter Criteria (iFC)

are stored in the HSS as part of the user profile and are downloaded to the S
-
21

CSCF upon user registration, or upon a terminating initial request for a
n unregistered user if unavailable.
22

They represent a provisioned subscription of a user to an application. After downloading the User Profile
23

from the HSS, the S
-
CSCF assesses the filter criteria. Initial Filter Criteria are valid throughout the
24

registrati
on lifetime of a user or until the User Profile is changed.

25

Subsequent Filter Criteria (sFC) are

not used in this version of this specification.

26

6.9.2.1

Application Server address

27

Address to be used to access the Application Server for a particular subscri
ber.

28

6.9.2.2

Default handling

29

The default handling procedure indicates whether to abandon matching of lower priority triggers and
to
30

release
the
dialogue
,
or to continue the dialogue and trigger matching
.

31

6.9.2.3

Trigger point

32

Trigger Points are the inform
ation the S
-
CSCF receives from the HSS that defines the relevant SPTs for a
33

particular application. They define the subset of initial SIP requests received by the S
-
CSCF that should be
34

sent or proxied to a particular application server. When the S
-
CSCF rec
eives an initial SIP request, it
35

evaluates the filter criteria one by one. If the initial SIP request matches the filter criteria, the S
-
CSCF
36

proxies the SIP request to the corresponding SIP

AS/OSA SCS.

37

6.9.2.4

iFC Priority

38

If there are multiple initial Fi
lter Criteria assigned for one subscriber, the priority shall describe the order in
39

which the S
-
CSCF shall assess them, and then contact the Application Servers when the SIP request
40

matches the initial filter criteria. In this case, the S
-
CSCF shall intera
ct with the application server
41

associated with the initial matching filter criteria, starting from the filter criteria which has the highest
42

priority.

43

X.S
0013
-
003
-
B v1.0

16


6.9.2.5

Service Information

1

Service Information is transparent information, and is not processed by the H
SS or the S
-
CSCF. Service
2

Information is optionally part of an initial Filter Criteria. If it is available from the initial Filter Criteria the
3

S
-
CSCF shall include it into the body of the SIP request which is sent from the S
-
CSCF to the AS to which
4

the in
itial Filter Criteria is pointing to. Service Information is only included by the S
-
CSCF in REGISTER
5

requests where the S
-
CSCF acts as a UAC.

6


7

6.9.3

Authentication data

8

This clause defines the Authentication Data. This data shall be sent by the HSS to the
S
-
CSCF via the Cx
9

Interface during registration.

10

For the handling of authentication data, see [11].

11

7

Functional requirements of HSS

12

7.1

Subscriber data related storage requirements for HSS

13

HSS stores information required by:

14

-

S
-
CSCFs (downloaded via Cx i
nterface). Data model and abstract syntax notation are described in
15

[8];

16

-

Application Servers (downloaded via Sh interface). Signalling flow and message contents are
17

described in [18].

18

The service related data shall be transparent to HSS, this requires th
e HSS has some means to differentiate
19

the source of the request for the data, therefore, the HSS can respond with the data the request asks for.

20

7.2

Interfaces defined for HSS

21

7.2.1

HSS


CSCF (Cx) interface

22

This interface is used to send subscriber data
to the S
-
CSCF, including Filter Criteria (and their priority);
23

which indicates which SIP requests should be proxied to which Application Servers.

24

The protocol used between the HSS and CSCF (Cx Interface) is specified in [8] and [17].

25

7.2.2

HSS
-

Applicatio
n Server (Sh) interface

26

The Sh interface is between the HSS and the SIP Application Servers and the OSA SCS and may be used
27

for transferring User Profile

information
such as user service related information or user location

28

information,
or charging
functio
n
addresses
.

Requirements for the Sh interface are specified in [3]
.

29

The protocol used between the HSS and AS (Sh Interface) is specified in [18] and [19].

30

7.2.3


Void

31

7.2.4

Void

32

7.3

Procedures during IP multimedia registration

33

These procedures are describ
ed in [8].

34

7.4

Procedures during IP multimedia sessions

35

These procedures are described in [8].

36



X.S0013
-
003
-
B v1.0

17


8

Functional requirements of the MRFC

1

8.1

Functionality of the MRFC

2

8.1.1

Overview of MRFC Functionality

3

The functionality of the MRFC is defined in [3]. These
clauses describe how an Application Server may
4

interact with a MRFC. In some cases a UE may interact directly with the MRFC; however these cases are
5

outside the scope of this specification and only the cases of Application Server control for service provis
ion
6

are considered here. In all cases of Application Server control, all session control requests that are passed
7

between the Application Server and the MRFC are sent via the S
-
CSCF using the ISC interface and the
8

interface of the Mr reference point.

9

MRFC
addresses are made known via peer
-
to
-
peer arrangements within the IM CN subsystem.

10

Figure 8.1.1.1 describes the relationship of the Application Server with the S
-
CSCF and MRFC.

11


12

Figure 8.1.1.1: Relationship of MRFC and MRFP wi
th S
-
CSCF, and Application Servers

13

8.1.2

Tones and announcements

14

An Application Server is in control of the tone/announcement selection and is aware of MRFC capabilities.

15

The MRFC accepts INVITE requests sent from an Application Server, via the S
-
CSCF, for

the purpose of
16

applying tones and announcements. The INVITE sent to the MRFC will contain sufficient information to
17

play the appropriate tone or announcement.

18

The MRFC shall support both the offer/answer as defined in IETF RFC 3264 [15] and the offer/answ
er
19

with preconditions models for SDP negotiation with the AS. However, the offer/answer model for SDP
20

negotiation between the AS/S
-
CSCF and the MRFC is sufficient for applying tones and announcements.
21

The MRFC should always grant the requests from the AS (
unless there is a resource problem). The receipt
22

of the ACK at the MRFC triggers the playing of the tone or announcement.

23

The tone or announcement should end when a BYE is received. Alternatively, an expiration time may have
24

been specified from the AS with
in the SDP of the INVITE request. In this case, the MRFC may terminate
25

the media on its own and generate and BYE request towards the AS. A tone or announcement may also
26

have a pre
-
determined play time (e.g., confirmation tone), and so there may not be a ne
ed for the AS to
27

send a request to stop it or to include the play time in the request.

28

See annex B for a call flow example of playing an announcement for a mobile originated call.

29

X.S
0013
-
003
-
B v1.0

18


8.1.3

Ad hoc conferences (multiparty calls)

1

An Application Server can contro
l an Ad Hoc conference (multiparty call) and is aware of MRFC
2

capabilities.

3

The MRFC accepts INVITE requests sent from an Application Server, via the S
-
CSCF, for the purpose of
4

managing ad hoc conferences. The INVITE sent to the MRFC shall contain sufficie
nt information to
5

initiate, add and remove parties from the conference. Re
-
INVITE requests can also be sent for managing
6

floor control and for parties to leave and rejoin the media path.

7

The MRFC shall support both the offer/answer as defined in IETF RFC 3
264 [15] and the offer/answer
8

with preconditions models for SDP negotiation with the AS. However, the offer/answer model for SDP
9

negotiation between the AS/S
-
CSCF and the MRFC is sufficient for managing ad hoc conferences. The
10

MRFC should always grant the
requests from the AS (unless there is a resource problem). The MRFC will
11

reserve the requested local resources and return the appropriate resource identifiers in the 200 response.

12

See annex B for a call flow example of an Ad Hoc Conference (Multiparty Call
).

13

8.1.4

Transcoding

14

An Application Server can control a transcoding session and is aware of MRFC capabilities.

15

The MRFC accepts INVITE requests sent from an Application Server, via the S
-
CSCF, for the purpose of
16

transcoding. The INVITE sent to the MRFC sh
all contain sufficient information to associate the two
17

sessions that require transcoding.

18

The MRFC shall support both the offer/answer as defined in IETF RFC 3264 [15] and the offer/answer
19

with preconditions models for SDP negotiation with the AS. Either
may be necessary for SDP negotiation
20

between the AS/S
-
CSCF and the MRFC. The MRFC should always grant the requests from the AS (unless
21

there is a resource problem).

22

For the offer/answer model, the MRFC responds to the INVITE request with a 200 response ind
icating the
23

selected media in the SDP. The MRFC will also reserve the requested local resources at that time and
24

return the appropriate resource identifiers in the 200 response.

25

For the offer/answer with preconditions model, the MRFC responds to the INVITE

request with a 183
26

response indicating the list of codecs supported by the MRFC. When the PRACK is received indicating the
27

selected media in the SDP, the MRFC will reserve the requested local resources at that time and return the
28

appropriate resource iden
tifiers in the 200

response.

29

See annex B for call flow examples of providing transcoding.

30

8.2

Interfaces defined for MRFC

31

8.2.1

MRFC


S
-
CSCF (Mr) interface

32

The protocol used between MRFC and S
-
CSCF is based on Session Initiation Protocol, which is specifi
ed
33

in [5].

34



X.S0013
-
003
-
B v1.0

19


9

Generic
IP multimedia session handling

for SIP Application
1

Servers

2

9.1

Architecture

3

This clause describes the functional architecture needed to support interactions between the S
-
CSCF in the
4

IP Multimedia Subsystem and the Application Server(s
).
This clause relates to the generic behaviour of SIP
5

Application Servers, which since SIP is the ISC interface protocol shall be considered to apply to all
6

application servers, (which also includes the SIP behaviour of the OSA SCS). The detailed models f
or
7

service provision are described in the clauses below. These models shall apply to the SIP behaviour of the
8

OSA SCS and all the Application Servers.

9


10


11

Figure 9.1.1:
Application Server functional model

12

Figure 9.1.1 identifi
es the components of a functional model of the AS.

13

NOTE:

These components are defined only as a model of the expected behaviour of the AS on the
14

ISC interface and are not intended to define or constrain the actual implementation.

15

The components include
the AS
-
ILCM, the AS
-
OLCM and the Application Logic. The AS
-
ILCM shall
16

store transaction state, and may optionally store session state depending on the specific service being
17

executed. The AS
-
ILCM interfaces to the S
-
CSCF (ILCM) for an incoming leg.

18

The AS
-
OLCM shall store transaction state, and may optionally store session state depending on the
19

specific service being executed. The AS
-
OLCM interfaces to the S
-
CSCF (OLCM) for an outgoing leg.

20

The Application Logic provides the service(s) and interacts betwee
n the AS
-
ILCM and AS
-
OLCM.

21

X.S
0013
-
003
-
B v1.0

20


The Application Server can access the HSS via the Sh interface to access subscriber related data specific to
1

the service or application including the address of the S
-
CSCF.

2

9.1.1

Modes of operation between Application Server and

S
-
CSCF

3

An Application Server can utilize five basic modes of operation for processing SIP Requests. Services can
4

be built using combinations of these five modes of operation between the Application Server and the S
-
5

CSCF. An application Server can transit
ion from one mode of operation to another during the lifetime of a
6

multimedia session it is managing.

7

9.1.1.1

Application Server acting as terminating UA, or redirect server

8


9

Figure 9.1.1.1.1: Application Server acting as termina
ting UA, or redirect server

10

In this mode of operation the incoming SIP Request is proxied by the S
-
CSCF to the Application Server,
11

which then acts as either a UA or Redirect Server as specified in IETF RFC 3261 [6].

12

9.1.1.2

Application Server acting as ori
ginating UA

13


14

Figure 9.1.1.2.1: Application Server acting as originating UA

15

In this mode of operation the Application Server acts as a UA as specified in IETF RFC 3261 [6] and
16

generates a SIP Request which it sends to the S
-
CSCF
which then proxies it towards the destination.

17



X.S0013
-
003
-
B v1.0

21


9.1.1.3

Application Server acting as a SIP proxy

1


2

Figure 9.1.1.3.1: Application Server acting as a SIP proxy

3

In this mode of operation the incoming SIP Request is proxied by the S
-
C
SCF to the Application Server
4

which then acts as a proxy as specified in IETF RFC 3261 [6] proxying the request back to the S
-
CSCF
5

which then proxies it towards the destination. During the proxy operation the Application Server can add,
6

remove or modify th
e header contents contained in the SIP request according to the Proxy rules specified in
7

IETF RFC 3261 [6].

8

9.1.1.4

Application Server performing third party call control/ B2BUA mode

9

The AS performing 3rd party call control acts as a B2BUA. There are several kinds

of 3rd party call
10

control, for example:

11

-

Routeing B2BUA: an AS receives a request from the S
-
CSCF, terminates it and generates a new
12

request, which is based on the received request.

13


14


15


16

Figure 9.1.1.4.1: Application Server perfo
rming third party call control acting as a routeing
17

B2BUA

18

In this mode of operation the incoming SIP Request is proxied by the S
-
CSCF to the Application Server
19

which then generates a new SIP request for a different SIP dialog which it sends to the S
-
CSCF w
hich then
20

X.S
0013
-
003
-
B v1.0

22


proxies it towards the destination. In this mode the Application Server behaves as a B2BUA for the
1

multiple SIP dialogs as specified in IETF

RFC 3261 [6].

2


3

-

Initiating B2BUA: an AS initiates two requests, which are logically connected together a
t the AS.

4


5

Figure 9.1.1.4.2: Application Server performing third party call control acting as an
6

initiating B2BUA

7

In this mode of operation the Application Server initiates two requests with different SIP dialogs.
8

The Applicatio
n Server is responsible for correlating the two dialogs. These requests are proxied
9

through the S