CX Diameter Int

X.S0013-006-B v1.
1
2
3
All-IP Core Network Multimedia Domain

Cx Interface Based on the Diameter Protocol;
Protocol Details
Contents
61 Scope.......................................................................................................................................1
72 References...............................................................................................................................2
8 2.1
Normative references.....................................................................................................2
93 Definitions, symbols and abbreviations...................................................................................3
10 3.1
Definitions.....................................................................................................................3
11 3.2
Abbreviations.................................................................................................................3
124 General....................................................................................................................................4
135 Use of the Diameter base protocol...........................................................................................5
14 5.1
Securing Diameter messages..........................................................................................5
15 5.2
Accounting functionality...............................................................................................5
16 5.3
Use of sessions...............................................................................................................5
17 5.4
Transport protocol..........................................................................................................5
18 5.5
Routing considerations...................................................................................................5
19 5.6
Advertising application support.....................................................................................6
206 Diameter application for Cx interface......................................................................................7
21 6.1
Command-Code values..................................................................................................7
22
6.1.1
User-Authorization-Request (UAR) command..........................................................8
23
6.1.2
User-Authorization-Answer (UAA) command..........................................................8
24
6.1.3
Server-Assignment-Request (SAR) command...........................................................9
25
6.1.4
Server-Assignment-Answer (SAA) command...........................................................9
26
6.1.5
Location-Info-Request (LIR) command..................................................................10
27
6.1.6
Location-Info-Answer (LIA) command...................................................................10
28
6.1.7
Multimedia-Auth-Request (MAR) command..........................................................10
29
6.1.8
Multimedia-Auth-Answer (MAA) command...........................................................11
30
6.1.9
Registration-Termination-Request (RTR) command................................................11
31
6.1.10
Registration-Termination-Answer (RTA) command................................................12
32
6.1.11
Push-Profile-Request (PPR) command....................................................................12
33
6.1.12
Push-Profile-Answer (PPA) command.....................................................................13
34 6.2
Experimental-Result-Code AVP values........................................................................13
35
6.2.1
Success....................................................................................................................13
36
6.2.1.1
DIAMETER_FIRST_REGISTRATION (2001).............................................13
37
6.2.1.2
DIAMETER_SUBSEQUENT_REGISTRATION (2002)..............................13
1X.S0013-006-B v1.0
6.2.1.3
DIAMETER_UNREGISTERED_SERVICE (2003)......................................14
6.2.1.4
DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED (2004)............14
6.2.2
Permanent failures...................................................................................................14
6.2.2.1
DIAMETER_ERROR_USER_UNKNOWN (5001)......................................14
6.2.2.2
DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002).....................14
6.2.2.3
DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003).................14
6.2.2.4
DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004).....................14
6.2.2.5
DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED (5005)......14
6.2.2.6
DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED (5006)........14
10
6.2.2.7
DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (5007)............................14
11
6.2.2.8
DIAMETER_ERROR_TOO_MUCH_DATA (5008).....................................14
12
6.2.2.9
DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA (5009)...............15
13
6.2.2.10
Void................................................................................................................15
14
6.2.2.11
DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011)........................15
15 6.3
AVPs............................................................................................................................15
16
6.3.1
Visited-Network-Identifier AVP..............................................................................16
17
6.3.2
Public-Identity AVP.................................................................................................16
18
6.3.3
Server-Name AVP....................................................................................................16
19
6.3.4
Server-Capabilities AVP..........................................................................................16
20
6.3.5
Mandatory-Capability AVP......................................................................................17
21
6.3.6
Optional-Capability AVP.........................................................................................17
22
6.3.7
User-Data AVP........................................................................................................17
23
6.3.8
SIP-Number-Auth-Items AVP..................................................................................17
24
6.3.9
SIP-Authentication-Scheme AVP............................................................................17
25
6.3.10
SIP-Authenticate AVP.............................................................................................17
26
6.3.11
SIP-Authorization AVP............................................................................................17
27
6.3.12
SIP-Authentication-Context AVP............................................................................17
28
6.3.13
SIP-Auth-Data-Item AVP........................................................................................18
29
6.3.14
SIP-Item-Number AVP............................................................................................18
30
6.3.15
Server-Assignment-Type AVP.................................................................................18
31
6.3.16
Deregistration-Reason AVP.....................................................................................19
32
6.3.17
Reason-Code AVP..................................................................................................19
33
6.3.18
Reason-Info AVP....................................................................................................19
34
6.3.19
Charging-Information AVP......................................................................................19
ii
X.S0013-006-B v1.0
6.3.20
Primary-Event-Charging-Function-Name AVP........................................................20
6.3.21
Secondary-Event-Charging-Function-Name AVP....................................................20
6.3.22
Primary-Charging-Collection-Function-Name AVP................................................20
6.3.23
Secondary-Charging-Collection-Function-Name AVP............................................20
6.3.24
User-Authorization-Type AVP.................................................................................20
6.3.25
Void.........................................................................................................................20
6.3.26
User-Data-Already-Available AVP..........................................................................20
6.3.27
Confidentiality-Key AVP.........................................................................................21
6.3.28
Integrity-Key AVP...................................................................................................21
10
6.3.29
Supported-Features AVP..........................................................................................21
11
6.3.30
Feature-List-ID AVP................................................................................................21
12
6.3.31
Feature-List AVP.....................................................................................................21
13
6.3.32
Supported-Applications AVP...................................................................................21
14
6.3.33
Associated-Identities AVP.......................................................................................22
15 6.4
Use of namespaces.......................................................................................................22
16
6.4.1
AVP codes................................................................................................................22
17
6.4.2
Experimental-Result-Code AVP values....................................................................22
18
6.4.3
Command Code values............................................................................................22
19
6.4.4
Application-ID value...............................................................................................22
207 Special requirements.............................................................................................................23

