-
CSCF which then proxies them towards the destination. In this mode the Application
10

Server behaves as a B2BUA for the multiple SIP dialogs as specified in IETF

RFC 3261 [6].

11


12

9.1.1.5

Application Server not involved or no longer involved

13


14

Figure 9.1.1.5.1: A SIP leg is passed through the S
-
CSCF without Application Server
15

involvement

16

In this mode of operation the Application Server was
either never involved in the SIP session signalling or
17

has determined to be no longer involved. The incoming SIP Request is proxied by the S
-
CSCF towards the
18

destination. The Application Server can maintain itself in the SIP session signalling path by inse
rting itself
19

in a Record
-
Route Header as specified in IETF RFC 3261 [6]. If the Application Server does not insert
20

itself in a Record Route header then this mode of operation shall be used for all subsequent requests related
21

to this SIP dialog.

22



X.S0013
-
003
-
B v1.0

23


9.2

Interfa
ces defined for
a SIP Application Server

1

9.2.1

S
-
CSCF


Application Server (ISC) interface

2

This interface can be used by the Application Server to control an IP Multimedia session via a S
-
CSCF.
3

Transactions between the S
-
CSCF and the Application Server

on

this interface are initiated either as a result
4

of the S
-
CSCF proxying a SIP request to the Application Server or by the Application Server initiating by
5

generating and sending a SIP request to the S
-
CSCF. This interface is based on SIP.

6

9.2.2

Application

Server


HSS (Sh) interface

7

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

for transferring User Profile information.

9

9.3

Description of Application Server related subscriber data

10

9.3.1

Application ser
ver subscription information

11

This clause defines the general contents of the Subscription Information that may be required by the
12

Application Server. The AS shall obtain this information from the HSS via the Sh interface or by other
13

operator defined method
s. The subscription information may be retrieved during registration or at any other
14

time dependent on AS and service requirements.

15

9.3.1.1

Service key

16

The Service Key identifies to the Application Server the service logic that shall apply.

17

9.3.1.2

Service platfor
m trigger points (STP)

18

Service Platform Trigger Points (STP) are the points in the SIP signalling that instruct the Application
19

Server to trigger the service logic.

20

9.3.1.3

Service scripts

21

The Application Server can utilize a call processing script (e.g.

in CGI, CPL, Java


Servlets, or another
22

proprietary language), which may be obtained from the HSS via the Sh interface or by other operator
23

defined methods.

24

NOTE:

Java


is the trade name of a product supplied by Sun Microsystems. This information is
25

given for the convenie
nce of users of the present document and does not constitute an
26

endorsement by 3GPP2 of the product named. Equivalent products may be used if they can
27

be shown to lead to the same results.

28

9.4

Procedures for multimedia session handling with a SIP based
29

App
lication Server

30

9.4.1

Application Server handling of mobile originating requests

31

The functional mode of application server is shown in figure 9.1.1.

32

For an originating request, the AS
-
ILCM may interact with the application logic reporting call state
33

inform
ation. Depending on the service that is being provided, the application logic may instruct the AS
-
34

OLCM to modify the request if needed (e g. by inserting itself in the

Record
-
Route etc). After processing
35

the request the AS
-
OLCM may send this request back t
o the S
-
CSCF.

36

When the AS acts as a B2BUA, the application server shall maintain and correlate the multiple dialogues
37

that it creates. It shall be responsible for correlating the dialogue identifiers and shall decide when to
38

translate a message from one di
alog to the other, or when to perform other functions based on the
39

instruction from the application logic.

40

X.S
0013
-
003
-
B v1.0

24


9.4.2

Application Server handling of mobile terminating requests

1

The handling of mobile terminating requests is similar with the handling of mobile o
riginating requests as
2

defined in clause 9.4.1.

3

9.4.3

Application Server handling of SIP registration

4

When the user is registered with the network and has been assigned a S
-
CSCF, the application servers,
5

which are interested to know about the user registra
tion events, should get a third party registration request
6

generated by the S
-
CSCF.

When the application server receives the request, the A
pplication
S
erver

may
7

perform a service triggered by a REGISTER.
If the application server doesn't support this mecha
nism, it
8

shall send back an error response to the S
-
CSCF. If the application server supports this mechanism, it shall
9

treat this request as a notification from the network about the user's registration event and extract the
10

important information from this
request.

11

The application server may, depending on the Filter Criteria receive REGISTER requests indicating re
-
12

registration or deregistration events from the S
-
CSCF, so that the application server can update or release
13

user's registration information.

14

The i
mportant information carried in the third party registration request are, the public user identity, the S
-
15

CSCF address, and the expiration time.

16


17

Application Servers can also subscribe to the S
-
CSCF Registration Event Package after receiving the third
18

par
ty registration request. After subscribing to the event package with the S
-
CSCF, the application will
19

expect to receive the notifications from the S
-
CSCF, which may carry the user's implicitly registered public
20

user identities, the user terminal’s current
capabilities and the user's registration event information.

21


22

The application server can also obtain the user's implicitly registered public identities by accessing the HSS
23

via Sh interface.

24

An application server will require knowledge of a user's IMS subsc
ription information if they are to
25

correctly apply services. This information can be provided to the application server in two ways, either:

26

a)

Manually by provisioning. This is outside of the scope of this specification.

