7 Special Requirements
29.2293GPPCx and Dx interfaces based on the Diameter protocolProtocol detailsRelease 17TS
7.1 Version Control
New functionality – i.e. functionality beyond the Rel-5 standard – shall be introduced by post-Rel-5 versions of this specification to the Diameter applications as follows:
1. If possible, the new functionality shall be defined optional.
2. If backwards incompatible changes can not be avoided, the new functionality should be introduced as a feature, see 7.1.1.
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.
7.1.1 Defining a new feature
The base functionality for the Cx is the 3GPP Rel-5 standard and a feature is an extension to that functionality. A feature is a functional entity that has a significant meaning to the operation of a Diameter application i.e. a single new parameter without a substantial meaning to the functionality of the Diameter endpoints should not be defined to be a new feature. If the support for a feature is defined mandatory in a post-Rel-5 versions of this specification, the feature concept enables interworking between Diameter endpoints regardless of whether they support all, some or none of the features of the application. Features should be defined so that they are independent from one another.
The content of a feature shall be defined as a part of the specification of the affected application messages. If new AVPs are added to the commands because of the new feature, the new AVPs shall have the ‘M’ bit cleared and the AVP shall not be defined mandatory in the command ABNF. The support for a feature may be defined to be mandatory behaviour of a node.
As an option to defining a feature, an extension to S-CSCF functionality for post-Rel-5 version may be defined as part of the list of mandatory capabilities that is used by the I-CSCF during the process of selecting an S-CSCF, as described in 3GPP TS 29.228 [1]. Any new feature should be taken into account in the definition of the list of mandatory and optional S-CSCF capabilities. Guidelines for the definition of S-CSCF Capabilities are described in 3GPP TS 29.228 [1].
The following table of features shall apply to the Cx interface.
Table 7.1.1: Features of Feature-List-ID 1 used in Cx
|
Feature bit |
Feature |
M/O |
Description |
|
0 |
SiFC |
O |
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 DSAI feature, as defined in 3GPP TS 29.328 [16], is also active with the shared iFC sets feature then the HSS shall behave as described below: If the DSAI feature is active with the shared iFC sets feature and if all the iFCs bounding to a Shared iFC set are not masked by the DSAI, the HSS shall download the unique identifier of the shared iFC set to the S-CSCF. If some iFCs or all the iFCs bounding to a shared iFC set are masked by the DSAI, the HSS shall not download the identifier of the shared iFC set. Instead the HSS shall – download the remaining non masked iFCs of the shared iFC set explicitly or – download suitable identifiers of other shared iFC sets, i.e. those covering exactly the remaining non masked iFCs and which do not contain masked iFCs or – download a combination of identifiers of shared iFC sets and explicit iFCs which cover exactly the remaining non masked iFCs. 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. |
|
1 |
AliasInd |
M |
Alias Indication This feature is applicable for the SAR/SAA and PPR/PPA command pairs. If both the HSS and the S-CSCF support this feature, different aliases groups may be sent within the same service profile. Identities within the same service profile that are aliases shall be sent with identical alias group ID. If the S-CSCF does not support this feature, the HSS shall send within the service profile only those identities that are aliases. Public User Identities that are not aliases of each other shall be sent in different service profiles even if these service profiles have exactly the same Core Network Service Authorization, Initial Filter Criteria, and Shared iFC Set information and these service profiles only differ in the contained Public User Identities. This is done in order to allow backwards compatibility since part of the handling of aliases in the S-CSCF was there before this indication was required and it applied to identities that share the same service profile and implicit registration set. In this case, the S-CSCF does not provide any additional treatment of aliases than that which existed before this indication was required. If the HSS does not support this feature, no special default behaviour is required for the S-CSCF. Note: All identities included in a single SAA or PPR command are always within one implicit registration set. |
|
2 |
IMSRestorationInd |
O |
IMS Restoration Indication This feature is applicable for the UAR/UAA, LIR/LIA, SAR/SAA command pairs. If both the HSS and the I-CSCF support this feature, in case the S-CSCF currently assigned in the HSS to the Public User Identity cannot be contacted the I-CSCF shall trigger the assignment of a new S-CSCF. If both the HSS and the S-CSCF support this feature, the S-CSCF shall send S-CSCF Restoration Information to the HSS. The HSS shall send this information element in SAA to the S-CSCF when required. If the S-CSCF does not support this feature, the HSS shall not send the IMS Restoration Information to the S-CSCF. |
|
3 |
P-CSCF-Restoration-mechanism |
O |
HSS-based P-CSCF Restoration mechanism. This feature is applicable for the SAR/SAA command pair. If both the HSS and the S-CSCF support this feature, the S-CSCF shall send the P-CSCF-Restoration-Indication in SAR-Flags AVP to the HSS when required as described by 3GPP TS 23.380 [24] clause 5.4. If the HSS does not support this feature, the S-CSCF shall not send the P-CSCF-Restoration-Indication to HSS. |
|
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. |
|||
The origin host may discover the supported features of the destination host with the dynamic discovery mechanism defined in 7.2 or via local O&M interfaces.
7.1.2 Changing the version of the interface
The version of an interface shall be changed by a future version of this specification only if there is no technically feasible means to avoid backwards incompatible changes to the Diameter application, i.e. to the current version of the interface. However, if the incompatible changes can be capsulated within a feature, there is no need to change the version of the interface. The versioning of an interface shall be implemented by assigning a new application identifier for the interface. This procedure is in line with the Diameter base protocol (see IETF RFC 3588) which defines that if an incompatible change is made to a Diameter application, a new application identifier shall be assigned for the Diameter application.
The following table shall apply to the Cx interface, column Application identifier lists the used application identifiers on Cx and 3GPP.
Table 7.1.2: Application identifiers used in Cx
|
Application identifier |
First applied |
|
16777216 |
3GPP Rel-5 |
The origin host may discover which versions of an interface the destination host supports within the capabilities exchange (i.e. CER/CEA command), via the error messages defined in the clause 7.3 or via local O&M interfaces.
7.2 Supported features
Features that are not indicated in the Supported-Features AVPs within a given application message shall not be used to construct that message. A request application message shall always be compliant with the list of supported features indicated in the Supported-Features AVPs within the application message. If a feature does not have an effect on constructing an application message, the message is by definition compliant with the feature. If no features are indicated in the application message, no features – i.e. no extensions to Rel-5 – shall be used to construct the application message. An answer application message shall always indicate in the Supported-Features AVPs the complete set of features supported by the sender of the answer application message. An answer application message shall be compliant with the features commonly supported by the sender of the request and answer application messages.
The sender of a request application message shall discover for a given application message pair which features a destination host supports as described in 7.2.1. The discovered features of one command pair may be applicable to other command pairs within the application. Different commands within an application may support a different set of features. After discovering the features a destination host supports for a given application message pair, the sender of the request application message may store the information on the supported features of the destination host and it may use the features the destination host supports to construct the subsequent request application messages sent to the destination host.
7.2.1 Dynamic discovery of supported features
When sending a request application message to a destination host whose supported features the sender does not know, the request application message shall include the Supported-Features AVP containing the set of features required to process the request and generate the answer. An exception to this is where the origin host does not use any features to construct the request application message and it is not prepared to accept an answer application message which is constructed by making use of any features. For this exception the origin host need not include the Supported-Features AVP within the message.
The Supported-Features AVP within a request application message shall always have the ‘M’ bit set and within an answer application message the AVP shall never have the ‘M’ bit set. An exception to this is where the origin host does not use any supported feature to construct the request application message but is prepared to accept an answer application message which is constructed by making use of supported features. For this exception it is optional for the origin host to set the ‘M’ bit of the Supported-Features AVP within the request application message.
On receiving a request application message, the destination host shall do one of the following:
– 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 it does not support all the features indicated in the Supported-Features AVPs with the ‘M’ bit set, 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.
– If it does not support Supported-Features AVP and it receives a request application message containing Supported-Features AVPs with the ‘M’ bit set, 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.
If an answer application message is received with the Experimental-Result-Code AVP set to DIAMETER_ERROR_FEATURE_UNSUPPORTED or with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED, the sender of the request application message may, based on the information in the received Supported-Features AVP or the lack of the AVP in the message, re-send the Diameter message containing only the common supported features.
7.3 Interface versions
The sender of the request application message may discover which versions of an interface a destination host supports together with the capabilities exchange (i.e. CER/CEA command pair) and with error mechanisms defined to the application messages in 7.3.1. The sender of the request application message should store information on all versions of the interface the destination host supports. The sender of the request application message should use the latest common version of the application supported by the destination host to send the request.
If the receiver of the request application message itself or the versions of the interface it supports are not yet known, the sender of the request application message should use the latest supported version of the interface of the Diameter peer (i.e. Diameter proxy, redirect or relay agent) discovered during the capabilities exchange. If the Diameter peer is a redirect or relay agent, which advertises the 0xffffffff as an application identifier, the sender of the request application message shall use its own latest supported version of the interface when initiating the request.
7.3.1 Discovery of supported interface versions
When a Diameter agent receives a request application message and the Diameter agent doesn’t find any upstream peer that would support the application identifier indicated in the request, the Diameter agent shall return the result code DIAMETER_UNABLE_TO_DELIVER and it may also return the list of the application identifiers, which are supported by the destination host of the request application message. The supported application identifiers are carried in the answer application message in the Supported-Applications grouped AVP.
Message format for the answer application message (based on the RFC 3588, clause 7.2) is as follows:
<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 ]
If the receiver of a request application message does not support the application identifier indicated in the message, it shall return the result code DIAMETER_APPLICATION_UNSUPPORTED and it may also return the list of all application identifiers it supports. The supported application identifiers are carried in the Supported-Applications grouped AVP. The error message format is as specified above.
If an answer application message is received with Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER or Experimental-Result-Code AVP set to DIAMETER_APPLICATION_UNSUPPORTED and the message contains the Supported-Applications AVP, the receiver of the answer application message may select, based on the information in the Supported-Applications AVP, the latest common version of the interface with the destination host and re-send the Diameter message with a structure conforming to the ABNF of that release.
Annex A (informative):
Change history
|
Date |
TSG # |
TSG Doc. |
CR# |
Rev |
Cat |
Subject/Comment |
Out |
|
Jun 2002 |
CN#16 |
NP-020265 |
Version 2.0.0 approved at CN#16 |
5.0.0 |
|||
|
Sep 2002 |
CN#17 |
NP-020449 |
001 |
– |
Add a reference to the new IETF RFC on SCTP checksum |
5.1.0 |
|
|
Sep 2002 |
CN#17 |
NP-020449 |
003 |
– |
Wrong format of Charging Function Addresses |
5.1.0 |
|
|
Sep 2002 |
CN#17 |
NP-020449 |
005 |
– |
Editorial mistake in the definition of command MAA |
5.1.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
006 |
– |
Addition of User-Name AVP to SAA |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
007 |
– |
Editorial correction of SIP-Auth-Data-Item AVP definition |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020589 |
008 |
1 |
Clarification of REGISTRATION_AND_CAPABILITIES value |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020588 |
009 |
– |
Correction in charging information |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020590 |
010 |
1 |
Error handling in S-CSCF when receiving too much data |
5.2.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
012 |
1 |
Update TS 29.229 after Diameter has become RFC |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
015 |
1 |
Clarification on Re-allocation of S-CSCF |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
018 |
1 |
Handling of non supported data in the S-CSCF when the profile is being updated. |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
014 |
– |
Correction to the values of User-Authorizatin-Type AVP |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
013 |
– |
Replacement of the NAS-Session-Key AVP |
5.3.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
019 |
– |
Conditionality of User-Name AVP in Server-Assignment-Answer |
5.4.0 |
|
|
Sep 2003 |
CN#21 |
NP-030383 |
022 |
1 |
Critical Correction on the PPR command code |
5.5.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
021 |
1 |
The S-CSCF name needs to be checked always in MAR and SAR |
5.6.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
027 |
– |
User-Authorization-Type |
5.6.0 |
|
|
Dec 2003 |
CN#22 |
NP-030518 |
029 |
– |
Clarification of inclusion of elements in Charging Information |
5.6.0 |
|
|
Dec 2003 |
CN#22 |
Application IDs and references updated |
5.6.0 |
||||
|
Mar 2004 |
CN#23 |
NP-040055 |
035 |
– |
Error for no identification in SAR command |
6.0.0 |
|
|
Jun 2004 |
CN#24 |
NP-040215 |
037 |
1 |
Update of the charging addresses from HSS |
6.1.0 |
|
|
Jun 2004 |
CN#24 |
NP-040215 |
043 |
– |
Multimedia-Auth-Request (MAR) Command Message Format Corrections |
6.1.0 |
|
|
Jun 2004 |
CN#24 |
NP-040215 |
050 |
2 |
Use of Vendor-Id by 3GPP |
6.1.0 |
|
|
Sep 2004 |
CN#25 |
NP-040395 |
065 |
2 |
Application version control |
6.2.0 |
|
|
Sep 2004 |
CN#25 |
NP-040401 |
056 |
– |
Optimization of User Profile Download |
6.2.0 |
|
|
Sep 2004 |
CN#25 |
NP-040396 |
058 |
– |
Simplification of the User Profile Split concept |
6.2.0 |
|
|
Sep 2004 |
CN#25 |
NP-040401 |
061 |
– |
Correction of the Application-Id code |
6.2.0 |
|
|
Sep 2004 |
CN#25 |
NP-040412 |
063 |
1 |
Re-numbering of 3GPP specific AVP codes |
6.2.0 |
|
|
Dec 2004 |
CN#26 |
NP-040523 |
070 |
– |
Cx ABNF corrections |
6.3.0 |
|
|
Mar 2005 |
CN#27 |
NP-050030 |
078 |
2 |
Correction of authentication-related AVPs |
6.4.0 |
|
|
Mar 2005 |
CN#27 |
NP-050037 |
079 |
– |
TEL-URI reference update |
6.4.0 |
|
|
Mar 2005 |
CN#27 |
NP-050030 |
082 |
1 |
Introduction of Failed-AVP |
6.4.0 |
|
|
Jun 2005 |
CT#28 |
CP-050086 |
087 |
– |
Correction of reference |
6.5.0 |
|
|
Jun 2005 |
CT#28 |
CP-050086 |
089 |
1 |
Editorial corrections |
6.5.0 |
|
|
Jun 2005 |
CT#28 |
CP-050086 |
088 |
2 |
Corrections to message parameters |
6.5.0 |
|
|
Sep 2005 |
CT#29 |
CP-050440 |
091 |
2 |
Private identities on the Cx |
6.6.0 |
|
|
Sep 2005 |
CT#29 |
CP-050282 |
093 |
1 |
Charging-Information correction |
6.6.0 |
|
|
Sep 2005 |
CT#29 |
CP-050296 |
094 |
– |
Error code cleanup |
6.6.0 |
|
|
Dec 2005 |
CT#30 |
CP-050611 |
095 |
1 |
Removal of overhead in Private Identities handling in RTR |
6.7.0 |
|
|
Dec 2005 |
CT#30 |
CP-050611 |
098 |
1 |
Incorrect Definition of Supported-Applications AVP |
6.7.0 |
|
|
Jan 2006 |
Rel-7 version was created because of ETSI TISPAN references. |
7.0.0 |
|||||
|
Mar 2006 |
CT#31 |
CP-060084 |
0099 |
– |
Supported Features Text missing |
7.1.0 |
|
|
Jun 2006 |
CT#32 |
CP-060302 |
0108 |
– |
S-CSCF reselection removal |
7.2.0 |
|
|
Jun 2006 |
CT#32 |
CP-060308 |
0110 |
3 |
Definition of new Feature for Cx |
7.2.0 |
|
|
Sep 2006 |
CT#33 |
CP-060417 |
0114 |
3 |
AS originating requests on behalf of a user |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060405 |
0118 |
2 |
Correction of discovery of supported features in Sh and Cx |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060417 |
0119 |
1 |
Sharing feature support information between command pairs |
7.3.0 |
|
|
Dec 2006 |
CT#34 |
CP-060566 |
0124 |
1 |
Optimization of handling of Wildcarded PSIs |
7.4.0 |
|
|
Mar 2007 |
CT#35 |
CP-070020 |
0125 |
1 |
M-bit in SupportedFeatures AVP |
7.5.0 |
|
|
Sep 2007 |
CT#37 |
CP-070520 |
0129 |
– |
Misalignment of Mandatory Items in the MAR |
7.6.0 |
|
|
Nov 2007 |
CT#38 |
CP-070744 |
0132 |
6 |
Add alias as a new feature |
7.7.0 |
|
|
Nov 2007 |
CT#38 |
CP-070755 |
0130 |
4 |
Updates to 29.229 for Digest on the Cx interface |
8.0.0 |
|
|
Mar 2008 |
CT#39 |
CP-080022 |
0138 |
2 |
Update 29.229 for Supporting NASS-Bundled-Authentication |
8.1.0 |
|
|
Mar 2008 |
CT#39 |
CP-080019 |
0139 |
– |
SIP Digest password push |
8.1.0 |
|
|
Mar 2008 |
CT#39 |
CP-080019 |
0141 |
2 |
Wildcarded Public User Identities |
8.1.0 |
|
|
Jun 2008 |
CT#40 |
CP-080261 |
0145 |
1 |
Correction to the behavior of the HSS defined in the SiFC feature |
8.2.0 |
|
|
Jun 2008 |
CT#40 |
CP-080261 |
0146 |
2 |
Realm and Host to be used for Charging |
8.2.0 |
|
|
Sep 2008 |
CT#41 |
CP-080456 |
0149 |
1 |
Emergency Public User Identity Removal |
8.3.0 |
|
|
Sep 2008 |
CT#41 |
CP-080460 |
0155 |
1 |
Support of "Loose-Route" indication from HSS |
8.3.0 |
|
|
Sep 2008 |
CT#41 |
CP-080463 |
0156 |
1 |
Cx Impacts of IMS Restoration Procedures |
8.3.0 |
|
|
Sep 2008 |
CT#41 |
CP-080463 |
0158 |
Add IMS Restoration as a new feature |
8.3.0 |
||
|
Sep 2008 |
CT#41 |
CP-080463 |
0159 |
1 |
Addition of Registered Private Identities in SAA |
8.3.0 |
|
|
Sep 2008 |
CT#41 |
CP-080460 |
0160 |
1 |
Add Assigned S-CSCF name to SAA |
8.3.0 |
|
|
Dec 2008 |
CT#42 |
CP-080708 |
0163 |
Removal of Digest Domain |
8.4.0 |
||
|
Dec 2008 |
CT#42 |
CP-080708 |
0166 |
2 |
Diameter Proxy Agent – an alternative User Identity to HSS resolution mechanism |
8.4.0 |
|
|
Mar 2009 |
CT#43 |
CP-090026 |
0167 |
Multiple Registrations in Registration |
8.5.0 |
||
|
Mar 2009 |
CT#43 |
CP-090026 |
0168 |
1 |
Restoration Information for Multiple Registrations |
8.5.0 |
|
|
Mar 2009 |
CT#43 |
CP-090026 |
0169 |
Update for Restoration |
8.5.0 |
||
|
Mar 2009 |
CT#43 |
CP-090051 |
0170 |
1 |
Definition of Server-Assignment-Type values in Cx |
8.5.0 |
|
|
Mar 2009 |
CT#43 |
CP-090028 |
0171 |
Support for GPRS IMS Bundled Authentication (GIBA) in Cx |
8.5.0 |
||
|
Mar 2009 |
CT#43 |
CP-090025 |
0172 |
Use of canonical form for SIP URI/tel URI in Cx interface |
8.5.0 |
||
|
Mar 2009 |
CT#43 |
CP-090026 |
0175 |
1 |
Comma separated list for Path, Contact and Record-Route AVPs |
8.5.0 |
|
|
Jun 2009 |
CT#44 |
CP-090484 |
0176 |
2 |
Contact storage in reg event subscription |
8.6.0 |
|
|
Jun 2009 |
CT#44 |
CP-090303 |
0177 |
1 |
Comma separated list for path AVP |
8.6.0 |
|
|
Sep |
CT#45 |
CP-090526 |
0181 |
Dx over SCTP |
8.7.0 |
||
|
Dec 2009 |
CT#46 |
CP-090784 |
0182 |
2 |
SIP Digest AVP Flag Settings |
8.8.0 |
|
|
Dec 2009 |
CT#46 |
CP-090781 |
0185 |
1 |
Unregistered user clarification |
8.8.0 |
|
|
Dec 2009 |
CT#46 |
CP-090778 |
0188 |
2 |
Session-Priority AVP |
8.8.0 |
|
|
Dec 2009 |
CT#46 |
CP-091030 |
0189 |
Validity of Feature Bit Value in Feature-List AVP |
8.8.0 |
||
|
Dec 2009 |
CT#46 |
Upgraded unchanged from Rel-8 |
9.0.0 |
||||
|
Mar 2010 |
CT#47 |
CP-100239 |
0195 |
1 |
Wildcarded Public Identity |
9.1.0 |
|
|
Mar 2010 |
CT#47 |
CP-100031 |
0199 |
Wildcarded Public Identities handling |
9.1.0 |
||
|
Jun 2010 |
CT#48 |
CP-100412 |
0205 |
1 |
Digest AVPs wrongly defined |
9.2.0 |
|
|
Sep 2010 |
CT#49 |
CP-100447 |
0207 |
2 |
Wildcarded Identities handling |
9.3.0 |
|
|
Sep 2010 |
CT#49 |
CP-100442 |
0209 |
2 |
Mandatory and optional capabilities handling |
9.3.0 |
|
|
Sep 2010 |
CT#49 |
CP-100442 |
0212 |
Reference to SCTP IETF RFC obsolete |
9.3.0 |
||
|
Sep 2010 |
CT#49 |
CP-100463 |
0213 |
2 |
Restoration Data Backup |
9.3.0 |
|
|
Sep 2010 |
CT#49 |
CP-100447 |
0216 |
Encoding of Framed-IPv6-Prefix AVP |
9.3.0 |
||
|
2011-03 |
– |
– |
– |
– |
Update to Rel-10 version (MCC) |
10.0.0 |
|
|
Jun 2011 |
CT#52 |
CP-110349 |
0224 |
2 |
Handling of RTR for Emergency Registration |
10.1.0 |
|
|
Jun 2011 |
CT#52 |
CP-110349 |
0227 |
Error in assignment type for backward compatibility scenarios |
10.1.0 |
||
|
Jun 2011 |
CT#52 |
CP-110349 |
0230 |
User-Authorization-Type AVP error in description |
10.1.0 |
||
|
Sep 2011 |
CT#53 |
CP-110566 |
0233 |
1 |
Priviledged sender |
10.2.0 |
|
|
Dec 2011 |
CT#54 |
CP-110781 |
0240 |
1 |
Restoration of Wildcarded-IMPU AVP |
10.3.0 |
|
|
Dec 2011 |
CT#54 |
CP-110812 |
0235 |
2 |
Server Assignment Type AVP definition |
11.0.0 |
|
|
Sep 2012 |
CT#57 |
CP-120440 |
0247 |
1 |
Emergency registrations do not affect registration status |
11.1.0 |
|
|
Dec 2012 |
CT#58 |
CP-120743 |
0251 |
2 |
PSI direct routing with restoration procedures |
11.2.0 |
|
|
Mar 2013 |
CT#59 |
CP-130011 |
0258 |
1 |
Originating-request AVP in LIR |
11.3.0 |
|
|
Jun 2013 |
CT#60 |
CP-130374 |
0260 |
1 |
Supported-Feature AVP carries list of features specific to the Application-ID |
11.4.0 |
|
|
Jun 2013 |
CT#60 |
CP-130380 |
0259 |
– |
Visited Network ID coding |
12.0.0 |
|
|
Dec 2013 |
CT#62 |
CP-130627 |
0263 |
1 |
Session-Priority AVP |
12.1.0 |
|
|
Jun 2014 |
CT#64 |
CP-140243 |
0264 |
2 |
Diameter Overload Control Over Cx |
12.2.0 |
|
|
Sep 2014 |
CT#65 |
CP-140515 |
0265 |
1 |
T-GRUU restoration |
12.3.0 |
|
|
Sep 2014 |
CT#65 |
CP-140506 |
0266 |
2 |
P-CSCF Restoration indication |
12.3.0 |
|
|
Dec 2014 |
CT#66 |
CP-140794 |
0268 |
2 |
P-CSCF Restoration mechanism new feature |
12.4.0 |
|
|
Dec 2014 |
CT#66 |
CP-140794 |
0270 |
1 |
P-CSCF Restoration mechanism new error |
12.4.0 |
|
|
Dec 2014 |
CT#66 |
CP-140773 |
0269 |
– |
M-bit clarification |
12.4.0 |
|
|
Mar 2015 |
CT#67 |
CP-150023 |
0273 |
1 |
SIP-Authentication-Scheme AVP encoding |
12.5.0 |
|
|
Jun 2015 |
CT#68 |
CP-150261 |
0274 |
– |
SAR-Flags inclusion in SAR command |
12.6.0 |
|
|
Sep 2015 |
CT#69 |
CP-150428 |
0276 |
1 |
SIP-Auth-Data-Item sub AVPs clarifications |
12.7.0 |
|
|
Sep 2015 |
CT#69 |
CP-150436 |
0275 |
1 |
Server-Assignment-Type AVP update to consider P-CSCF Restoration |
12.7.0 |
|
|
Dec 2015 |
CT#70 |
CP-150754 |
0279 |
2 |
Allowed WAF and/or WWSF Identities |
12.8.0 |
|
|
Dec 2015 |
CT#70 |
CP-150759 |
0281 |
1 |
Update reference to DOIC new IETF RFC |
12.8.0 |
|
|
Dec 2015 |
CT#70 |
CP-150768 |
0282 |
2 |
Support of the DRMP AVP over Cx/Dx |
13.0.0 |
|
|
2016-12 |
CT#74 |
CP-160664 |
0284 |
1 |
Correction to change IETF drmp draft version to official RFC 7944 |
13.1.0 |
|
|
2016-12 |
CT#74 |
CP-160681 |
0283 |
1 |
Load Control |
14.0.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0285 |
1 |
Update of reference for the Diameter base protocol |
14.1.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0286 |
– |
Cardinality of the Failed-AVP AVP in answer |
14.1.0 |
|
|
2017-06 |
CT#76 |
CP-171018 |
0288 |
1 |
Support for signaling transport level packet marking |
14.2.0 |
|
|
2018-06 |
CT#80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
|
2019-03 |
CT#83 |
CP-190035 |
0289 |
1 |
Reference Location Information change |
15.1.0 |
|
|
2019-09 |
CT#85 |
CP-192094 |
0293 |
2 |
draft-ietf-dime-load published as RFC 8583 |
15.2.0 |
|
|
2019-09 |
CT#85 |
CP-192125 |
0291 |
– |
Add P-CSCF subscription info to Restoration information |
16.0.0 |
|
|
2019-12 |
CT#86 |
CP-193040 |
0294 |
– |
S-CSCF restoration after registration timer expiry |
16.1.0 |
|
|
2020-06 |
CT#88e |
CP-201053 |
0295 |
– |
Support of PCRF-based P-CSCF restoration |
16.2.0 |
|
|
2021-12 |
CT#94e |
CP-213104 |
0297 |
– |
B |
Update of SIP Digest Access Authentication |
17.0.0 |
|
2022-03 |
CT#95e |
CP-220052 |
0300 |
– |
F |
Reference identity for RFC 7616 |
17.1.0 |
|
2022-03 |
CT#95e |
CP-220052 |
0301 |
2 |
B |
Support of the hash value for alternate SIP Digest algorithm |
17.1.0 |
|
2022-03 |
CT#95e |
CP-220054 |
0298 |
– |
B |
Failed P-CSCF |
17.1.0 |
|
2022-06 |
CT#96 |
CP-221041 |
0303 |
– |
F |
IMS authentication using AKAv2-SHA-256 digest AKA algorithm |
17.2.0 |