21 7.1
Version control.............................................................................................................23
22
7.1.1
Defining a new feature.............................................................................................23
23
7.1.2
Changing the version of the interface......................................................................24
24 7.2
Supported features.......................................................................................................25
25
7.2.1
Dynamic discovery of supported features................................................................25
26 7.3
Interface versions.........................................................................................................26
27
7.3.1
Discovery of supported interface versions...............................................................26
28
iii
1X.S0013-006-B v1.0
1Foreword
2(This foreword is not part of this document).
3This document was prepared by 3GPP2 TSG-X.
4This document contains major modifications from the previous revision.
5This document is part of the series of documents X.S0013.
6This document contains portions of material copied from 3GPP document number TS 29.229 6.a.0. The
7copyright on the 3GPP document is owned by the Organizational Partners of 3GPP (ARIB - Association of
8Radio Industries and Businesses, Japan; CCSA China Communications Standards Association, China;
9ETSI - European Telecommunications Standards Institute; ATSI; TTA - Telecommunications Technology
10Association, Korea; and TTC Telecommunication Technology Committee, Japan), which have granted
11license for reproduction and for use by 3GPP2 and its Organizational Partners.
12
13Revision History
Revision
Changes
Date
0, v1.0
Initial Publication
December 2003
0, v2.0
Version Update
July 2005
A, v1.0
Release A
November 2005
B, v1.0
Release B
December 2007
14
iv
X.S0013-006-B v1.0
11
Scope
2The present document defines a transport protocol for use in the IP multimedia (IM) Core Network (CN)
3subsystem based on Diameter.
4The present document is applicable to: The Cx interface between the I-CSCF/S-CSCF and the HSS.
5Whenever it is possible, this document specifies the requirements for this protocol by reference to
6specifications produced by the IETF within the scope of Diameter. Where this is not possible, extensions to
7Diameter are defined within this document.
1X.S0013-006-B v1.0
12
References
22.1
Normative references
3The following standards and documents contain provisions which, through reference in this text, constitute
4provisions of this document. At the time of publication, the editions indicated were valid. All standards are
5subject to revision, and parties to agreements based on this Standard are encouraged to investigate the
6possibility of applying the most recent editions of the standards indicated below. ANSI and TIA maintain
7registers of currently valid national standards published by them.
8
9
References are either specific (identified by date of publication, edition number, version number,
etc.) or non-specific.
10
For a specific reference, subsequent revisions do not apply.
11
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP2
document, a non-specific reference implicitly refers to the latest version of that document in the
same Release as the present document.
12
13
14 [1]
15
16 [2]
3GPP2 X.S0013-005-B, IP Multimedia (IM) Subsystem Cx interface; signalling flows and message
contents
3GPP2 S.R0086-A, 3GPP2 IMS Security Framework
17[3]
IETF RFC 3261, "SIP: Session Initiation Protocol"
18[4]
IETF RFC 2396, Uniform Resource Identifiers (URI): generic syntax
19[5]
IETF RFC 2960, Stream Control Transmission Protocol
20[6]
IETF RFC 3588, Diameter Base Protocol
21[7]
IETF RFC 2234, Augmented BNF for syntax specifications
22[8]
IETF RFC 3966, URLs for Telephone Calls
23[9]
void
24[10]
IETF RFC 3309, SCTP Checksum Change
25[11]
3GPP2 X.S0013-011-B, Sh Interface based on the Diameter protocol; protocol details
26[12]
27
IETF RFC 3589, Diameter Command Codes for Third Generation Partnership Project (3GPP)
Release 5
X.S0013-006-B v1.0
13
Definitions, symbols and abbreviations
23.1
Definitions
3Refer to [6] for the definitions of some terms used in this document.
4For the purposes of the present document, the following terms and definitions apply.
5Attribute-Value Pair: see [6], it corresponds to an Information Element in a Diameter message.
6Diameter Multimedia client: a client that implements the Diameter Multimedia application. The client is
7one of the communicating Diameter peers that usually initiate transactions. Examples in MMD are the I8CSCF and S-CSCF.
9Diameter Multimedia server: a server that implements the Diameter Multimedia application. A Diameter
10Multimedia server that also supported the NASREQ and MobileIP applications would be referred to as a
11Diameter server. An example of a Diameter Multimedia server in MMD is the HSS.
12Registration: SIP-registration.
13Server: SIP-server.
14User data: user profile data.
153.2
Abbreviations
16For the purposes of the present document, the following abbreviations apply:
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
ABNF
AVP
CN
CSCF
HSS
IANA
I-CSCF
IETF
IMS
RFC
S-CSCF
SCTP
SIP
SLF
UCS
URL
UTF
Augmented Backus-Naur Form