27

b)

Automatically from the HSS via the Sh

interface.

28

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

29

9.4.4

Application Server handling of IP multimedia session release requests

30

9.4.4.1

Session release request terminated at the Application Server

31

When the application server receives a se
ssion release request, if the application server is acting as a user
32

agent or a B2BUA, it shall send 200 OK to the entity that initiated the session release request.

33


34

Figure 9.4.4.1.1: Release request terminated at the Applicati
on Server

35



X.S0013
-
003
-
B v1.0

25


9.4.4.2

Session release request proxied by the Application Server

1

When receiving a session release request, the application server may proxy the release request based on the
2

route information in that request. This handling is typically used when
the application server is in proxy
3

mode.

4


5

Figure 9.4.4.2.1: Release request proxied by the Application Server

6

9.4.4.3

Session release request initiated by the Application Server

7

If needed, the application server may initiate rel
ease requests to the entities involved in the dialogs the
8

application server manages. Application servers may initiate release requests in either user agent or
9

B2BUA mode.

10


11

Figure 9.4.4.3.1: Release request initiated by the App
lication Server

12

9.4.5

Application server handling of IP multimedia accounting

13

If an application server receives a third party REGISTER from the S
-
CSCF carrying the ICID, IOI and
14

accounting function addresses, the application server may store these paramete
rs for accounting purposes.

15

In an originating case, when processing an incoming initial request carrying the ICID, IOI,
ICN accounting
16

information

and accounting function addresses for this session, the application server shall pass these
17

parameters in the

outgoing message and may store the parameters for accounting purposes.

18

In a terminating case, when processing an incoming initial request carrying the ICID, IOI,
ICN accounting
19

information

and accounting function addresses for this session, the applicatio
n server shall pass these
20

parameters in the outgoing message and may store the parameters for accounting purposes.

21

X.S
0013
-
003
-
B v1.0

26


When the application server is acting as an originating user agent as described in clause
9.1.1.2 and initiates
1

a session or a standalone tra
nsaction, it shall generate ICID itself.
The application server may retrieve the
2

charging addresses on Sh interface
.

3

When the
c
onflict

occurs
between the charging function address(es) received over the ISC interface and
4

those received over the Sh interface
,
the address(es) received over the ISC interface should take
5

precedence.

6

NOTE:

The use of the Sh interface to retrieve charging function addresses is not intended as a
7

general
-
purpose alternative to receiving charging function addresses from the ISC inter
faces.
8

Rather, it is meant to address a special case where the AS needs to interact with the charging
9

system before initiating a request to a
user

when the AS has not received the third party
10

REGISTER

for that
user
.

11

For detailed information on transporting

accounting parameters between IMS entities using SIP, see [5].

12

10

Void

13


14

11

IP multimedia session handling

with an OSA
-
Service
15

Capability Server

16

This clause describes the functional architecture needed to support interactions with the S
-
CSCF in the IP
17

Mult
imedia Subsystem and the OSA
-
SCS. The OSA
-
Service Capability Server is a SIP Application Server
18

which interfaces SIP to the OSA framework. The generic SIP Application Server behaviour of the OSA
-
19

SCS is specified in clause 9 of the present document.

20

The det
ailed OSA
-
SCS procedures for IMS Application Server are specified in [7].

21

1
2.

IP multimedia session handling

with an
Charging

Server

22

This clause describes the functional architecture needed to support interactions with the S
-
CSCF in the IP
23

Multimedia Subsy
stem and Charging Server.

The
Charging Server

is a
specific
SIP Application Server that
24

performs the role of online charging mechanism for the Event Charging Function (ECF) and Session
25

Charging Function (SCF).

26

The detailed procedures for
Charging
Server ar
e specified in [
20
]

and [
21
]
.

27



X.S0013
-
003
-
B v1.0

27


Annex A (informative):

1

Scalability and deployment considerations for IP
2

multimedia service provision

3

This Annex is intended to guide the reader in deployment and real life issues.

4

This specification has provided a set of tools

for the application developer and the application integrator to
5

util
ize

in order to develop and deploy applications and provide services for the IP multimedia core network
6

subsystem. However, practical deployments will need to consider certain scalability

issues with the use or
7

misuse of some of the tools specified in this specification.

8

The architecture allows for any number of Application Servers to be connected to any number of S
-
CSCFs
9

and any number of Application Servers to be involved in the initiati
on of a multimedia session. A
10

scalability issue may arise if there are a large number of S
-
CSCF and AS in a network.

11

Consideration should be given to the signalling propagation delays introduced when many Application
12

Servers add themselves to the route to
provide originating and terminating services for the calling and
13

called parties.

14

A
SIP Application Server may act as gateway function

by
forward
ing
an incoming request to external ASs
15

beyond the IM CN subsy
s
tem
. An e
xternal ASs will also send response
s
to
IM CN subsy
s
tem via
a
SIP AS
16

gateway
.
These other Application Servers can be
located externally
to

th
e

home network, and
use the SIP
17

Application Server as a
gateway
to
the ISC interface. The interface between the SIP A
pplication
S
erver

18

acting as a gateway,

and
other Application Servers
is outside the scope of the present document
.

19

There is another case where the external AS is connected with S
-
CSCF

(or I
-
CSCF) via public ISP
20