Attribute-Value Pair
Core Network
Call Session Control Function
Home Subscriber Server
Internet Assigned Numbers Authority
Interrogating CSCF
Internet Engineering Task Force
IP Multimedia Subsystem
Request For Comments
Serving CSCF
Stream Control Transport Protocol
Session Initiation Protocol
Server Locator Function
Universal Character Set
Uniform Resource Locator
UCS Transformation Formats
1X.S0013-006-B v1.0
14
General
2The Diameter Base Protocol as specified in [6] shall apply except as modified by the defined support of the
3methods and the defined support of the commands and AVPs, result and event codes specified in clause 6 of
4this specification. Unless otherwise specified, the procedures (including error handling and unrecognised
5information handling) are unmodified.
X.S0013-006-B v1.0
15
Use of the Diameter base protocol
2With the clarifications listed in the following subclauses, the Diameter Base Protocol defined by IETF [6]
3shall apply.
45.1
Securing Diameter messages
5For secure transport of Diameter messages, see [2].
65.2
Accounting functionality
7Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not
8used on the Cx interface.
95.3
Use of sessions
10Both between the I-CSCF and the HSS and between the S-CSCF and the HSS, Diameter sessions are
11implicitly terminated. An implicitly terminated session is one for which the server does not maintain state
12information. The client does not need to send any re-authorization or session termination requests to the
13server.
14The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation
15of implicitly terminated sessions.
16The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value
17NO_STATE_MAINTAINED (1), as described in [6]. As a consequence, the server does not maintain any
18state information about this session and the client does not need to send any session termination request.
19Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or
20responses.
215.4
Transport protocol
22Diameter messages over the Cx interface shall make use of SCTP [5] and shall utilise the new SCTP
23checksum method specified in RFC 3309 [10].
245.5
Routing considerations
25This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.
26If an I-CSCF or S-CSCF knows the address/name of the HSS for a certain user, both the Destination-Realm
27and Destination-Host AVPs shall be present in the request. Otherwise, only the Destination-Realm AVP
28shall be present and the command shall be routed to the next Diameter node based on the Diameter routing
29table in the client.
30If an SLF acting as an enhanced Diameter redirect agent returns the address or the destination HSS (using
31Redirect-Host AVP), the redirected request to the HSS shall include both Destination-Realm and
32Destination-Host AVPs. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all
33requests initiated by an I-CSCF or an S-CSCF. The S-CSCF shall store the address of the HSS for each user,
34after a first request sent to the redirector function.
35If an SLF acting as a Diameter Proxy is used to proxy requests to an HSS, the Origin-Realm AVP value in
36the response shall be set to the HSS Realm and the Origin-Host AVP in the response shall be set to the HSS
37name. The SLF shall not modify the Origin-Realm AVP and Origin-Host AVP in the Cx_response from the
38HSS. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated
39by an I-CSCF or an S-CSCF. The S-CSCF shall store the address of the HSS for each user, after a first
40request sent to the SLF acting as a Diameter Proxy.
1X.S0013-006-B v1.0
1Requests initiated by the HSS towards an S-CSCF shall include both Destination-Host and Destination2Realm AVPs. The HSS obtains the Destination-Host AVP to use in requests towards an S-CSCF, from the
3Origin-Host AVP received in previous requests from the S-CSCF. Consequently, the Destination-Host AVP
4is declared as mandatory in the ABNF for all requests initiated by the HSS.
5Destination-Realm AVP is declared as mandatory in the ABNF for all requests.
65.6
Advertising application support
7The HSS, S-CSCF and I-CSCF shall advertise support of the Diameter Multimedia Application by
8including the value of the application identifier (see chapter 6) in the Auth-Application-Id AVP within the
9Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities10Exchange-Answer commands.
11The vendor identifier value of 3GPP (10415) shall be included in the Supported-Vendor-Id AVP of the
12Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP
13within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and
14Capabilities-Exchange-Answer commands.
15
16
17
Note: The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-ExchangeAnswer commands that is not included in the Vendor-Specific-Application-Id AVPs as
described above shall indicate the manufacturer of the Diameter node as per [6].
X.S0013-006-B v1.0
16
Diameter application for Cx interface
2This clause specifies a Diameter application that allows a Diameter Multimedia server and a Diameter
3Multimedia client:
4-
to exchange location information
5-
to authorize a user to access the IMS
6-
to exchange authentication information
7-
to download and handle changes in the user data stored in the server
8The Cx interface protocol is defined as an IETF vendor specific Diameter application, where the vendor is
93GPP. The vendor identifier assigned by IANA to 3GPP ( http://www.iana.org/assignments/enterprise10numbers) is 10415.
11The Diameter application identifier assigned to the Cx/Dx interface application is 16777216, allocated by
12IANA.
136.1
Command-Code values
14This section defines Command-Code values for this Diameter application.

15Every command is defined by means of the ABNF syntax [7], according to the rules in [6]. Whenever the
16definition and use of an AVP is not specified in this document, what is stated in [6] shall apply.
17The command codes for the Cx/Dx interface application are taken from the range allocated by IANA in [12]
18as assigned in this specification. For these commands, the Application-ID field shall be set to 16777216
19(application identifier of the Cx/Dx interface application, allocated by IANA).
20The following Command Codes are defined in this specification:
21
Table 6.1.1: Command-Code values

Command-Name
Abbreviation
Code
Section
User-Authorization-Request
UAR
300
6.1.1
User-Authorization-Answer
UAA
300
6.1.2
Server-Assignment-Request
SAR
301
6.1.3
Server-Assignment-Answer
SAA
301
6.1.4
Location-Info-Request
LIR
302
6.1.5
Location-Info-Answer
LIA
302
6.1.6
Multimedia-Auth-Request
MAR
303
6.1.7
Multimedia-Auth-Answer
MAA
303
6.1.8
Registration-TerminationRequest
RTR
304
6.1.9
Registration-TerminationAnswer
RTA
304
6.1.10
Push-Profile-Request
PPR
305
6.1.11
Push-Profile-Answer
PPA
305
6.1.12
22
1X.S0013-006-B v1.0
1NOTE: The Diameter Base Protocol RFC 3588 [6] requires that Answer type commands have a Result2Code AVP. However, in certain Answer commands an optional Experimental-Result AVP may be present.
3When the Experimental-Result AVP is present the Result-Code AVP is not required.
46.1.1 User-Authorization-Request (UAR) command
5The User-Authorization-Request (UAR) command, indicated by the Command-Code field set to 300 and
6the R bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter
7Multimedia server in order to request the authorization of the registration of a multimedia user.
8Message Format
9< User-Authorization-Request> ::= < Diameter Header: 300, REQ, PXY, 16777216 >
10
< Session-Id >
11
{ Vendor-Specific-Application-Id }
12
{ Auth-Session-State }
13
{ Origin-Host }
14
{ Origin-Realm }
15
[ Destination-Host ]
16
{ Destination-Realm }
17
{ User-Name }
18
*[ Supported-Features ]
19
{ Public-Identity }
20
{ Visited-Network-Identifier }
21
[ User-Authorization-Type ]
22
*[ AVP ]
23
*[ Proxy-Info ]
24
*[ Route-Record ]
25
266.1.2 User-Authorization-Answer (UAA) command
27The User-Authorization-Answer (UAA) command, indicated by the Command-Code field set to 300 and
28the R bit cleared in the Command Flags field, is sent by a server in response to the User-Authorization29Request command. Either the Result-Code AVP or the Experimental-Result AVP shall be present to indicate
30the disposition of the request. The Experimental-Result AVP (when present) may contain one of the values
31defined in section 6.2.
32Message Format
33< User-Authorization-Answer> ::=
34
35
36
37
38
39
< Diameter Header: 300, PXY, 16777216 >

< Session-Id >
[ Result-Code ] ; Required if Experimental-Result not present Otherwise not present.
[ Experimental-Result ] ; Required if Result-Code not present Otherwise not present.
40
41
42
43
44
45
46
47
48
49
{ Origin-Host }
{ Origin-Realm }
[ Server-Name ]
[ Server-Capabilities ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
X.S0013-006-B v1.0
16.1.3 Server-Assignment-Request (SAR) command

2The Server-Assignment-Request (SAR) command, indicated by the Command-Code field set to 301 and the
3R bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia
4server in order to request it to store the name of the server that is currently serving the user.
5Message Format
6<Server-Assignment-Request> ::= < Diameter Header: 301, REQ, PXY, 16777216 >
7
< Session-Id >
8
9
10
{ Origin-Host }
11
{ Origin-Realm }
12
13
14
[ User-Name ]
15
16
*[ Public-Identity ]
17
[ Server-Name ]
18
{ Server-Assignment-Type }
19
{ User-Data-Already-Available }
20
*[ AVP ]
21
*[ Proxy-Info ]
22
*[ Route-Record ]
236.1.4 Server-Assignment-Answer (SAA) command
24The Server-Assignment-Answer (SAA) command, indicated by the Command-Code field set to 301 and the
25R bit cleared in the Command Flags field, is sent by a server in response to the Server-Assignment26Request command. The Experimental-Result AVP may contain one of the values defined in section 6.2. If
27Result-Code or Experimental-Result does not inform about an error, the User-Data AVP shall contain the
28information that the S-CSCF needs to give service to the user. Either the Result-Code AVP or the
29Experimental-Result AVP shall be present to indicate the disposition of the request.
30Message Format
31<Server-Assignment-Answer> ::=
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
< Diameter Header: 301, PXY, 16777216 >

< Session-Id >
[ Result-Code ] ; Required if Experimental-Result not present Otherwise not present.
[ Experimental-Result ] ; Required if Result-Code not present Otherwise not present
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ User-Data ]
[ Charging-Information ]
[ Associated-Identities ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
1X.S0013-006-B v1.0
16.1.5 Location-Info-Request (LIR) command

2The Location-Info-Request (LIR) command, indicated by the Command-Code field set to 302 and the R
3bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia
4server in order to request name of the server that is currently serving the user.
5Message Format
6<Location-Info-Request> ::= < Diameter Header: 302, REQ, PXY, 16777216 >
7
< Session-Id >
8
9
10
{ Origin-Host }
11
{ Origin-Realm }
12
13
14
15
{ Public-Identity }
16
*[ AVP ]
17
*[ Proxy-Info ]
18
*[ Route-Record ]
196.1.6 Location-Info-Answer (LIA) command
20The Location-Info-Answer (LIA) command, indicated by the Command-Code field set to 302 and the R
21bit cleared in the Command Flags field, is sent by a server in response to the Location-Info-Request
22command. Either the Result-Code AVP or the Experimental-Result AVP shall be present to indicate the
23disposition of the request. The Experimental-Result AVP (when present) may contain one of the values
25Message Format
26<Location-Info-Answer> ::= < Diameter Header: 302, PXY, 16777216 >
27
< Session-Id >
28
29
[ Result-Code ] ; Required if Experimental-Result not present - Otherwise
30
not present.
31
[ Experimental-Result ] ; Required if Result-Code not present - Otherwise
32
not present
33
34
{ Origin-Host }
35
{ Origin-Realm }
36
37
[ Server-Name ]
38
[ Server-Capabilities ]
39
*[ AVP ]
40
*[ Failed-AVP ]
41
*[ Proxy-Info ]
42
*[ Route-Record ]
436.1.7 Multimedia-Auth-Request (MAR) command
44The Multimedia-Auth-Request (MAR) command, indicated by the Command-Code field set to 303 and the
45R bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia
46server in order to request security information.
47Message Format
48< Multimedia-Auth-Request > ::= < Diameter Header: 303, REQ, PXY, 16777216 >
49
< Session-Id >
10
X.S0013-006-B v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Public-Identity }
{ SIP-Auth-Data-Item }
{ SIP-Number-Auth-Items }
{ Server-Name }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
166.1.8 Multimedia-Auth-Answer (MAA) command

17The Multimedia-Auth-Answer (MAA) command, indicated by the Command-Code field set to 303 and the
18R bit cleared in the Command Flags field, is sent by a server in response to the Multimedia-Auth-Request
19command. Either the Result-Code AVP or the Experimental-Result AVP shall be present to indicate the
20disposition of the request. The Experimental-Result AVP (when present) may contain one of the values
22Message Format
23< Multimedia-Auth-Answer > ::= < Diameter Header: 303, PXY, 16777216 >
24
< Session-Id >
25
26
[ Result-Code ] ; Required if Experimental-Result not present 27
Otherwise not present.
28
[ Experimental-Result ] ; Required if Result-Code not present 29
Otherwise not present
30
31
{ Origin-Host }
32
{ Origin-Realm }
33
[ User-Name ]
34
35
[ Public-Identity ]
36
[ SIP-Number-Auth-Items ]
37
* [SIP-Auth-Data-Item ]
38
* [ AVP ]
39
*[ Failed-AVP ]
40
* [ Proxy-Info ]
41
* [ Route-Record ]
426.1.9 Registration-Termination-Request (RTR) command
43The Registration-Termination-Request (RTR) command, indicated by the Command-Code field set to 304
44and the R bit set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter
45Multimedia client in order to request the de-registration of a user.
46Message Format
47<Registration-Termination-Request> ::= < Diameter Header: 304, REQ, PXY, 16777216 >
48
< Session-Id >
49
50
51
{ Origin-Host }
11
1X.S0013-006-B v1.0
1
2
3
4
5
6
7
8
9
10
11
{ Origin-Realm }
{ Destination-Host }
{ User-Name }
*[ Public-Identity ]
{ Deregistration-Reason }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
126.1.10 Registration-Termination-Answer (RTA) command

13The Registration-Termination-Answer (RTA) command, indicated by the Command-Code field set to 304
14and the R bit cleared in the Command Flags field, is sent by a client in response to the Registration15Termination-Request command. Either the Result-Code AVP or the Experimental-Result AVP shall be
16present to indicate the disposition of the request. The Experimental-Result AVP (when present) may
17contain one of the values defined in section 6.2.
18Message Format
19<Registration-Termination-Answer> ::= < Diameter Header: 304, PXY, 16777216>
20
< Session-Id >
21
22
[Result-Code ]; Required if Experimental-Result not present 23
Otherwise not present.
24
[ Experimental-Result ]; Required if Result-Code not present 25
Otherwise not present
26
27
{ Origin-Host }
28
{ Origin-Realm }
29
30
31
*[ AVP ]
32
*[ Failed-AVP ]
33
*[ Proxy-Info ]
34
*[ Route-Record ]
356.1.11 Push-Profile-Request (PPR) command
36The Push-Profile-Request (PPR) command, indicated by the Command-Code field set to 305 and the R bit
37set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter Multimedia client in
38order to update the subscription data of a multimedia user in the Diameter Multimedia client whenever a
39modification has occurred in the subscription data that constitutes the data used by the client.
40Message Format
41< Push-Profile-Request > ::= < Diameter Header: 305, REQ, PXY, 16777216 >
42
< Session-Id >
43
44
45
{ Origin-Host }
46
{ Origin-Realm }
47
{ Destination-Host }
48
49
{ User-Name }
50
51
[ User-Data ]
12
X.S0013-006-B v1.0
[ Charging-Information ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
1
2
3
4
56.1.12 Push-Profile-Answer (PPA) command

6The Push-Profile-Answer (PPA) command, indicated by the Command-Code field set to 305 and the R bit
7cleared in the Command Flags field, is sent by a client in response to the Push-Profile-Request command.
8Either the Result-Code AVP or the Experimental-Result AVP shall be present to indicate the disposition of
9the request. The Experimental-Result AVP (when present)may contain one of the values defined in section
106.2.
11Message Format
12< Push-Profile-Answer > ::= < Diameter Header: 305, PXY, 16777216 >
13
< Session-Id >
14
15
[Result-Code ] ; Required if Experimental-Result not present - Otherwise not
16
present.
17
[ Experimental-Result ] ; Required if Result-Code not present - Otherwise not
18
present.
19
20
{ Origin-Host }
21
{ Origin-Realm }
22
23
*[ AVP ]
24
*[ Failed-AVP ]
25
*[ Proxy-Info ]
26
*[ Route-Record ]
276.2
Experimental-Result-Code AVP values
28This section defines new result code values that must be supported by all Diameter implementations that
29conform to this specification. When one of the result codes defined here is included in a response, it shall be
30inside a Experimental-Result AVP and Result-Code AVP shall be absent.
316.2.1 Success
32Result codes that fall within the Success category are used to inform a peer that a request has been
33successfully completed.
346.2.1.1
DIAMETER_FIRST_REGISTRATION (2001)
35 The HSS informs the I-CSCF that:
36
The user is authorized to register this public identity;
37
A S-CSCF shall be assigned to the user.
386.2.1.2
DIAMETER_SUBSEQUENT_REGISTRATION (2002)
40
The user is authorized to register this public identity;
41
A S-CSCF is already assigned and there is no need to select a new one.
13
1X.S0013-006-B v1.0
16.2.1.3
DIAMETER_UNREGISTERED_SERVICE (2003)
The public identity is not registered but has services related to unregistered state;
A S-CSCF shall be assigned to the user.
56.2.1.4
DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED (2004)
6The HSS informs to the S-CSCF that :
The de-registration is completed;
The S-CSCF name is not stored in the HSS.
96.2.2 Permanent failures

10Errors that fall within the Permanent Failures category are used to inform the peer that the request failed,
11and should not be attempted again.
126.2.2.1
DIAMETER_ERROR_USER_UNKNOWN (5001)
13A message was received for a user that is unknown.
146.2.2.2
DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002)
15A message was received with a public identity and a private identity for a user, and the server determines
16that the public identity does not correspond to the private identity.
176.2.2.3
DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003)
18A query for location information is received for a public identity that has not been registered before. The
19user to which this identity belongs cannot be given service in this situation.
206.2.2.4
DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004)
21The user is not allowed to roam in the visited network.
226.2.2.5
DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED (5005)
23The identity being registered has already a server assigned and the registration status does not allow that it
24is overwritten.
256.2.2.6
DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED (5006)
26The authentication scheme indicated in an authentication request is not supported.
276.2.2.7
DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (5007)
28The identity being registered has already the same server assigned and the registration status does not allow
29the server assignment type.
306.2.2.8
DIAMETER_ERROR_TOO_MUCH_DATA (5008)
31The volume of the data pushed to the receiving entity exceeds its capacity.
32NOTE: This error code is also used in [11].
14
X.S0013-006-B v1.0
16.2.2.9
DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA (5009)
2The S-CSCF informs HSS that the received subscription data contained information, which was not
3recognised or supported.
46.2.2.10
Void
56.2.2.11
DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011)
6A request application message was received indicating that the origin host requests that the command pair
7would be handled using a feature which is not supported by the destination host.
86.3
AVPs
9The following table describes the Diameter AVPs defined for the Cx interface protocol, their AVP Code
10values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-Id header of
11all AVPs defined in this specification shall be set to 3GPP (10415).
Table 6.3.1: Diameter Multimedia Application AVPs
12
AVP Flag rules

Attribute Name
AVP Section
Code defined
Value Type
Must May Should Must May Encr.

not
not
Visited-Network-Identifier
600
6.3.1
OctetString
M, V
No
Public-Identity
601
6.3.2
UTF8String
M, V
No
Server-Name
602
6.3.3
UTF8String
M,V
No
Server-Capabilities
603
6.3.4
Grouped
M, V
No
Mandatory-Capability
604
6.3.5
Unsigned32
M, V
No
Optional-Capability
605
6.3.6
Unsigned32
M, V
No
User-Data
606
6.3.7
OctetString
M, V
No
SIP-Number-Auth-Items
607
6.3.8
Unsigned32
M, V
No
SIP-Authentication-Scheme
608
6.3.9
UTF8String
M, V
No
SIP-Authenticate
609
6.3.10
OctetString
M, V
No
SIP-Authorization
610
6.3.11
OctetString
M, V
No
SIP-Authentication-Context
611
6.3.12
OctetString
M, V
No
SIP-Auth-Data-Item
612
6.3.13
Grouped
M, V
No
SIP-Item-Number
613
6.3.14
Unsigned32
M, V
No
Server-Assignment-Type
614
6.3.15
Enumerated
M, V
No
Deregistration-Reason
615
6.3.16
Grouped
M, V
No
Reason-Code
616
6.3.17
Enumerated
M, V
No
Reason-Info
617
6.3.18
UTF8String
M, V
No
Charging-Information
618
6.3.19
Grouped
M, V
No
Primary-Event-ChargingFunction-Name
619
6.3.20
DiameterURI
M, V
No
15
1X.S0013-006-B v1.0
Secondary-Event-ChargingFunction-Name
620
6.3.21
DiameterURI
M, V
No
Primary-Charging-CollectionFunction-Name
621
6.3.22
DiameterURI
M, V
No
Secondary-ChargingCollection-Function-Name
622
6.3.23
DiameterURI
M, V
No
User-Authorization-Type
623
6.3.24
Enumerated
M, V
No
User-Data-Already-Available
624
6.3.26
Enumerated
M, V
No
Confidentiality-Key
625
6.3.27
OctetString
M, V
No
Integrity-Key
626
6.3.28
OctetString
M, V
No
Supported-Features
628
6.3.29
Grouped
Feature-List-ID
629
6.3.30
Unsigned32
No
Feature-List
630
6.3.31
Unsigned32
No
Supported-Applications
631
6.3.32
Grouped
No
Associated-Identities
632
6.3.33
Grouped
No
No
NOTE 1: The AVP header bit denoted as M, indicates whether support of the AVP is required. The AVP header bit
denoted as V, indicates whether the optional Vendor-ID field is present in the AVP header. For further
details, see [6].
NOTE 2: Depending on the concrete command.
1
26.3.1 Visited-Network-Identifier AVP
3The Visited-Network-Identifier AVP is of type OctetString. This AVP contains an identifier that helps the
4home network to identify the visited network (e.g. the visited network domain name).
56.3.2 Public-Identity AVP
6The Public-Identity AVP is of type UTF8String. This AVP contains the public identity of a user in the IMS.
7The syntax of this AVP corresponds either to a SIP URL (with the format defined in [3] and [4]) or a TEL
8URL (with the format defined in [8]).
96.3.3 Server-Name AVP
10The Server-Name AVP is of type UTF8String. This AVP contains a SIP-URL (as defined in [3] and [4]),
11used to identify a SIP server (e.g. S-CSCF name).
126.3.4 Server-Capabilities AVP
13The Server-Capabilities AVP is of type Grouped. This AVP contains information to assist the I-CSCF in the
14selection of an S-CSCF.
15AVP format
16
Server-Capabilities ::= <AVP header: 603 10415>
17
*[Mandatory-Capability]
18
*[Optional-Capability]
19
*[Server-Name]
16
X.S0013-006-B v1.0
*[AVP]
26.3.5 Mandatory-Capability AVP