networks depending on the operators desire for network configuration hiding. S
-
CSCF

or entities outside
21

the

S
-
CSCF may perform the interworking function.

22

Care must also be taken to the priority and order of contact of multiple Application Servers during a session
23

in order to account for feature interaction issues.

24

25


26

Figure A.1: Example hierarchical architecture for Application Servers

27

Figure A.1 depicts a possible solution that shows how a S
-
CSCF (S
-
CSCF1 S
-
CSCF3) could be connected
28

to a single AS (SIP AS1), while another (S
-
CSCF2) could be connected to more tha
n one, in this case it is
29

two (SIP AS1, SIP AS2). All S
-
CSCF will be connected to the HSS via Cx. A SIP AS may be connected to
30

X.S
0013
-
003
-
B v1.0

28


the HSS via Sh. SIP ASs may be connected to the IP network, which could allow them to contact
1

Application Servers (e.g., either S
IP ASs, or Other ASs).

2

Care should be taken to the transaction delays resulting of a high number of S
-
CSCF and ASs on the
3

session signalling path.

4

A possible application of this architecture is described below (see figure A.2).

5

While some applications need

to discover the registration of a user on an event driven basis, many
6

applications do not. For many applications an access to the HSS or other database to obtain the address of
7

the S
-
CSCF that serves a user is sufficient to contact and initiate a session
to that user, and others (such as
8

basic call feature servers) do not require to be informed of the registration state or necessarily even need to
9

know the identity of the user. It is therefore possible that the filter criteria are set in such a way that

S
-
10

CSCF3 does not forward or notify SIP AS 3 of REGISTER requests. SIP AS3 would then need to
11

determine registration status via other means (i.e. via IP network) not specified.

12

The number of Application Servers receiving REGISTER requests (i.e., SIP AS3) from

an individual S
-
13

CSCF should be minim
ize
d.

14

15


16

Figure A.2: Use of a hierarchy in a practical architecture for Application Servers

17



X.S0013
-
003
-
B v1.0

29


Annex B (informative):

1

Information flows for example services

2

This annex contains some informative e
xample information flows that show the possible flow of
3

information for some example services.

These examples are intended only to help aid the understanding of
4

the behaviour of the S
-
CSCF, MRFC and Application Servers for service provision for the IM CN
5

s
ubsystem and are not intended to recommend or specify how to create such services, (indeed the examples
6

given may not even be a good idea for a practical implementation).

7

The following modes of operation are shown in these examples:

8

-

Third Party Registra
tion to Application Server



Clause B.3.2;

9

-

Application Server in Originating UA mode



Clause B.3.2;

10

-

Application Server in Redirect mode




Clause B.1.3;

11

-

Application Server in Terminating UA mode



Clause B.3.1;

12

-

Application Server in Proxy mode




Clause B.1.4;

13

-

Application Server in Third Party Call Control/B2BUA mode

Clauses B.2.1, B.2.2, and B.2.3;

14

-

Application Server with no involvement



Clause B.1.4.

15


16

B.1

Call forwarding example

17

B.1.1

Call forwarding through Application Servers

18

Figure B.1.1.
1 presents the network configuration for a call
-
forwarding scenario. Some interfaces between
19

nodes have been omitted purely for clarity. In this configuration, the UE1 originates a call to the UE2. The
20

UE2 is subscribed to a Call Forwarding (CF) service ba
sed on the Calling Line Identification (CLI). T
he
21

CF service logic resides in an Application Server interfacing to the IM CN subsystem via the ISC interface.
22

The Application Server is programmed to detect all incoming calls or terminating sessions with UE1
's CLI
23

and to instruct the S
-
CSCF to forward the calls/sessions to another destination, UE3, either directly or via
24

the UE1. These two session forwarding scenarios are shown by the red and blue coloured flows. When the
25

session redirection is carried out di
rectly by the S
-
CSCF of the UE2, the network may notify the UE1 of its
26

call/session redirection.

27

As shown in figure B.1.1.1, the Application Server may be

a SIP AS, or an OSA AS. The latter Application
28

Server interfaces the S
-
CSCF via the OSA SCS gateway.

29

X.S
0013
-
003
-
B v1.0

30



1


2

Figure B.1.1.1: Network configuration for the call forwarding examples

3

In this configuration, the originating UE1 and the terminating UE3 are assumed to be in their respective
4

home network. The UE2, not shown in figure B.1.
1.1, may be either at its home network or roaming in a
5

visited network.

6

The CF feature is invoked based on the detection of the originating party's CLI "pre
-
activated" for call
7

forwarding. Upon invocation of the CFonCLI feature, the call will be forwarded

to a pre
-
specified
8

destination. These two steps and a few underlying assumptions are briefly described below:

9

B.1.1.1

Service activation and programming

10

The UE2 activates its CFonCLI service and programs it with a Forward
-
to Number which is UE3's number,
11

conditioning it to the originating party's line identity, CLI.

12

B.1.1.2

Service invocation and control

13

The UE1 makes a call to the UE2. The CFonCLI is invoked and the call is forwarded to the
14

UE3 following a "Session Redirection" that is initiated by either

the S
-
CSCF or the UE1.

15

NOTE:


[3] lists six redirection procedures as follows:

16

NOTE 1:

Session Redirection initiated by S
-
CSCF to IMS;

17

NOTE 2:

Session Redirection initiated by S
-
CSCF to CS
-
domain;

18

NOTE 3:

Session Redirection initiated by S
-
CSCF to genera
l endpoint;

19

NOTE 4:

Session Redirection initiated by P
-
CSCF;

20

NOTE 5:

Session Redirection initiated by UE;

21



X.S0013
-
003
-
B v1.0

31


NOTE 6:

Session Redirection initiated after Bearer Establishment.

1

B.1.2

Assumptions

2

For the CFonCLI service invocation and service control procedure,
the following are assumed to hold:

3

-

Normal case scenario, showing successful cases only;

4

-

Subscriber data of all three UE1, UE2 and UE3 are stored in their respective HSS;

5

-

All call/session control for the UE1, UE2, and UE3 is done in their respective h
ome network S
-
6

CSCF;

7

-

The UE2 has already subscribed to the CFonCLI service with a service provider operating an
8

Application Server where the service control logic resides;

9

-

The pre
-
selected numbers (e.g., UE3) to which the originated calls are forwarded,

are stored by the
10

CFonCLI service control logic upon activation of the feature by the UE2.

11

B.1.3

UE redirect based call flows

12


13

14


15

Figure B.1.3.1: CFonCLI information flows with UE re
-
direct

16

Figure B.1.3.1 presents the informat
ion flow diagram for the invocation and control of the CFonCLI service
17

based on the configuration of figure B.1.1.1.

18

X.S
0013
-
003
-
B v1.0

32


The UE1 initiates a call to UE2. The CFonCLI service logic is invoked in the Application Server when the
1

S
-
CSCF for UE2 detects that servic
e invocation is required. The call is forwarded to the UE3 by the UE1
2

according to the "Session Redirection initiated by UE" procedure. The UE3 accepts the (forwarded) call. A
3

detailed description for each flow is given below:

4


1) The S
-
CSCF of UE1 receive
s a SIP invite request form UE1.

5


2) The I
-
CSCF of the UE2 receives a SIP INVITE request form the S
-
CSCF of the originating user,
6

UE1. UE1's CLI is included in this INVITE request.

7


3) The I
-
CSCF of the UE2 queries the HSS to obtain the S
-
CSCF of the UE2.

8


4) The HSS returns the S
-
CSCF location.

9


5) The I
-
CSCF forwards the INVITE to the S
-
CSCF of UE2.

10


6) Based on the information obtained from the UE2 Service Profile (during registration), the S
-
11

CSCF of the UE2 detects that the criteria for certain pre
-
def
ined triggers are met. The INVITE
12

request is forwarded to the Application Server. The service logic is invoked in the Application
13

Server.

14


7) Based on the outcome of the execution of the service logic, the Application Server instructs the S
-
15

CSCF to REDIREC
T the session to UE3. The behaviour of the Application Server follows the
16

description of a 'redirect server'. It sends the 302 Move Temporary response with UE3 as the redirect
17

address to UE1. The Application Server plays no further part in the session esta
blishment.

18


8) S
-
CSCF of UE2 sends ACK back to the Application Server to acknowledge the receiving of the
19

302 response.

20


9) S
-
CSCF of UE2 forwards the 302 Move Temporary to the I
-
CSCF of UE2.

21


10) The I
-
CSCF of UE2 forwards the 302 Move Temporary to the

S
-
CSCF of UE1.

22


11) The S
-
CSCF of UE1 sends ACK to acknowledge the receiving of the 302 Move Temporary.

23


12) The I
-
CSCF of UE2 forwards the ACK to the S
-
CSCF of UE2.

24


13) The S
-
CSCF of UE1 forwards the 302 Move Temporary response to the next downstream h
op.

25


14) The S
-
CSCF of UE1 receives the ACK for that 302 response from the downstream hop.

26


15) The UE1 re
-
issues an INVITE with UE3 as the destination.

27


16) The originating S
-
CSCF redirects the SIP INVITE request to the UE3's home network.

28


17) Bearer e
stablishment & call setup between from the UE1 to the UE3 is
performed following the
29

procedure described in the basic call flow sections for originating, inter
-
network and terminating
30

segments.

31

B.1.4

S
-
CSCF based redirect call flows

32

Figure B.1.4.1 presents

the information flow diagram for the invocation and control of the CFonCLI service
33

based on the configuration of figure B.1.1.1, where redirection is made by the S
-
CSCF after instructions
34

from the service logic in the Application Servers.

35



X.S0013
-
003
-
B v1.0

33


1


2

Figure B.1. 4.1: CFonCLI information flow with S
-
CSCF redirect

3

The UE1 (located in the originating visited network) makes a call to UE2. The CFonCLI is invoked and the
4

CFonCLI service logic is executed by an application residing in the Appl
ication Server.

5

The call is forwarded to the UE3 by the S
-
CSCF of UE2 according to the "Session Redirection" instructed
6

by the Application Server. The S
-
CSCF sends a SIP 181Call Is Being Forwarded to UE1 and a SIP Invite
7

request 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


(7a, 7b, 7c and 7d) The Application Server notifies the UE1 that the call is being fo
rwarded, by
10

sending a 181 Call Is Being Forwarded response.

11