3The Mandatory-Capability AVP is of type Unsigned32. The value included in this AVP can be used to
4represent a single determined mandatory capability of an S-CSCF. Each mandatory capability available in
5an individual operators network shall be allocated a unique value. The allocation of these values to
6individual capabilities is an operator issue.
76.3.6 Optional-Capability AVP
8The Optional-Capability AVP is of type Unsigned32. The value included in this AVP can be used to
9represent a single determined optional capability of an S-CSCF. Each optional capability available in an
10individual operators network shall be allocated a unique value. The allocation of these values to individual
11capabilities is an operator issue.
126.3.7 User-Data AVP
13The User-Data AVP is of type OctetString. This AVP contains the user data required to give service to a
14user. The exact content and format of this AVP is described in [1].
156.3.8 SIP-Number-Auth-Items AVP
16The SIP-Number-Auth-Items AVP is of type Unsigned32.
17When used in a request, the SIP-Number-Auth-Items indicates the number of authentication vectors the S18CSCF is requesting. This can be used, for instance, when the client is requesting several pre-calculated
19authentication vectors. In the answer message, the SIP-Number-Auth-Items AVP indicates the actual
20number of SIP-Auth-Data-Item AVPs provided by the Diameter server.
216.3.9 SIP-Authentication-Scheme AVP
22The Authentication-Scheme AVP is of type UTF8String and indicates the authentication scheme used in the
23authentication of SIP messages.
246.3.10 SIP-Authenticate AVP
25The SIP-Authenticate AVP is of type OctetString and contains specific parts of the data portion of the
26WWW-Authenticate or Proxy-Authenticate SIP headers that are to be present in a SIP response. The
27identification and encoding of the specific parts are defined in [1].
286.3.11 SIP-Authorization AVP
29The SIP-Authorization AVP is of type OctetString and contains specific parts of the data portion of the
30Authorization or Proxy-Authorization SIP headers suitable for inclusion in a SIP request. The identification
31and encoding of the specific parts are defined in [1].
326.3.12 SIP-Authentication-Context AVP
33The SIP-Authentication-Context AVP is of type OctectString, and contains authentication-related
34information relevant for performing the authentication but that is not part of the SIP authentication headers.
35Some mechanisms (e.g. PGP, digest with quality of protection set to auth-int defined in IETF RFC 2617,
36digest with predictive nonces or sip access digest) request that part or the whole SIP request is passed to the
37entity performing the authentication. In such cases the SIP-Authentication-Context AVP would be carrying
38such information.
17
1X.S0013-006-B v1.0
16.3.13 SIP-Auth-Data-Item AVP

2The SIP-Auth-Data-Item is of type Grouped, and contains the authentication and/or authorization
3information for the Diameter client.
4AVP format
5
SIP-Auth-Data-Item:: = <AVP Header : 612 10415>
[ SIP-Item-Number ]
[ SIP-Authentication-Scheme ]
[ SIP-Authenticate ]
[ SIP-Authorization ]
10
[ SIP-Authentication-Context ]
11
[Confidentiality-Key]
12
[Integrity-Key]
13
* [AVP]
146.3.14 SIP-Item-Number AVP