8) The service logic forwards the INVITE request back to S
-
CSCF modifies the destination address
12

by inserting the identity of the UE3. The Application Server is in SIP proxy mode.

13


9) The S
-
CSCF

of UE2 forwards the modified INVITE request it received from the Application
14

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

X.S
0013
-
003
-
B v1.0

34



(13a, 13b, 13c, 13d, 13e, 13f, 13g, 13h and 13g) The UE3 accepts the incoming call and sends an
1

183 Session Progress back to UE1.

2


14) Bearer establishment & call setup between from the UE1 to the UE
3 is performed following the
3

procedure described in the basic call flow clauses for originating, inter
-
network and terminating
4

segments.

5

B.2

Announcement, conferencing and transcoding examples
6

using MRFC

7

B.2.1

Example information flow for a mobile originat
ed IP multimedia session that
8

results in playing an announcement

9

The following diagram shows an example of playing an announcement for a mobile originated IP
10

multimedia session. An AS (acting as B2BUA) performs third party call control with the MRFC, where

the
11

S
-
CSCF is in the signalling path.

12

The "[x]" notation in the diagram is an indicator of a unique SIP dialog. The "dot" notation on the AS line
13

indicates B2BUA actions are taking place along with AS service logic. The 100 Trying responses are not
14

shown
in the diagram, but it is assumed that 100 Trying is sent in response to each INVITE request.

15

The B2BUA AS interacts with the UE as usual to establish the dialog. The B2BUA AS interacts with the
16

MRFC using a third party control model to establish the dialo
g. The B2BUA AS manages the interactions
17

between the two dialogs.

18

The offer/answer model as defined in IETF RFC 3264 [15] is used for SDP negotiation between the AS/S
-
19

CSCF and the MRFC.

The MRFC should always grant the requests from the AS (unless there is

a resource
20

problem). The MRFC responds to the INVITE request with a 200 response indicating the selected codec in
21

the SDP. The MRFC will also reserve the requested local resources at that time. The selected codec is
22

included by the B2BUA AS in the 183 res
ponse to the UE. The receipt of the ACK at the MRFC triggers
23

the playing of the tone or announcement.

24



X.S0013
-
003
-
B v1.0

35



1

Figure B.2.1.
1
: Tones and announcements call flow

2

Notes for figure B.2.1.1:

3


1) INVITE request is received at the S
-
CSCF [C
all
-
ID 1].

4


2) INVITE request is forwarded to an AS, based on the filter criteria.

5

X.S
0013
-
003
-
B v1.0

36



3) The AS service logic determines to proceed with the call.

1


4) New INVITE request is sent towards destination, via the S
-
CSCF, to establish a new dialog [Call
-
2

ID 2].

3


5)

S
-
CSCF experiences a failure, such as not being able to determine the next hop for the SIP URI.

4


6) Session failure returned to the AS.

5


7) ACK returned to complete this dialog [Call
-
ID 2].

6


8) The AS service logic determines to play an announcement to t
he calling party.

7


9) New INVITE request is sent to the MRFC, via the S
-
CSCF, to establish a new dialog for playing
8

an announcement [Call
-
ID 3].

Sufficient information is included to specify the details for the
9

announcement.

10


10) S
-
CSCF relays INVITE to t
he MRFC.

11


11) The MRFC allocates the requested resource and returns 200 OK, with SDP
-
A indicating
12

selected media.

13


12) S
-
CSCF relays 200 OK to the AS.

14


13)
-

30) The B2BUA AS manages the dialog for Call
-
ID 1 as normal, with the SDP
-
A supplied
15

from the MRF
C. The MRFC is instructed to play the announcement using the ACK request at flow
16

26 for Call
-
ID 3.

17

B.2.2

Example information flow for a mobile originated IP multimedia ad hoc
18

conferencing session (multiparty call)

19

The following diagram shows an example of
an ad hoc conference (multiparty call). An AS (acting as
20

B2BUA) performs third party call control with the MRFC, where the S
-
CSCF is in the signalling path.

21

The "[x]" notation in the diagram is an indicator of a unique SIP dialog. The "dot" notation on the

AS line
22

indicates B2BUA actions are taking place along with AS service logic. The 100 Trying responses are not
23

shown in the diagram, but it is assumed that 100 Trying is sent in response to each INVITE request.

24

The Application Server is in control of the
ad hoc conference, is aware of the MRFC capabilities and is also
25

operating as a B2BUA performing third party call control.

26

An INVITE request is generated from UE
-
1 indicating a desire to start a multiparty call (ad hoc conference)
27

by taking the existing se
ssions, between UE
-
1 to UE
-
2 and UE
-
1 to UE
-
3, and bringing them together.

The
28

AS uses third party call control to request the conference facilities from the MRFC.

A separate dialog is
29

established from the AS to the MRFC for each of the three parties (UE
-
1
, UE
-
2, UE
-
3).

New dialogs are
30

also established between the AS and each of the UE endpoints. The media from each UE is connected at the
31

conferencing resource at the MRFP. The first INVITE request to the MRFC should receive a response that
32

includes the conf
erence identifier. The same conference identifier will be used for subsequent INVITE
33

requests to add or drop parties to the conference.

34

The offer/answer model as defined in IETF RFC 3264 [15] is used for SDP negotiation between the AS/S
-
35

CSCF and the MRFC.

The MRFC should always grant the requests from the AS (unless there is a resource
36

problem).

The MRFC responds to the INVITE request with a 200 response indicating the selected media in
37

the SDP.

The MRFC will also reserve the requested local resources at th
at time and return the appropriate
38

resource identifiers in the 200 response.

39



X.S0013
-
003
-
B v1.0

37


1


2

Figure B.2.2.1: Ad hoc conference call flow

3

Notes for figure B.2.2.1:

4


1) INVITE request received at S
-
CSCF from UE
-
1 indicating desire to start ad ho
c 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.

7


3) INVITE forwarded to AS.

8

X.S
0013
-
003
-
B v1.0

38



4) AS performs service logic and allows attempt to start ad hoc conference.

1


5
-
8) New INVITE request sent
to MRFC to initiate multiparty call, get conference identifier and
2

prepare dialog for UE
-
2 [Call
-
ID 2].

3


9
-
13) Re
-
INVITE sent to UE
-
2 to establish dialog between AS and UE
-
2 [Call
-
ID 3].

4


14
-
17) ACK sent for Call
-
ID 2 and Call
-
ID 3.

5


18
-
21) New INVITE requ
est sent to MRFC using the same conference identifier and prepare dialog
6

for UE
-
3 [Call
-
ID 4].

7


22
-
26) Re
-
INVITE sent to UE
-
3 to establish dialog between AS and UE
-
3 [Call
-
ID 5].

8


27
-
30) ACK sent for Call
-
ID 4 and Call
-
ID 5.

9


31
-
34) New INVITE request sent

to MRFC using the same conference identifier and prepare dialog
10

for UE
-
1 [Call
-
ID 6].

11


35
-
36) 200 OK returned to UE
-
1 with SDP.

12


37) The session is established.

13


38
-
41) ACK sent for Call
-
ID 1 and Call
-
ID 6.

14

B.2.3

Example information flows for a mobile ori
ginated IP multimedia session that
15

requires transcoding

16

The two figures B.2.3.1 and B.2.3.2 that follow illustrate the MRFC providing transcoding for a mobile
17

originated session, where the MRFC is receiving directions from the AS operating as a B2BUA.

18

The
"[x]" notation in the diagram is an indicator of a unique SIP dialog. The "dot" notation on the AS line
19

indicates B2BUA actions are taking place along with AS service logic. The 100 Trying responses are not
20

shown in the diagram, but it is assumed that 100
Trying is sent in response to each INVITE request.

21

The B2BUA AS interacts with the originating UE as usual to establish the dialog. The B2BUA AS interacts
22

with the MRFC using a third party control model to establish the dialog with the called party after r
eceiving
23

the initial failure indication. The B2BUA AS manages the interactions between the two dialogs.

24

An INVITE request is generated from a UE. A 606 "Not Acceptable" response is received from the called
25

party. The AS uses third party call control to req
uest transcoding facilities from the MRFC.

A separate
26

dialog is established from the AS to the MRFC for each of the two parties.

New dialogs are also established
27

between the AS and each of the UE endpoints. The media from each UE is connected at the transc
oding
28

resource at the MRFP.

29

In the first figure B.2.3.1 below, the called party returns an indication of an acceptable codec.

For this case,
30

the request to the MRFC will include the appropriate codec for the called party and the offer/answer model
31

as defin
ed in IETF RFC 3264 [15] with the MRFC is used. In figure B.2.3.2 below, the called party does
32

not indicate any SDP, which means that more steps will be required on the subsequent INVITE request to
33

set up transcoding with the MRFC. An INVITE without SDP is

sent to the MRFC to get the list of codecs it
34

supports.

The AS then sends that list of codecs in the new INVITE that it sends to the called party. The
35

B2BUA function of the AS matches up the responses.

36

The offer/answer model is used for SDP negotiation be
tween the AS/S
-
CSCF and the MRFC. The MRFC
37

should always grant the requests from the AS (unless there is a resource problem). The MRFC responds to
38

the INVITE request with a 200 response indicating the selected codec in the SDP. The MRFC will also
39

reserve t
he requested local resources at that time. The selected codec is included by the B2BUA AS in the
40

183 response to the UE. The receipt of the ACK at the MRFC triggers the playing of the tone or
41

announcement.

42



X.S0013
-
003
-
B v1.0

39



1

Figure B.2.3.1: Trans
coding call flow (called party indicates codec)

2

X.S
0013
-
003
-
B v1.0

40


Notes for figure B.2.3.1:

1


1) INVITE request received at S
-
CSCF from UE [Call
-
ID 1].

2


2) 100 Trying returned.

3


3) INVITE forwarded to an AS, based on filter criteria.

4


4) AS service logic determines to pr
oceed with the call.

5


5) New INVITE request is sent towards destination, via the S
-
CSCF, to establish a new dialog [Call
-
6

ID 2].

7


6) S
-
CSCF forwards the INVITE.

8


7) Called UA returns 606 Not Acceptable in response to the INVITE request. Included in the
9

resp
onse is an indicator that the offered codec is not acceptable plus information on what codec
10

would be acceptable.

11


8) An ACK is sent to the called UA to complete the dialog for Call
-
ID 2.

12


9) 606 response is forwarded to the AS.