15The SIP-Item-Number AVP is of type Unsigned32, and is included in a SIP-Auth-Data-Item grouped AVP
16in circumstances where there are multiple occurrences of SIP-Auth-Data-Item AVP, and the order in which
17they should be processed is significant. In this scenario, SIP-Auth-Data-Item AVP with a low SIP-Item18Number value should be processed before SIP-Auth-Data-Items AVPs with a high SIP-Item-Number value.
196.3.15 Server-Assignment-Type AVP
20The Server-Assignment-Type AVP is of type Enumerated, and indicates the type of server update being
21performed in a Server-Assignment-Request operation. The following values are defined:
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
NO_ASSIGNMENT (0)
This value is used to request from HSS the user profile assigned to one or more public identities,
without affecting the registration state of those identities.
REGISTRATION (1)
The request is generated as a consequence of a first registration of an identity.
RE_REGISTRATION (2)
The request corresponds to the re-registration of an identity.
UNREGISTERED_USER (3)
The request is generated because the S-CSCF received an INVITE for a public identity that is not
registered.
TIMEOUT_DEREGISTRATION (4)
The SIP registration timer of an identity has expired.
USER_DEREGISTRATION (5)
The S-CSCF has received a user initiated de-registration request.
TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6)
The SIP registration timer of an identity has expired. The S-CSCF keeps the user data stored in
the S-CSCF and requests HSS to store the S-CSCF name.
USER_DEREGISTRATION_STORE_SERVER_NAME (7)
18
X.S0013-006-B v1.0
1
2
3
4
5
6
7
8
9
10
11
The S-CSCF has received a user initiated de-registration request. The S-CSCF keeps the user
data stored in the S-CSCF and requests HSS to store the S-CSCF name.
ADMINISTRATIVE_DEREGISTRATION (8)
The S-CSCF, due to administrative reasons, has performed the de-registration of an identity.
AUTHENTICATION_FAILURE (9)
The authentication of a user has failed.
AUTHENTICATION_TIMEOUT (10)
The authentication timeout has occured.
DEREGISTRATION_TOO_MUCH_DATA (11)
The S-CSCF has requested user profile information from the HSS and has received a volume of
data higher than it can accept.
126.3.16 Deregistration-Reason AVP

13The Deregistration-Reason AVP is of type Grouped, and indicates the reason for a de-registration operation.
14AVP format
15
Deregistration-Reason :: = <AVP Header : 615 10415>
16
{ Reason-Code }
17
[ Reason-Info ]
18
* [AVP]
196.3.17
Reason-Code AVP
20The Reason-Code AVP is of type Enumerated, and defines the reason for the network initiated de21registration. The following values are defined:
22
PERMANENT_TERMINATION (0)
23
NEW_SERVER_ASSIGNED (1)
24
SERVER_CHANGE (2)
25
REMOVE_S-CSCF (3)
26The detailed behaviour of the S-CSCF is defined in [1].

276.3.18
Reason-Info AVP
28The Reason-Info AVP is of type UTF8String, and contains textual information to inform the user about the
29reason for a de-registration.
306.3.19 Charging-Information AVP
31The Charging-Information AVP is of type Grouped, and contains the addresses of the charging functions.
32AVP format
33
Charging-Information :: = <AVP Header : 618 10415>
34
[ Primary-Event-Charging-Function-Name ]
35
[ Secondary-Event-Charging-Function-Name ]
36
[ Primary-Charging-Collection-Function-Name ]
19
1X.S0013-006-B v1.0
[ Secondary-Charging-Collection-Function-Name ]
*[ AVP]
36.3.20 Primary-Event-Charging-Function-Name AVP

4The Primary-Event-Charging-Function-Name AVP is of type DiameterURI. This AVP contains the address
5of the Primary Online Charging Function.
66.3.21 Secondary-Event-Charging-Function-Name AVP
7The Secondary-Event-Charging-Function-Name AVP is of type DiameterURI. This AVP contains the
8address of the Secondary Online Charging Function.
96.3.22 Primary-Charging-Collection-Function-Name AVP
10The Primary-Charging-Collection-Function-Name AVP is of type DiameterURI. This AVP contains the
11address of the Primary Charging Data Function.
126.3.23 Secondary-Charging-Collection-Function-Name AVP
13The Secondary-Charging-Collection-Function-Name AVP is of type DiameterURI. This AVP contains the
14address of the Secondary Charging Data Function.
156.3.24 User-Authorization-Type AVP
16The User-Authorization-Type AVP is of type Enumerated, and indicates the type of user authorization being
17performed in a User Authorization operation, i.e. UAR command. The following values are defined:
18
REGISTRATION (0)
19
20
21
This value is used in case of the initial registration or re-registration. I-CSCF determines this
from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is
not equal to zero.
22
This is the default value.
23
24
25
26
27
28
29
30
DE_REGISTRATION (1)
This value is used in case of the de-registration. I-CSCF determines this from the Expires field or
expires parameter in Contact field in the SIP REGISTER method if it is equal to zero.
REGISTRATION_AND_CAPABILITIES (2)
This value is used in case of initial registration or re-registration and when the I-CSCF explicitly
requests S-CSCF capability information from the HSS. The I-CSCF shall use this value when the
user's current S-CSCF, which is stored in the HSS, cannot be contacted and a new S-CSCF needs
to be selected.
316.3.25 Void
326.3.26 User-Data-Already-Available AVP
33The User-Data-Already-Available AVP is of type Enumerated, and indicates to the HSS whether or not the
34S-CSCF already has the part of the user profile that it needs to serve the user. The following values are
35defined:
36
37
38
USER_DATA_NOT_AVAILABLE (0)
The S-CSCF does not have the data that it needs to serve the user.
USER_DATA_ALREADY_AVAILABLE (1)
20
X.S0013-006-B v1.0
The S-CSCF already has the data that it needs to serve the user.
26.3.27 Confidentiality-Key AVP

3The Confidentiality-Key AVP is of type OctetString, and contains the Confidentiality Key (CK).
46.3.28 Integrity-Key AVP
5The Integrity-Key AVP is of type OctetString, and contains the Integrity Key (IK).
66.3.29 Supported-Features AVP
7The Supported-Features AVP is of type Grouped. If this AVP is present it may inform the destination host
8about the features that the origin host supports. The Feature-List AVP contains a list of supported features of
9the origin host. The Vendor-Id AVP and the Feature-List AVP shall together identify which feature list is
10carried in the Supported-Features AVP.
11Where a Supported-Features AVP is used to identify features that have been defined by 3GPP, the Vendor-Id
12AVP shall contain the vendor ID of 3GPP. Vendors may define proprietary features, but it is strongly
13recommended that the possibility is used only as the last resort. Where the Supported-Features AVP is used
14to identify features that have been defined by a vendor other than 3GPP, it shall contain the vendor ID of the
15specific vendor in question.
16If there are multiple feature lists defined by the same vendor, the Feature-List-ID AVP shall differentiate
17those lists from one another. The destination host shall use the value of the Feature-List-ID AVP to identify
18the feature list.
19AVP format
20
Supported-Features ::= <AVP header: 628 10415>
21
{ Vendor-Id }
22
{ Feature-List-ID }
23
{ Feature-List }
24
*[AVP]
256.3.30 Feature-List-ID AVP