13


10) AS service logic dete
rmines that there is an MRFC that can perform the transcoding.

14


11) ACK sent to S
-
CSCF to complete the dialog for Call
-
ID 2.

15


12
-
17) New INVITE request sent to MRFC to establish transcoding for called UA [Call
-
ID 3].

16


18
-
25) New INVITE request sent to cal
led UA to establish session between UA and MRF [Call
-
ID
17

4].

18


26
-
29) New INVITE request sent to MRFC to establish transcoding for calling UE [Call
-
ID 5].

19


30
-
53) Normal call establishment procedures from here on, with B2BUA AS performing the
20

appropriate sig
nalling translations between the associated dialogs.

21



X.S0013
-
003
-
B v1.0

41



1

Figure B.2.3.2: Transcoding call flow (called party codec negotiated)

2

Notes for figure B.2.3.2:

3


1) INVITE request received at S
-
CSCF from UE [Call
-
ID 1].

4


2) 100 Trying retu
rned.

5


3) INVITE forwarded to an AS, based on filter criteria.

6


4) AS service logic determines to proceed with the call.

7


5) New INVITE request is sent towards destination, via the S
-
CSCF, to establish a new dialog [Call
-
8

ID 2].

9


6) S
-
CSCF forwards the INVI
TE.

10


7) Called UA returns 606 Not Acceptable in response to the INVITE request. Included in the
11

response is an indicator that the offered codec is not acceptable but there is no information on what
12

codec would be acceptable (no SDP).

13


8) ACK sent to called

UA to complete the dialog for Call
-
ID 2.

14


9) 606 response is forwarded to the AS.

15


10) AS service logic determines that there is an MRFC that can perform the transcoding.

16

X.S
0013
-
003
-
B v1.0

42



11) ACK sent to S
-
CSCF to complete the dialog for Call
-
ID 2.

1


12
-
15) New INVITE req
uest sent to MRFC to establish transcoding for called UA and to get the list
2

codecs supported by the MRF [Call
-
ID 3].

3


16
-
19) New INVITE request sent to called UA with SDP for all codecs supported by the MRF to
4

establish session between UA and MRF [Call
-
ID

4]. UA returns SDP with acceptable codecs.

5


20
-
27) A new offer with the codecs provided by the UA is sent in PRACK and the 200 OK response
6

indicates the selected codec.

7


28
-
31) Acknowledgements sent to complete Call
-
ID 3.

8

Call establishment procedures fro
m here on are common with the previous transcoding call flow.

9

B.3

Example information flows for a voicemail service

10

B.3.1

User out of coverage message recording

11

Figure B.3.1.1 shows a possible scenario of an Application Server, which acting as a terminatin
g UA
12

performs the function of a Voicemail Server in order to terminate a call and record a message on behalf of a
13

UE that is out of coverage or powered off.

14

A S
-
CSCF is forwarded the initial INVITE destined for a UE that is not currently IMS registered. Th
e
15

Default Filter Criteria in the S
-
CSCF indicates that for the case of an unregistered user the INVITE should
16

be forwarded to the Voicemail and Announcement Server.

17

Upon receiving the INVITE request the Voicemail and Announcement Server determines that the

18

destination UE has subscribed to the Voicemail Service (possibly by downloading some subscriber profile
19

information via the Sh interface). The Voicemail and Announcement Server therefore in addition to playing
20

an announcement to inform the caller that the

called party is either powered off or out of coverage also
21

informs the caller that he may leave a message for the called party.

22

The calling party leaves a message for the called party and then hangs up the call by sending a BYE.

23



X.S0013
-
003
-
B v1.0

43


1


2

Figure B.3.1.1: Voicemail server records messages

3

Notes for figure B.3.1.1:

4

NOTE:

For simplicity the 100 Trying response returned or received by the S
-
CSCF in response to
5

requests is omitted from figure B.3.1.1.

6


1) INVITE request destined for an unregi
stered user is received at the S
-
CSCF.

7


2) Based on trigger point of the initial Filter Criteria S
-
CSCF proxies the INVITE request to the AS
8

(Voicemail Server).

9


3
-
4) The AS starts the voicemail application and responds with a 183 Session Progress containi
ng
10

SDP which is proxied back to the caller by the S
-
CSCF.

11

X.S
0013
-
003
-
B v1.0

44



5
-
8) The caller responds with a PRACK containing SDP, which the S
-
CSCF proxies to the AS and
1

the AS responds with a 200 OK containing SDP which the S
-
CSCF proxies back to the caller.

2


QOS establish
ment and resource reservation takes place.

3


10
-
13) After completing resource reservation the caller sends a UPDATE containing SDP which is
4

proxied by the S
-
CSCF to the AS which responds with a 200 OK containing SDP which is proxied
5

back to the caller by th
e S
-
CSCF.

6


14
-
15) The AS then sends a 200 OK to the initial INVITE which the S
-
CSCF proxies to the caller.

7


16
-
17) The caller returns an ACK to the 200 OK.

8


18) The AS plays an announcement using the session established indicating that the caller is
9

powere
d off but that the caller may leave a message.

10


19) The caller leaves a message using the session established.

11


20
-
21) The caller hangs up by sending a BYE which the S
-
CSCF proxies to the AS.

12