26The Feature-List-ID AVP is of type Unsigned32 and it contains the identity of a feature list.
276.3.31 Feature-List AVP
28The Feature-List AVP is of type Unsigned32 and it contains a bit mask indicating the supported features of
29an application. For the Cx application, the meaning of the bits has been defined in 7.1.1.
306.3.32 Supported-Applications AVP
31The Supported-Applications AVP is of type Grouped and it contains the supported application identifiers of
32a Diameter node.
33AVP format
34
35
Supported-Applications ::= <AVP header: 631 10415>

*[ Auth-Application-Id ]
21
1X.S0013-006-B v1.0
*[ Acct-Application-Id ]
*[ Vendor-Specific-Application-Id ]
*[ AVP ]
46.3.33 Associated-Identities AVP

5The Associated-Identities AVP is of type Grouped and it contains the private user identities associated to an
6IMS subscription.
7AVP format
8
9
10
116.4
Associated-Identities ::= <AVP header: 632, 10415>

*[User-Name]
*[AVP]
Use of namespaces
12This clause contains the namespaces that have either been created in this specification, or the values
13assigned to existing namespaces managed by IANA.
146.4.1 AVP codes
15This specification assigns the AVP values from the AVP Code namespace for Diameter vendor-specific
16applications. See section 6.3 for the assignment of the namespace in this specification.
176.4.2 Experimental-Result-Code AVP values
18This specification has assigned Experimental-Result-Code AVP values 2001-2005 and 5001-5011. See
19section 6.2.
206.4.3 Command Code values
21This specification assigns the values 300-305 from the range allocated by IANA to 3GPP in [12].
226.4.4 Application-ID value
23IANA has allocated the value 16777216 for the 3GPP/3GPP2 Cx interface application.
22
X.S0013-006-B v1.0
17
Special requirements
27.1
Version control
3New functionality - i.e. functionality beyond the initial version of the Cx specification shall be introduced
4by later versions of the Cx Diameter applications as follows:
5
1.
If possible, the new functionality shall be defined optional.
6
7
2.
If backwards incompatible changes can not be avoided, the new functionality should be introduced
as a feature, see 7.1.1.
8
9
10
3.
If the change would be backwards incompatible even as if it was defined as a feature, a new
version of the interface shall be created by changing the application identifier of the Diameter
application, see 7.1.2.
117.1.1 Defining a new feature

12The base functionality for the Cx is the initial version of this document and a feature is an extension to that
13functionality. A feature is a functional entity that has a significant meaning to the operation of a Diameter
14application i.e. a single new parameter without a substantial meaning to the functionality of the Diameter
15endpoints should not be defined to be a new feature. If the support for a feature is defined mandatory in a
16later version of this document, the feature concept enables interworking between Diameter endpoints
17regardless of whether they support all, some or none of the features of the application. Features should be
18defined so that they are independent from one another.
19The content of a feature shall be defined as a part of the specification of the affected application messages.
20If new AVPs are added to the commands because of the new feature, the new AVPs shall have the M bit
21cleared and the AVP shall not be defined mandatory in the command ABNF. The support for a feature may
22be defined to be mandatory behaviour of a node.
23As an option to defining a feature, an extension to S-CSCF functionality in a later version of this document
24may be defined as part of the list of mandatory capabilities that is used by the I-CSCF during the process of
25selecting an S-CSCF, as described in [1]. Any new feature should be taken into account in the definition of
26the list of mandatory and optional S-CSCF capabilities. Guidelines for the definition of S-CSCF
27Capabilities are described in [1]
28The following table of features shall apply to the Cx interface.
23
1X.S0013-006-B v1.0
Table 7.1.1: Features of Feature-List-ID 1 used in Cx
Feature
bit
Feature
M/O
Description
SiFC
Shared iFC sets

This feature is applicable for the SAR/SAA and PPR/PPA command pairs.
If both the HSS and the S-CSCF support this feature, subsets of Initial Filter
Criteria may be shared by several service profiles and the HSS shall download
the shared iFC sets implicitly by downloading the unique identifiers of the
shared iFC sets to the S-CSCF. By means of a locally administered database,
the S-CSCF then maps the downloaded identifiers onto the shared iFC sets.
If the S-CSCF does not support this feature, the HSS shall not download
identifiers of shared iFC sets. Instead as a default behavior the HSS shall (by
means of a locally administered database) download the iFCs of a shared iFC
set explicitly.
If the HSS does not support this feature, no special default behaviour is
required for the S-CSCF.
Note: In using this feature option, the network operator is responsible for
keeping the local databases in the S-CSCFs and HSSs consistent.
Feature bit: The order number of the bit within the Supported-Features AVP, e.g. 1.
Feature: A short name that can be used to refer to the bit and to the feature, e.g. MOM.
M/O: Defines if the implementation of the feature is mandatory (M) or optional (O).
Description: A clear textual description of the feature.
2
3The origin host may discover the supported features of the destination host with the dynamic discovery
4mechanism defined in 7.2 or via local O&M interfaces.
57.1.2 Changing the version of the interface
6The version of an interface shall be changed by a future version of this specification only if there is no
7technically feasible means to avoid backwards incompatible changes to the Diameter application, i.e. to the
8current version of the interface. However, if the incompatible changes can be capsulated within a feature,
9there is no need to change the version of the interface. The versioning of an interface shall be implemented
10by assigning a new application identifier for the interface. This procedure is in line with the Diameter base
11protocol (see [6]) which defines that if an incompatible change is made to a Diameter application, a new
12application identifier shall be assigned for the Diameter application.
13The following table shall apply to the Cx interface, column Application identifier lists the used application
14identifiers on Cx.
15
Table 7.1.2: Application identifiers used in Cx