22
-
23) The AS responds with a 200 OK, which the S
-
CSCF proxies
back to the caller.

13

B.3.2

User IMS registers voice mail service plays back messages

14

Figure B.3.2.1 shows the scenario when the UE that has subscribed to a voicemail service with a feature
15

enabled that contacts the user upon registration informing him of an
y recorded messages.

16

The Filter Criteria downloaded by the S
-
CSCF indicates that a third party REGISTER request should be
17

sent to the Voicemail Server. Upon receiving the third party registration of the UE, the Voicemail Server
18

acting as an originating UA
contacts the UE by sending an INVITE request to inform him that he has
19

voicemail messages recorded while he was not registered.

20

The user listens to the messages played back by the voicemail server, (only streaming class QOS is required
21

for this session) an
d then terminates the session with a BYE.

22



X.S0013
-
003
-
B v1.0

45


1


2

Figure B.3.2.1: Upon registration voicemail server replays messages

3

X.S
0013
-
003
-
B v1.0

46


Notes for figure B.3.2.1:

1

NOTE:

For simplicity the 100 Trying response returned or received by the S
-
CSCF in response

to
2

requests is omitted from figure B.3.2.1.

3


1
-
4) The UE sends a REGISTER request to the S
-
CSCF which authenticates with a 401
4

Unauthorized response challenge with the authentication response being supplied in a second
5

REGISTER request. The registration c
ompletes with a 200 OK from the S
-
CSCF to the UE.

6


5
-
6) The S
-
CSCF downloads Filter Criteria for the UE from the HSS which indicates the S
-
CSCF
7

should send a third party REGISTER request on behalf of the UE to an AS that performs a
8

voicemail service. The A
S responds to the REGISTER request with a 200 OK.

9


7
-

8) The AS downloads subscriber data for the subscriber (possibly from the HSS via the Sh
10

interface) that indicates that the subscriber has enabled a feature that has the voicemail application
11

contact th
e subscriber upon registration to deliver recorded messages. The AS sends an INVITE
12

request containing SDP for the UE to the S
-
CSCF which proxies it to the UE.

13


9
-
10) The UE responds with 183 Session Progress containing SDP which the S
-
CSCF proxies to the
14

AS.

15


11
-
14) The AS sends a PRACK, which the S
-
CSCF proxies to the UE and the UE respond with a
16

200 OK which the S
-
CSCF proxies to the AS.

17


15) QOS establishment and resource reservation takes place.

18


16
-

19) The AS sends an UPDATE, which the S
-
CSCF proxies

to the UE and the UE responds with
19

a 200 OK which the S
-
CSCF proxies to the AS.

20


20
-
21) The UE sends a 180 Ringing indicating that it is alerting the user which the S
-
CSCF proxies
21

to the AS.

22


22
-
25) The AS to indicate receipt of the 180 response sends a P
RACK which the S
-
CSCF proxies to
23

the UE and the UE responds with a 200 OK which the S
-
CSCF proxies to the AS.

24


26
-
27) When the subscriber answers the UE sends a 200 OK to the initial INVITE which the S
-
25

CSCF proxies to the AS.

26


28
-
29) The AS acknowledges th
e 200 OK with an ACK which the S
-
CSCF proxies to the UE.

27


30) The AS plays an announcement indicating the number of messages stored and then plays back
28

the messages to the UE using the session established.

29


31
-
32) The UE hangs up by sending a BYE, which th
e 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.

31



X.S0013
-
003
-
B v1.0

47


Annex C (informative):

1

Example for Initial filter criteria triggering

2

This example applies for call originating and terminating procedure both. But
we assume this is a call
3

originating procedure. User has registered with the network. Its filter criteria and addresses of the assigned
4

application servers have been downloaded to its S
-
CSCF during registration via Cx interface. Also, the
5

application serv
er specific data may have been downloaded via the Sh interface to the application server
6

during registration.

7


8

Figure C.1: Initial Filter Criteria Triggering Example

9

There is a flow example in figure C.1:

10

In this example, two app
lication servers are assigned to provide additional services to a subscriber and they
11

are showed as AS1 and AS2 in this example.

12

1.

User initiates a SIP session by sending a SIP initial request to its S
-
CSCF.

13

2.

On receiving this request, the S
-
CSCF evalua
tes the SPTs and checks if they match the initial filter
14

criteria X for AS1. If they match, the S
-
CSCF forwards this request to AS1.

15

3.

The AS1 performs any needed service logic based on the Service and sends the SIP request possibly
16

with service related
modification back to the S
-
CSCF.

17

4.a

On receiving the request from the AS, the S
-
CSCF evaluates

the SPTs and checks if they match the
18

initial filter criteria Y for AS2. If they match the S
-
CSCF forwards the request to the associated
19

Application Server AS2.

20

X.S
0013
-
003
-
B v1.0

48


4.b

If the request doesn't match any further filter criteria, the S
-
CSCF forwards this request to the next
1

hop based on the route decision.

2

5.a

The AS2 performs any needed service logic based on the Service and sends the SIP request possibly
3

with service
related modification back to the S
-
CSCF.

4

6.a

The S
-
CSCF checks the request sent by AS2 and finds that no initial criteria is matched, then the S
-
5

CSCF forwards this request to next hop based on the route decision.

6


7