Application identifier
First applied
16777216
First version of Cx
16
24
X.S0013-006-B v1.0
1The origin host may discover which versions of an interface the destination host supports within the
2capabilities exchange (i.e. CER/CEA command), via the error messages defined in the chapter 7.3 or via
3local O&M interfaces.
47.2
Supported features
5Features that are not indicated in the Supported-Features AVPs within a given application message shall not
6be used to construct that message. A request application message shall always be compliant with the list of
7supported features indicated in the Supported-Features AVPs within the application message. If a feature
8does not effect on constructing an application message, the message is by definition compliant with the
9feature. If no features are indicated in the application message, no features - i.e., no extensions to the first
10version of Cx shall be used to construct the application message. An answer application message shall
11always indicate in the Supported-Features AVPs the complete set of features supported by the sender of the
12answer application message. An answer application message shall be compliant with the features commonly
13supported by the sender of the request and answer application messages.
14The sender of a request application message shall discover for a given application message pair which
15features a destination host supports as described in 7.2.1. The discovery of the supported features shall
16apply only to the exchanged application message pair type, the discovered features of one command pair
17shall not be applicable to other command pairs within the application. Different commands within an
18application may support a different set of features. After discovering the features a destination host supports
19for a given application message pair, the sender of the request application message may store the
20information on the supported features of the destination host and it may use the features the destination host
21supports to construct the subsequent request application messages sent to the destination host.
227.2.1 Dynamic discovery of supported features
23When sending a request application message to a destination host whose supported features the sender does
24not know, the request application message shall include the Supported-Features AVP containing the set of
25features required to process the request and generate the answer. An exception to this is where the origin
26host does not use any features to construct the request application message and it is not prepared to accept
27an answer application message which is constructed by making use of any features. For this exception, the
28origin host need not include the Supported-Features AVP within the message. The Supported-Features AVP
29within a request application message shall always have the M bit set and within an answer application
30message the AVP shall never have the M bit set.
31On receiving a request application message, the destination host shall do one of the following:
32
If it supports all features indicated in the Supported-Features AVPs within the request message, the
answer application message shall include Supported-Features AVPs identifying the complete set of
features that it supports. The Experimental-Result-Code AVP shall not be set to
DIAMETER_ERROR_FEATURE_UNSUPPORTED.
If the request application message does not contain any Supported-Features AVPs, the answer
application message shall include either Supported-Features AVPs identifying the complete set of
features that it supports or, if it does not support any features, no Supported-Features AVPs shall be
present. The Experimental-Result-Code AVP shall not be set to
DIAMETER_ERROR_FEATURE_UNSUPPORTED.
If the destination host implements a version of the Cx protocol other than the initial version and it
does not support all the features indicated in the Supported-Features AVPs, it shall return the answer
application message with the Experimental-Result-Code AVP set to
DIAMETER_ERROR_FEATURE_UNSUPPORTED and it shall include also Supported-Features
AVPs containing lists of all features that it supports.
33
34
35
36
37
38
39
40
41
42
43
44
45
25
1X.S0013-006-B v1.0
2
3
4
If the destination host implements the initial version of the Cx protocol and it receives a request
application message containing Supported-Features AVPs, it will return the answer application
message with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED and a Failed-AVP
AVP containing at least one Supported-Features AVP as received in the request application message.
5If an answer application message is received with the Experimental-Result-Code AVP set to
6DIAMETER_ERROR_FEATURE_UNSUPPORTED or with the Result-Code AVP set to
7DIAMETER_AVP_UNSUPPORTED, the sender of the request application message may, based on the
8information in the received Supported-Features AVP or the lack of the AVP in the message, re-send the
9Diameter message containing only the common supported features.
107.3
Interface versions
11The sender of the request application message may discover which versions of an interface a destination
12host supports together with the capabilities exchange (i.e. CER/CEA command pair) and with error
13mechanisms defined to the application messages in 7.3.1. The sender of the request application message
14should store information on all versions of the interface the destination host supports. The sender of the
15request application message should use the latest common version of the application supported by the
16destination host to send the request.
17If the receiver of the request application message itself or the versions of the interface it supports are not yet
18known, the sender of the request application message should use the latest supported version of the
19interface of the Diameter peer (i.e. Diameter proxy, redirect or relay agent) discovered during the
20capabilities exchange. If the Diameter peer is a redirect or relay agent, which advertises the 0xffffffff as an
21application identifier, the sender of the request application message shall use its own latest supported
22version of the interface when initiating the request.
237.3.1 Discovery of supported interface versions
24When a Diameter agent receives a request application message and the Diameter agent doesnt find any
25upstream peer that would support the application identifier indicated in the request, the Diameter agent shall
26return the result code DIAMETER_UNABLE_TO_DELIVER and it may also return the list of the
27application identifiers, which are supported by the destination host of the request application message. The
28supported application identifiers are carried in the answer application message in the Supported29Applications grouped AVP.
30Message format for the answer application message (based on [6], section 7.2) is as follows:
31
32
33
34
35
36
37
38
39
40
41
<answer-message> ::= < Diameter Header: code, ERR [PXY] >

0*1< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Origin-State-Id ]
[ Error-Reporting-Host ]
[ Proxy-Info ]
[ Supported-Applications ]
* [ AVP ]
42If the receiver of a request application message does not support the application identifier indicated in the
43message, it shall return the result code DIAMETER_APPLICATION_UNSUPPORTED and it may also
44return the list of all application identifiers it supports. The supported application identifiers are carried in the
45Supported-Applications grouped AVP. The error message format is as specified above.
46If an answer application message is received with Result-Code AVP set to
47DIAMETER_UNABLE_TO_DELIVER or Experimental-Result-Code AVP set to
26
X.S0013-006-B v1.0
1DIAMETER_APPLICATION_UNSUPPORTED and the message contains the Supported-Applications

2AVP, the receiver of the answer application message may select, based on the information in the Supported3Applications AVP, the latest common version of the interface with the destination host and re-send the
4Diameter message with a structure conforming to the ABNF of that release.
27

CX Diameter Int

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CX Diameter Int

Загружено:

Авторское право:

Доступные форматы

X.S0013-006-B v1.

All-IP Core Network Multimedia Domain

User-Authorization-Answer (UAA) command..........................................................8

Server-Assignment-Request (SAR) command...........................................................9

Server-Assignment-Answer (SAA) command...........................................................9

Location-Info-Request (LIR) command..................................................................10

Location-Info-Answer (LIA) command...................................................................10

Multimedia-Auth-Request (MAR) command..........................................................10

Multimedia-Auth-Answer (MAA) command...........................................................11

Registration-Termination-Request (RTR) command................................................11

Registration-Termination-Answer (RTA) command................................................12

Push-Profile-Request (PPR) command....................................................................12

Push-Profile-Answer (PPA) command.....................................................................13

Experimental-Result-Code AVP values....................................................................22

Command Code values............................................................................................22

207 Special requirements.............................................................................................................23

Changing the version of the interface......................................................................24

For a specific reference, subsequent revisions do not apply.

IETF RFC 3261, "SIP: Session Initiation Protocol"

IETF RFC 2396, Uniform Resource Identifiers (URI): generic syntax

IETF RFC 2960, Stream Control Transmission Protocol

IETF RFC 3588, Diameter Base Protocol

IETF RFC 2234, Augmented BNF for syntax specifications

IETF RFC 3966, URLs for Telephone Calls

IETF RFC 3309, SCTP Checksum Change

3GPP2 X.S0013-011-B, Sh Interface based on the Diameter protocol; protocol details

Definitions, symbols and abbreviations

Augmented Backus-Naur Form

Use of the Diameter base protocol

Securing Diameter messages

5For secure transport of Diameter messages, see [2].

Advertising application support

Diameter application for Cx interface

to exchange location information

to authorize a user to access the IMS

to exchange authentication information

14This section defines Command-Code values for this Diameter application.

Table 6.1.1: Command-Code values

< Diameter Header: 300, PXY, 16777216 >

16.1.3 Server-Assignment-Request (SAR) command

< Diameter Header: 301, PXY, 16777216 >

16.1.5 Location-Info-Request (LIR) command

166.1.8 Multimedia-Auth-Answer (MAA) command

126.1.10 Registration-Termination-Answer (RTA) command

56.1.12 Push-Profile-Answer (PPA) command

Experimental-Result-Code AVP values

The user is authorized to register this public identity;

A S-CSCF shall be assigned to the user.

The user is authorized to register this public identity;

A S-CSCF is already assigned and there is no need to select a new one.

A S-CSCF shall be assigned to the user.

The de-registration is completed;

The S-CSCF name is not stored in the HSS.

96.2.2 Permanent failures

Table 6.3.1: Diameter Multimedia Application AVPs

AVP Flag rules

Must May Should Must May Encr.

Server-Capabilities ::= <AVP header: 603 10415>

26.3.5 Mandatory-Capability AVP

16.3.13 SIP-Auth-Data-Item AVP

SIP-Auth-Data-Item:: = <AVP Header : 612 10415>

146.3.14 SIP-Item-Number AVP

126.3.16 Deregistration-Reason AVP