B.2 Service profile
29.2283GPPIP Multimedia (IM) Subsystem Cx and Dx InterfacesRelease 17Signalling flows and message contentsTS
The following picture gives an outline of the UML model of the Service Profile class:
Figure B.2.1: Service Profile
Each instance of the Service Profile class consists of the following classes:
– One or several instances of the Public-Identity class. PublicIdentity class contains the Public Identities associated with that service profile. The information in the CoreNetworkServicesAuthorization and InitialFilterCriteria classes apply to all PublicIdentification class instances, which are included in one ServiceProfile class.
– An optional instance of the CoreNetworkServicesAuthorization class. If no instance of the CoreNetworkServicesAuthorization class is present, no filtering related to subscribed media or restriction on IMS Communication Service Identifiers applies in the S-CSCF.
– Zero or several instances of the InitialFilterCriteria class.
Each instance of the Service Profile class contains the following attributes:
– Zero or more instances of the attribute SharedIFCSetID. A SharedIFCSetID attribute points to a set of Initial Filter Criteria locally administered and stored at the S-CSCF. Shared iFC Sets may be shared by several Service Profiles.
B.2.1 Public Identification
The following picture gives an outline of the UML model of Public Identification class:
Figure B.2.1.1: Public Identification
The attribute BarringIndication is of type Boolean. If it is absent, or if it is present and set to FALSE, the S-CSCF shall not restrict the use of that public user identity in any IMS communications. If it is present and set to TRUE, the S-CSCF shall prevent that public identity from being used in any IMS communication except registrations and re-registrations, as specified in TS 24.229 [8].
Public Identification class can contain an Identity attribute. The attribute IdentityType indicates the type of identity contained in each case. It could be either:
– A distinct Public User Identity
– A distinct Public Service Identity
– A Wildcarded Public Service Identity
– A non distinct Public User Identity, i.e. not explicitly provisioned in HSS.
– A Wildcarded Public User Identity
If the identity type is not present, it is assumed to be a distinct Public User Identity.
The attribute WildcardedPSI may be present (when IdentityType is WildcardedPSI) and contains the Wildcarded Public Service Identity that matched the Public Service Identity. This Wildcarded Public Service identity shall be sent as stored in the HSS, that is, including the delimiter described in TS 23.003 [17].
The attribute DisplayName allows a name to be associated with a Public Identity.
The attribute AliasIdentityGroupID indicates the Alias Public User Identity Set to which the Public User Identity belongs. If the "AliasInd" feature is supported, all Public User Identities shall have an AliasIdentityGroupID allocated. Within an IMS subscription Public User Identities that have the same AliasIdentityGroupID allocated shall be in the same implicit registration sets, and shall share their service profile and the same service data for each and every service, and shall be regarded as aliases of each other, as defined in the TS 23.008 [18]. If the "AliasInd" feature is not supported, all Public User Identities within an IMS subscription that are within the same implicit registration set and share their service profile shall be regarded aliases of each other.
The attribute WildcardedIMPU shall be present when IdentityType is a non distinct IMPU or it may be optionally present when IdentityType is a Wildcarded IMPU. It contains the Wildcarded Public User Identity that matched the Public User Identity. This Wildcarded Public User identity shall be sent as stored in the HSS, that is, including the delimiter described in TS 23.003 [17].
The attribute ServiceLevelTraceInfo provides the Service Level Tracing Information that is related to the Public User Identity. If the ServiceLevelTraceInfo is present, service level tracing shall be enabled in the S-CSCF for the related Public User Identity according to the configuration data received. If the ServiceLevelTraceInfo is not present, service level tracing is disabled in the S-CSCF for the related Public User Identity.
The attribute ServicePriorityLevel provides the Priority Level allowed for the Public User Identity, which can be used by the S-CSCF and other network elements for Priority Service.
The attribute PriorityNamespace provides the Namespace as specified in IETF RFC 4412 [22] and to which the Extended Priority refers.
The attribute PriorityLevel provides the Priority Level allowed for the Public User Identity, for the Extended Priority. Its value depends on the PriorityNamespace.
The attribute MaxNumOfAllowedSimultRegs provides the maximum number of allowed simultaneous registrations for the Public User Identity.
B.2.1A Core Network Service Authorization
The following picture gives an outline of the UML model of Core Network Service Authorization class:
Figure B.2.1A.1: Core Network Service Authorization
Each instance of the Core Network Service Authorization class contains zero or one instance of the class Subscribed Media Profile Id. If no instance of the class Subscribed Media Profile Id is present, no filtering related to subscribed media applies in S-CSCF. The Subscribed Media Profile Id is of type Integer and identifies a media profile in the S-CSCF for the authorization of media parameters.
Each instance of the Core Network Service Authorization class contains zero or one instance of the class List of Service Ids. If no instance of the class List of Service Ids is present, no restriction on IMS Communication Service Identifiers related applies in S-CSCF. Each instance of the class List of Service Ids contains zero or more instances of the class Service Id. The Service Id is of type String and identifies an IMS Communication Service Identifier that the subscriber is authorized to use.
B.2.2 Initial Filter Criteria
The following picture gives an outline of the UML model of Initial Filter Criteria class:
Figure B.2.2.1.1: Initial Filter Criteria
Each instance of the InitialFilterCriteria class includes the following attributes:
– One instance of Priority attribute that indicates the priority of the Filter Criteria. The higher the Priority Number the lower the priority of the Filter Criteria is; i.e., a Filter Criteria with a higher value of Priority Number shall be assessed after the Filter Criteria with a smaller Priority Number have been assessed. The same priority shall not be assigned to more than one initial Filter Criterion.
– An optional instance of ProfilePartIndicator attribute that is an enumerated type, with possible values "REGISTERED and UNREGISTERED, indicating if the iFC is a part of the registered or unregistered user profile. If ProfilePartIndicator is missing from the iFC, the iFC is considered to be relevant to both the registered and unregistered parts of the user profile, i.e. belongs to the common part of the user profile.
Each instance of the InitialFilterCriteria class consists of the following classes:
– An optional instance of TriggerPoint class that describes the trigger points that should be checked in order to find out if the indicated Application Server should be contacted or not. Each TriggerPoint is a boolean expression in Conjunctive or Disjunctive Normal form (CNF of DNF). The absence of Trigger Point instance will indicate an unconditional triggering to Application Server.
The attribute ConditionTypeCNF attribute defines how the set of SPTs are expressed, i.e. either an Ored set of ANDed sets of SPT statements or an ANDed set of Ored sets of statements. Individual SPT statements can also be negated. These combinations are termed, respectively, Disjunctive Normal Form (DNF) and Conjunctive Normal Form (CNF) for the SPT (see Annex C). Both DNF and CNF forms can be used. ConditionTypeCNF is a boolean that is TRUE when the Trigger Point associated with the FilterCriteria is a boolean expression in Conjunctive Normal Form (CNF) and FALSE if the Trigger Point is expressed in Disjunctive Normal Form (DNF) (see Annex C).
Each TriggerPoint class is composed by 1 to n instances of the SPT (ServicePointTrigger) class.
– One instance of ApplicationServer class that defines the application server, which is contacted, if the trigger points are met.
Each instance of the ApplicationServer class includes following attributes:
– One instance of ServerName attribute that is the SIP URL of the application server to contact.
– An optional instance of DefaultHandling attribute that determines whether the dialog should be released if the Application Server could not be reached or not; it is of type enumerated and can take the values: SESSION_CONTINUED or SESSION_TERMINATED.
– One optional instance of the ServiceInfo attribute. The ServiceInfo attribute allows to download to S-CSCF information that is to be transferred transparently to an Application Server when the trigger points of a filter criterion are satisfied. ServiceInfo is a string conveying that information. See TS 23.218 [6] for a description of the use of this information element.
Each instance of the ApplicationServer class includes following classes:
– One optional instance of the IncludeRegisterRequest class that indicates to the S-CSCF that the incoming SIP REGISTER request is to be transferred to an Application Server when the trigger points of a filter criterion are satisfied. See TS 23.218 [6] for a description of the use of this information element.
– One optional instance of the IncludeRegisterResponse class that indicates to the S-CSCF that the final SIP response to the incoming SIP REGISTER request is to be transferred to an Application Server when the trigger points of a filter criterion are satisfied. See TS 23.218 [6] for a description of the use of this information element.
B.2.3 Service Point Trigger
The following picture gives an outline of the UML model of Service Point Trigger class:
Figure B.2.3.1: Service Point Trigger
The attribute Group of the class Service Point Trigger allows the grouping of SPTs that will configure the sub-expressions inside a CNF or DNF expression. For instance, in the following CNF expression (A+B).(C+D), A+B and C+D would correspond to different groups.
In CNF, the attribute Group identifies the ORed sets of SPT instances. If the SPT belongs to different ORed sets, SPT can have more than one Group values assigned. At least one Group must be assigned for each SPT.
In DNF, the attribute Group identifies the ANDed sets of SPT instances. If the SPT belongs to different ANDed sets, SPT can have more than one Group values assigned. At least one Group must be assigned for each SPI.
The attribute ConditionNegated of the class Service Point Trigger defines whether the individual SPT instance is negated (i.e. NOT logical expression).
NOTE: The operator should be aware that a negated Session Case implies that all other available session cases are set. The list of session cases depends on the release and can even be increased in the future, then a negated Session Case may end up triggering ASs unexpectedly (e.g. NOT ORIGINATED_REGISTERED may trigger only TERMINATING_UNREGISTERED and TERMINATING_REGISTERED, or as well ORIGINATING_UNREGISTERED and ORIGINATING_CDIV).
The attribute RegistrationType of the class Service Point Trigger is relevant only to the SIP Method SPT with a value of "REGISTER" and its’ support is optional in the HSS and in the S-CSCF. The RegistrationType may contain a list of values that define whether the SPT matches to REGISTER messages that are related to initial registrations, re-registrations, and/or de-registrations. If RegistrationTypes are given, the SIP Method SPT with a value of "REGISTER" shall match if any of the RegistrationTypes match and the S-CSCF supports the RegistrationType attribute. If the SIP Method SPT contains value "REGISTER", and no RegistrationType is given, or if the S-CSCF does not support the RegistrationType attribute, the SIP Method SPT matches to all REGISTER messages. The attribute RegistrationType may be discarded if it is present in an SPT other than SIP Method with value "REGISTER".
Request-URI class defines SPT for the Request-URI. Request-URI contains attribute RequestURI.
SIP Method class defines SPT for the SIP method. SIP Method contains attribute Method which holds the name of any SIP method.
SIP Header class defines SPT for the presence or absence of any SIP header or for the content of any SIP header. SIP Header contains attribute Header which identifies the SIP Header, which is the SPT, and the Content attribute defines the value of the SIP Header if required.
The absence of the Content attribute and ConditionNegated = TRUE indicates that the SPT is the absence of a determined SIP header.
Session Case class represents an enumerated type, with possible values "Originating", "Terminating_Registered", "Terminating_Unregistered", "Originating_Unregistered", "Originating_CDIV" indicating whether the filter should be used by the S-CSCF handling the Originating, Terminating for a registered end user, Terminating for an unregistered end user, Originating for an unregistered end user, or Originating after Call Diversion services.
Session Description Information class defines SPT for the content of any SDP field within the body of a SIP Method. The Line attribute identifies the line inside the session description. Content is a string defining the content of the line identified by Line.
Annex C (informative):
Conjunctive and Disjunctive Normal Form
A Trigger Point expression is constructed out of atomic expressions (i.e. Service Point Trigger) linked by Boolean operators AND, OR and NOT. Any logical expression constructed in that way can be transformed to forms called Conjunctive Normal Form (CNF) and Disjunctive Normal Form (DNF).
A Boolean expression is said to be in Conjunctive Normal Form if it is expressed as a conjunction of disjunctions of literals (positive or negative atoms), i.e. as an AND of clauses, each of which is the OR of one of more atomic expressions.
Taking as an example the following trigger:
Method = "INVITE" OR Method = "MESSAGE" OR (Method="SUBSCRIBE" AND NOT Header = "from" Content = "joe")
The trigger can be split into the following atomic expressions:
Method="INVITE"
Method="MESSAGE"
Method="SUBSCRIBE"
NOT header="from" Content ="joe"
Grouping the atomic expressions, the CNF expression equivalent to the previous example looks like:
(Method="INVITE" OR Method = "MESSAGE" OR Method="SUBSCRIBE") AND (Method="INVITE" OR Method = "MESSAGE" OR (NOT Header = "from" Content = "joe"))
This result in two "OR" groups linked by "AND" (CNF):
(Method="INVITE" OR Method = "MESSAGE" OR Method="SUBSCRIBE")
(Method="INVITE" OR Method = "MESSAGE" OR (NOT Header = "from" Content = "joe"))
The XML representation of the trigger is:
<?xml version="1.0" encoding="UTF-8"?>
<IMSSubscription xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="CxDataType.xsd">
<PrivateID>IMPI1@homedomain.com</PrivateID>
<ServiceProfile>
<PublicIdentity>
<BarringIndication>1</BarringIndication>
<Identity> sip:IMPU1@homedomain.com </Identity>
</PublicIdentity>
<PublicIdentity>
<Identity> sip:IMPU2@homedomain.com </Identity>
</PublicIdentity>
<InitialFilterCriteria>
<Priority>0</Priority>
<TriggerPoint>
<ConditionTypeCNF>1</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>INVITE</Method>
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>MESSAGE</Method>
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>SUBSCRIBE</Method>
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>1</Group>
<Method>INVITE</Method>
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>1</Group>
<Method>MESSAGE</Method>
</SPT>
<SPT>
<ConditionNegated>1</ConditionNegated>
<Group>1</Group>
<SIPHeader>
<Header>From</Header>
<Content>"joe"</Content>
</SIPHeader>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:AS1@homedomain.com</ServerName>
<DefaultHandling>0</DefaultHandling>
</ApplicationServer>
</InitialFilterCriteria>
</ServiceProfile>
</IMSSubscription>
A Boolean expression is said to be in Disjunctive Normal Form if it is expressed as a disjunction of conjunctions of literals (positive or negative atoms), i.e. as an OR of clauses, each of which is the AND of one of more atomic expressions.
The previous example is already in DNF, composed by the following groups:
Method="INVITE"
Method="MESSAGE"
Method="SUBSCRIBE" AND (NOT header="from" Content ="joe")
The XML representation of the trigger is:
<?xml version="1.0" encoding="UTF-8"?>
<IMSSubscription xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="CxDataType.xsd">
<PrivateID>IMPI1@homedomain.com</PrivateID>
<ServiceProfile>
<PublicIdentity>
<BarringIndication>1</BarringIndication>
<Identity> sip:IMPU1@homedomain.com </Identity>
</PublicIdentity>
<PublicIdentity>
<Identity> sip:IMPU2@homedomain.com </Identity>
</PublicIdentity>
<InitialFilterCriteria>
<Priority>0</Priority>
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>INVITE</Method>
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>1</Group>
<Method>MESSAGE</Method>
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>2</Group>
<Method>SUBSCRIBE</Method>
</SPT>
<SPT>
<ConditionNegated>1</ConditionNegated>
<Group>2</Group>
<SIPHeader>
<Header>From</Header>
<Content>"joe"</Content>
</SIPHeader>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:AS1@homedomain.com</ServerName>
<DefaultHandling index="0">0</DefaultHandling>
</ApplicationServer>
</InitialFilterCriteria>
</ServiceProfile>
</IMSSubscription>
Annex D (informative):
High-level format for the User Profile
The way the information shall be transferred through the Cx interface can be seen from a high-level point of view in the following picture:
Figure D.1: Example of in-line format of user profile
If more than one service profile is created, for example to assign a different set of filters to public identifiers 1 and 2 and public identity 3, the information shall be packaged in the following way:
Figure D.2: Example of in-line format of user profile
Annex E (normative):
XML schema for the Cx interface user profile
The file CxDataType_Rel11.xsd, attached to this specification, contains the XML schema for the user profile that is sent over the Cx interface. The user profile XML schema defines that are used in the user profile XML. The data that is allowed to be sent in the user profile may vary depending on the features supported by the Diameter end points, see TS 29.229 [5]. The user profile XML schema file is intended to be used by an XML parser. The version of the Cx application sending the user profile XML shall be the same as the version of the sent user profile XML and thus it implies the version of the user profile XML schema to be used to validate it.
Table E.1 describes the data types and the dependencies among them that configure the user profile XML schema.
Table E.1: XML schema for the Cx interface user profile: simple data types
|
Data type |
Tag |
Base type |
Comments |
|
tPriority |
Priority |
integer |
>= 0 |
|
tProfilePartIndicator |
ProfilePartIndicator |
enumerated |
Possible values: 0 (REGISTERED) 1 (UNREGISTERED) |
|
tSharedIFCSetID |
SharedIFCSetID |
integer |
>= 0 |
|
tGroupID |
Group |
integer |
>= 0 |
|
tRegistrationType |
RegistrationType |
enumerated |
Possible values: 0 (INITIAL_REGISTRATION) 1 (RE-REGISTRATION) 2 (DE-REGISTRATION) |
|
tDefaultHandling |
DefaultHandling |
enumerated |
Possible values: 0 (SESSION_CONTINUED) 1 (SESSION_TERMINATED) |
|
tDirectionOfRequest |
SessionCase |
enumerated |
Possible values: 0 (ORIGINATING_REGISTERED) 1 TERMINATING_REGISTERED 2 (TERMINATING_UNREGISTERED) 3 (ORIGINATING_UNREGISTERED) 4 (ORIGINATING_CDIV) |
|
tPrivateID |
PrivateID |
anyURI |
Syntax described in IETF RFC 2486 [14] |
|
tSIP_URL |
Identity |
anyURI |
Syntax described in IETF RFC 3261 [11] or 3GPP TS 23003 (See Note 1) |
|
tTEL_URL |
Identity |
anyURI |
Syntax described in IETF RFC 3966 [15] or 3GPP TS 23003 (See Note 1) |
|
tIdentity |
Identity |
(union) |
Union of tSIP_URL, and tTEL_URL |
|
tIdentityType |
IdentityType |
enumerated |
Possible values: 0 (DISTINCT PUBLIC_USER_IDENTITY) 1 (DISTINCT_PSI) 2 (WILDCARDED_PSI) (See Note 2) 3 (NON_DISTINCT_IMPU) (See Note 3) 4 (WILDCARDED_IMPU) (See Note 4) |
|
tServiceInfo |
ServiceInfo |
string |
|
|
tString |
RequestURI, Method, Header, Content, Line, AccessType, AccessInfo, AccessValue |
string |
|
|
tBool |
ConditionTypeCNF, ConditionNegated, BarringIndication |
boolean |
Possible values: 0 (false) 1 (true) |
|
tSubscribedMediaProfileId |
SubscribedMediaProfileId |
integer |
>=0 |
|
tDisplayName |
DisplayName |
string |
|
|
tAliasIdentityGroupID |
AliasIdentityGroupID |
string |
|
|
tServiceLevelTraceInfo |
ServiceLevelTraceInfo |
string |
Syntax described in 3GPP TS 24.323 [32] |
|
tServicePriorityLevel |
ServicePriorityLevel |
enumerated |
Possible values: 0 (Highest priority) 1 2 3 4 (Lowest priority) |
|
tPriorityNamespace |
PriorityNamespace |
string |
Possible values are those of the namespaces that are defined in IETF RFC 4412 [22] or defined according to the IANA registration procedure described in IETF RFC 4412 [22] for Resource-Priority Namespaces. |
|
tPriorityLevel |
PriorityLevel |
string |
Possible values depend on the PriorityNamespace and are specified with the associated namespace that is defined in IETF RFC 4412 [22] or defined according to the IANA registration procedure described in IETF RFC 4412 [22] for Resource-Priority Namespaces |
|
tIMSI |
IMSI |
string |
Syntax described in 3GPP TS 23.003 [17]. ASCII encoded according to ANSI X3.4 [26]. |
|
tMaxNumOfAllowedSimultRegistrations |
MaxNumOfAllowedSimultRegistrations |
integer |
>= 1 |
|
NOTE 1: Only when the "Identity" tag is a Wildcarded Identity the syntax is described in 1 23.003 [17]. It applies to both WILDCARDED_IMPU and WILDCARDED_PSI. NOTE 2: Wildcarded PSI could optionally be included as well in tPublicIdentityExtension. NOTE 3: The IMPU is not explicitly provisioned in HSS. In this case, corresponding Wildcarded IMPU is included in tPublicIdentityExtension3. NOTE 4: WILDCARDED_IMPU indicates that the content of the identity in the "Identity" tag is a Wildcarded Public User Identity. In this case, Wildcarded IMPU could optionally be included as well in tPublicIdentityExtension3. |
|||
Table E.2: XML schema for the Cx interface user profile: complex data types
|
Data type |
Tag |
Compound of |
|||
|---|---|---|---|---|---|
|
Tag |
Type |
Cardinality |
|||
|
tIMSSubscription |
IMSSubscription |
PrivateID |
tPrivateID |
1 |
|
|
ServiceProfile |
tServiceProfile |
(1 to n) |
|||
|
Extension |
tIMSSubscriptionExtension |
(0 to 1) |
|||
|
tIMSSubscriptionExtension |
Extension |
IMSI |
tIMSI |
(0 to 1) |
|
|
Extension |
tIMSSubscriptionExtension2 |
(0 to 1) |
|||
|
tIMSSubscriptionExtension2 |
Extension |
ReferenceLocationInformation |
tReferenceLocationInformation |
(0 to n) |
|
|
tReferenceLocationInformation |
ReferenceLocationInformation |
AccessType |
tString (NOTE 4) |
(0 to 1) |
|
|
AccessInfo |
tString (NOTE 4) |
(0 to 1) |
|||
|
AccessValue |
tString (NOTE 4) |
(0 to 1) |
|||
|
tServiceProfile |
ServiceProfile |
PublicIdentity |
tPublicIdentity |
(1 to n |
|
|
CoreNetworkServicesAuthorization |
CoreNetworkServicesAuthorization |
(0 to 1 |
|||
|
InitialFilterCriteria |
tInitialFilterCriteria |
(0 to n) |
|||
|
Extension |
tServiceProfileExtension |
(0 to 1) |
|||
|
tServiceProfileExtension |
Extension |
SharedIFCSetID |
tSharedIFCSetID |
(0 to n) |
|
|
tCoreNetworkServicesAuthorization |
CoreNetworkServicesAuthorization |
SubscribedMediaProfileId |
tSubscribedMediaProfileId |
(0 to 1) |
|
|
Extension |
tCNServicesAuthorizationExtension |
(0 to 1) |
|||
|
tPublicIdentity |
PublicIdentity |
BarringIndication |
tBool |
(0 to 1) |
|
|
Identity |
tIdentity |
1 |
|||
|
Extension |
tPublicIdentityExtension |
(0 to 1) |
|||
|
tInitialFilterCriteria |
InitialFilterCriteria |
Priority |
tPriority |
1 |
|
|
TriggerPoint |
tTrigger |
(0 to 1) |
|||
|
ApplicationServer |
tApplicationServer |
1 |
|||
|
ProfilePartIndicator |
tProfilePartIndicator |
(0 to 1) |
|||
|
tTrigger |
TriggerPoint |
ConditionTypeCNF |
tBool |
1 |
|
|
SPT |
tSePoTri |
(1 to n) |
|||
|
tSePoTri |
SPT |
ConditionNegated |
tBool |
(0 to 1) |
|
|
Group |
tGroupID |
(1 to n |
|||
|
Choice of |
RequestURI |
tString |
1 |
||
|
Method |
tString |
1 |
|||
|
SIPHeader |
tHeader |
1 |
|||
|
SessionCase |
tDirectionOfRequest |
1 |
|||
|
SessionDescription |
tSessionDescription |
1 |
|||
|
Extension |
tSePoTriExtension |
(0 to 1) |
|||
|
tSePoTriExtension |
Extension |
RegistrationType |
tRegistrationType |
(0 to 2) |
|
|
tHeader |
SIPHeader |
Header |
tString |
1 |
|
|
Content |
tString |
(0 to 1) |
|||
|
tSessionDescription |
SessionDescription |
Line |
tString |
1 |
|
|
Content |
tString |
(0 to 1) |
|||
|
tApplicationServer |
ApplicationServer |
ServerName |
tSIP_URL |
1 |
|
|
DefaultHandling |
tDefaultHandling |
(0 to 1) |
|||
|
ServiceInfo |
tServiceInfo |
(0 to 1) |
|||
|
Extension |
tApplicationServerExtension |
(0 to 1) |
|||
|
tApplicationServerExtension |
Extension |
IncludeRegisterRequest |
tIncludeRegisterRequest |
(0 to 1) |
|
|
IncludeRegisterResponse |
tIncludeRegisterResponse |
(0 to 1) |
|||
|
tIncludeRegisterRequest |
IncludeRegisterRequest |
(NOTE 2) |
(NOTE 2) |
(0 to 1) |
|
|
tIncludeRegisterResponse |
tIncludeRegisterResponse |
(NOTE 2) |
(NOTE 2) |
(0 to 1) |
|
|
tPublicIdentityExtension |
Extension |
IdentityType |
tIdentityType |
(0 to 1) |
|
|
WildcardedPSI |
anyURI (NOTE 3) |
(0 to 1) |
|||
|
Extension |
tPublicIdentityExtension2 |
(0 to 1) |
|||
|
tPublicIdentityExtension2 |
Extension |
DisplayName |
tDisplayName |
(0 to 1) |
|
|
AliasIdentityGroupID |
tAliasIdentityGroupID |
(0 to 1) |
|||
|
Extension |
tPublicIdentityExtension3 |
(0 to 1) |
|||
|
tPublicIdentityExtension3 |
Extension |
WildcardedIMPU |
anyURI (NOTE 3) |
(0 to 1) |
|
|
ServiceLevelTraceInfo |
tServiceLevelTraceInfo |
(0 to 1) |
|||
|
ServicePriorityLevel |
ServicePriorityLevel |
(0 to 1) |
|||
|
Extension |
tPublicIdentityExtension4 |
(0 to 1) |
|||
|
tPublicIdentityExtension4 |
Extension |
ExtendedPriority |
tExtendedPriority |
(0 to n) |
|
|
Extension |
tPublicIdentityExtension5 |
(0 to 1) |
|||
|
tPublicIdentityExtension5 |
Extension |
MaxNumOfAllowedSimultRegistrations |
tMaxNumOfAllowedSimultRegistrations |
(0 to 1) |
|
|
tExtendedPriority |
ExtendedPriority |
PriorityNamespace |
tPriorityNamespace |
1 |
|
|
PriorityLevel |
tPriorityLevel |
1 |
|||
|
tCNServicesAuthorizationExtension |
Extension |
ListOfServiceIds |
tListOfServiceIds |
(0 to 1) |
|
|
tListOfServiceIds |
ListOfServiceIds |
ServiceId |
tString |
(0 to n) |
|
|
NOTE 1: "n" shall be interpreted as non-bounded. NOTE 2: empty cells shall be interpreted as complex XML elements without defined content. NOTE 3: the syntax of Wildcarded Public User Identity and Wildcarded Service Identity shall be as described in 3GPP TS 23.003 [17]. NOTE 4: the syntax of AccessType, AccessInfo and AccessValue is as described in 3GPP TS 24.229 [8] for P-Access-Network-Info header fields: AccessType corresponds to the "access-type" field whereas AccessInfo and AccessValue correspond to the type and associated value defined for the "access-info" field. NOTE 5: the HSS shall not send more than one instance of ReferenceLocationInformation and if the S-CSCF receives more than one instance of ReferenceLocationInformation it may arbitrarily pick one for further processing. |
|||||
Annex F (normative):
Definition of parameters for service point trigger matching
Table F.1 defines the parameters that are transported in the user profile XML.
Table F.1: Definition of parameters in the user profile XML
|
Tag |
Description |
|
RequestURI |
RequestURI tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clause 9 in IEEE 1003.1-2004 Part 1 [13]. For SIP URI, the regular expression shall be matched against the hostport of the SIP-URI. For definition of SIP-URI and hostport, see IETF RFC 3261 [11]. For Tel URI, the regular expression shall be matched against the telephone-subscriber of the telephone-uri. For definition of telephone-subscriber and telephone-uri, see IETF RFC 3966 [15]. |
|
SIPHeader |
A SIP Header SPT shall be evaluated separately against each header instance within the SIP message. The SIP Header SPT matches if at least one header occurrence matches the SPT. |
|
Header (of SIPHeader) |
Header tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clause 9 in IEEE 1003.1-2004 Part 1 [13]. The regular expression shall be matched against the header-name of the SIP header. For definition of header and header-name, see IETF RFC 3261 [11]. Before matching the header-name to the pattern, all SWSs shall be removed from the header-name and all LWSs in the header-name shall be reduced to a single white space character (SP). For definition of SWS and LWS, see IETF RFC 3261 [11]. |
|
Content (of SIPHeader) |
Content tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clause 9 in IEEE 1003.1-2004 Part 1 [13]. The regular expression shall be matched against the header-value of the SIP header. For definition of header and header-value, see IETF RFC 3261 [11]. If the SIP header contains several header-values in a comma-separated list, each of the header-value shall be matched against the pattern for the Content separately. Before matching the header-value to the pattern, all SWSs shall be removed from the header-value and all LWSs in the header-value shall be reduced to a single white space character (SP). For definition of SWS and LWS, see IETF RFC 3261 [11]. |
|
SessionDescription |
A Session Description SPT shall be evaluated separately against each SDP field instance within the SIP message. The Session Description SPT matches if at least one field occurrence matches the SPT. |
|
Line (of SessionDescription) |
Line tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clause 9 in IEEE 1003.1-2004 Part 1 [13]. The regular expression shall be matched against the type of the field inside the session description. For definition of type, see clause 6 in IETF RFC 4566 [12]. |
|
Content (of SessionDescription) |
Content tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clause 9 in IEEE 1003.1-2004 Part 1 [13]. The regular expression shall be matched against the value of the field inside the session description. For definition of value, see clause 6 in IETF RFC 4566 [12]. |
Annex G (normative):
Emergency registrations
S-CSCF and HSS shall handle emergency registrations as normal registrations with the following considerations:
– Upon emergency registration, following cases apply:
– If a normal registration for the same user does not exist, the S-CSCF shall download corresponding user profile from HSS, ensure that the HSS allocates S-CSCF name to this subscriber and the registration status is set to UNREGISTERED.
– Otherwise, the S-CSCF shall ensure that the registration status of the user is not changed in the HSS.
– Upon deregistration or expiration of the last normal session, if an emergency registration is still active for this subscriber, the S-CSCF shall ensure that the HSS keeps S-CSCF name allocated to this subscriber and the registration status is set to UNREGISTERED.
– Upon expiration of an emergency registration, the S-CSCF shall ensure the registration status of the user is not changed in the HSS if there are other normal registrations of the user. Otherwise, the S-CSCF may send SAR to the HSS to remove its name and set the registration status of the user to NOT REGISTERED.
– IMS Restoration procedures do not apply for IMS emergency sessions.
Annex H (normative):
Diameter overload control mechanism
H.1 General
Diameter overload control mechanism is an optional feature.
IETF RFC 7683 [24] specifies a Diameter overload control mechanism which includes the definition and the transfer of related AVPs between Diameter nodes.
It is recommended to make use of IETF RFC 7683 [24] on the Cx interface where, when applied, the I/S-CSCF shall behave as reacting nodes and the HSS as a reporting node.
Depending on regional/national requirements and network operator policy, priority traffic (e.g. MPS as described in TS 22.153 [25]) shall be exempted from throttling due to Diameter overload control up to the point where requested traffic reduction cannot be achieved without throttling the priority traffic.
H.2 HSS behaviour
The HSS requests traffic reduction from the I/S-CSCF when the HSS is in an overload situation, including OC-OLR AVP in answer commands as described in IETF RFC 7683 [24].
The HSS identifies that it is in an overload situation by implementation specific means. For example, the HSS may take into account the traffic over the Cx interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources, etc.
The HSS determines the specific contents of OC-OLR AVP in overload reports and the HSS decides when to send OC-OLR AVPs by implementation specific means.
H.3 I/S-CSCF behaviour
The I/S-CSCF applies required traffic reduction received in answer commands to subsequent applicable requests, as per IETF RFC 7683 [24].
The I/S-CSCF achieves requested traffic reduction by implementation specific means. For example, the I/S-CSCF may implement message throttling with prioritization or a message retaining mechanism for operations that can be postponed.
Diameter requests related to priority traffic (e.g. MPS) and emergency, detected via the presence of priority information (e.g., Resource-Priority header field for MPS) in SIP messages as described in TS 24.229 [8], have the highest priority. Depending on regional/national regulatory and operator policies, these Diameter requests shall be the last to be throttled, when the I/S-CSCF has to apply traffic reduction. Relative priority amongst various priority traffic (e.g. MPS) and emergency traffic is subject to regional/national regulatory and operator policies.
Annex I (Informative):
Diameter overload node behaviour
I.1 Message prioritization
This clause describes possible behaviours of the I/S-CSCF regarding message prioritisation in an informative purpose.
The I/S-CSCF may take the following into account when making throttling decisions:
– Identification of the procedures that can be deferred (e.g. Deregistration Request), so to avoid to drop non deferrable procedures;
– Prioritisation of certain types of request (e.g. between MAR and SAR for S-CSCF, and between LIR and UAR for I-CSCF) according to the context of their use, in particular:
– Higher prioritisation of SAR commands for S-CSCF that are related to a registered user for a service, so to avoid the interruption of the registered service for the user;
– Higher prioritisation of LIR commands for I-CSCF that are related to a requested service different from registration or deregistration, so to get more originating or terminating services provided to the user;
– Skipping of optional authentication.
– Priority level of a priority user (e.g., MPS user).
Annex J (normative):
Diameter message priority mechanism
J.1 General
IETF RFC 7944 [27] specifies a Diameter message priority mechanism that allows Diameter nodes to indicate the relative priority of Diameter messages. With this information, other Diameter nodes may leverage the relative priority of Diameter messages into routing, resource allocation, set the DSCP marking for transport of the associated Diameter message, and also abatement decisions when overload control is applied.
J.2 Cx/Dx interfaces
J.2.1 General
The Diameter message priority mechanism is an optional feature.
It is recommended to make use of IETF RFC 7944 [27] over the Cx/Dx interfaces of an operator network when the overload control defined in Annex H is applied on these Cx/Dx interfaces.
J.2.2 S-CSCF/I-CSCF behaviour
When the S-CSCF/I-CSCF supports the Diameter message priority mechanism, the S-CSCF/I-CSCF shall comply with IETF RFC 7944 [27].
The S-CSCF/I-CSCF sending a request shall determine the required priority according to its policies. When priority is required, the S-CSCF/I-CSCF shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level.
When the S-CSCF/I-CSCF receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request.
When the S-CSCF/I-CSCF receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, it may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response.
If:
– the S-CSCF/I-CSCF supports using the Diameter message priority mechanism for DSCP marking purposes,
– the transport network utilizes DSCP marking, and
– message-dependant DSCP marking is possible for the protocol stack transporting Diameter,
then the S-CSCF/I-CSCF shall set the DSCP marking for transport of the request or response according to the required priority level.
Diameter requests related to priority traffic (e.g. MPS as identified by the S-CSCF/I-CSCF through SIP procedures, emergency) shall contain a DRMP AVP with a high priority of which the level value is operator dependent.
When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific.
J.2.3 HSS/SLF behaviour
When the HSS/SLF supports the Diameter message priority mechanism, the HSS/SLF shall comply with IETF RFC 7944 [27].
The HSS/SLF sending a request shall determine the required priority according to its policies. When priority is required, the HSS/SLF shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level.
When the HSS/SLF receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request.
When the HSS/SLF receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, it may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response.
If:
– the HSS/SLF supports using the Diameter message priority mechanism for DSCP marking purposes,
– the transport network utilizes DSCP marking, and
– message-dependant DSCP marking is possible for the protocol stack transporting Diameter,
then the HSS/SLF shall set the DSCP marking for transport of the request or response according to the required priority level.
When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific.
J.2.4 Interactions
If the HSS supporting the Diameter message priority mechanism receives the request message containing both the Session-Priority AVP and DRMP AVP, the HSS shall prioritize the request according to priority level received within the DRMP AVP.
Annex K (normative):
Diameter load control mechanism
K.1 General
The Diameter load control mechanism is an optional feature.
It is recommended to make use of IETF IETF RFC 8583 [29] on the Cx interface where, when applied, the I-CSCF and the S-CSCF shall behave as reacting nodes and the HSS as a reporting node.
K.2 HSS behaviour
The HSS may report its current load by including a Load AVP of type HOST in answer commands as described in IETF IETF RFC 8583 [29].
The HSS calculates its current load by implementation specific means. For example, the HSS may take into account the traffic over the Cx interface or other interfaces, the level of usage of internal resources (e.g. CPU, memory), the access to external resources, etc.
The HSS determines when to send Load AVPs of type HOST by implementation specific means.
K.3 I-CSCF/S-CSCF behaviour
When performing next hop Diameter Agent selection for requests that are routed based on realm, the I-CSCF/S-CSCF may take into account load values from Load AVPs of type PEER received from candidate next hop Diameter nodes, as per IETF IETF RFC 8583 [29].
Annex L (informative):
Change history
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
New |
|
Jun 2002 |
CN#16 |
NP-020264 |
Version 2.0.0 approved at CN#16 |
5.0.0 |
|||
|
Sep 2002 |
CN#17 |
NP-020449 |
001 |
2 |
Clarification of implicit registration |
5.1.0 |
|
|
Sep 2002 |
CN#17 |
NP-020449 |
002 |
1 |
Clarification of user registration status query |
5.1.0 |
|
|
Sep 2002 |
CN#17 |
NP-020449 |
003 |
1 |
Clarification of HSS initiated update of user profile |
5.1.0 |
|
|
Sep 2002 |
CN#17 |
NP-020449 |
004 |
2 |
Clarification of MAR command |
5.1.0 |
|
|
Sep 2002 |
CN#17 |
NP-020449 |
005 |
1 |
Conditionality of the SIP-Auth-Data-Item in MAA command |
5.1.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
008 |
2 |
Rejection of registration of a Temporary Public Identity without active implicit registration |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
010 |
– |
Removal of upper bounds in Cx i/f user profile |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
011 |
– |
S-CSCF Assignment |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
012 |
– |
NAS-Session-Key AVPs in MAA command |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
013 |
1 |
Correction to detailed behaviour of user registration status query |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
014 |
1 |
Removing the DDF dependencies from Cx interface |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
015 |
1 |
Clarification of SERVER_CHANGE de-registration reason code |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020589 |
016 |
1 |
Clarification of User-Authorization-Type AVP usage within the UAR |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
017 |
1 |
Correction to HSS initiated update of user profile |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020588 |
019 |
– |
Correction in charging information |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020590 |
020 |
1 |
Error handling in S-CSCF when receiving too much data |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020587 |
021 |
1 |
Re-allocation of S-CSCF |
5.2.0 |
|
|
Dec 2002 |
CN#18 |
NP-020591 |
022 |
– |
Correction of the SPI |
5.2.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
025 |
1 |
Clarification of service profile download at service profile modification |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
028 |
– |
Filter ID field removal in InitialFilterCriteria class |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
030 |
1 |
Clarification of IMPU barring handling |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
032 |
1 |
The default public user identity in the Server-Assignment-Answer |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
034 |
2 |
Corrections to service profile |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
037 |
3 |
Handling of non supported data in the S-CSCF when the profile is being updated |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
024 |
1 |
Clarification of the HSS behaviour in REGISTRATION and DE_REGISTRATION procedures at IMPU checking time. |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
027 |
– |
Deletion of Annex F |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
029 |
– |
Clarification of User-Authorization-Type AVP usage within UAR |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
031 |
1 |
Update TS 29.228 after Diameter has become RFC |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
033 |
1 |
Replacement of the NAS-Session-Key AVP |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
035 |
2 |
Clarification on Re-allocation of S-CSCF |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
038 |
1 |
Change of SPI to SPT |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
040 |
1 |
Definition of the Subscribed Media Profile Identifier |
5.3.0 |
|
|
Mar 2003 |
CN#19 |
NP-030101 |
026 |
– |
Error in definition of Service Point of Interest class |
5.3.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
043 |
– |
Correct use of the Result-Code AVP |
5.4.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
044 |
1 |
Conditionality of User-Name AVP in Server-Assignment-Answer |
5.4.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
045 |
2 |
Corrections to the base 64 encoding examples |
5.4.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
046 |
1 |
Deregistration of implicitly registered public user identities |
5.4.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
047 |
– |
Clarification on the Server-Assignment-Type NO_ASSIGNMENT |
5.4.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
048 |
1 |
Incorrect use of result-code |
5.4.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
049 |
1 |
Misalignment in the Public-User-Identity IE |
5.4.0 |
|
|
Jun 2003 |
CN#20 |
NP-030215 |
050 |
1 |
Duplicated Destination-Host AVP within MAR command code |
5.4.0 |
|
|
Sep 2003 |
CN#21 |
NP-030383 |
042 |
3 |
Error in S-CSCF Assignment Type |
5.5.0 |
|
|
Sep 2003 |
CN#21 |
NP-030383 |
051 |
2 |
Mistakes in the XML schema of 29.228-540 |
5.5.0 |
|
|
Sep 2003 |
CN#21 |
NP-030383 |
055 |
1 |
Extensibility of the public identity structure in the XML schema |
5.5.0 |
|
|
Sep 2003 |
CN#21 |
NP-030394 |
041 |
2 |
Introduction of Presence Stage 3 (Px) to the Cx interface |
6.0.0 |
|
|
Sep 2003 |
CN#21 |
NP-030394 |
052 |
– |
Sharing public identities across multiple UEs |
6.0.0 |
|
|
Dec 2003 |
CN#22 |
NP-030585 |
057 |
3 |
Conditions for inclusion of Charging Information |
6.1.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
060 |
1 |
MAR in synchronisation failure case |
6.1.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
061 |
1 |
The S-CSCF name needs to be checked always in MAR |
6.1.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
063 |
– |
Conditional AVPs in answer commands |
6.1.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
065 |
1 |
Server-Assignment-Request |
6.1.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
067 |
– |
Determination of User-Authorization-Type AVP based on registration expiration |
6.1.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
069 |
2 |
Not registered state after deregistration with S-CSCF deleted at the HSS |
6.1.0 |
|
|
Dec 2003 |
CN#22 |
NP-030500 |
071 |
– |
The extensibility of the XML schema |
6.1.0 |
|
|
Dec 2003 |
CN#22 |
– |
Reference [9] updated |
6.1.0 |
|||
|
Mar 2004 |
CN#23 |
NP-040046 |
077 |
1 |
Clarification on S-CSCF-Name comparison |
6.2.0 |
|
|
Mar 2004 |
CN#23 |
NP-040055 |
081 |
– |
Error for missing identification in SAR command |
6.2.0 |
|
|
Mar 2004 |
CN#23 |
NP-040046 |
085 |
1 |
Conditions for inclusion of Public Identity in SAR |
6.2.0 |
|
|
Mar 2004 |
CN#23 |
NP-040046 |
087 |
1 |
Correction to sending the Charging-Information AVP |
6.2.0 |
|
|
Mar 2004 |
CN#23 |
NP-040046 |
089 |
– |
Correction to User-Authorization-Answer |
6.2.0 |
|
|
Mar 2004 |
CN#23 |
NP-040046 |
091 |
– |
Default handling of error cases during IMS registration |
6.2.0 |
|
|
Jun 2004 |
CN#24 |
NP-040215 |
097 |
2 |
Update of the charging addresses from HSS |
6.3.0 |
|
|
Jun 2004 |
CN#24 |
NP-040215 |
095 |
1 |
Content of the User Profile |
6.3.0 |
|
|
Jun 2004 |
CN#24 |
NP-040215 |
099 |
– |
Correction of SessionCase attribute ambiguity |
6.3.0 |
|
|
Sep 2004 |
CN#25 |
NP-040416 |
109 |
1 |
LIR and services related to unregistered state |
6.4.0 |
|
|
Sep 2004 |
CN#25 |
NP-040401 |
121 |
2 |
Triggering initial REGISTER messages |
6.4.0 |
|
|
Sep 2004 |
CN#25 |
NP-040401 |
118 |
1 |
XML versioning |
6.4.0 |
|
|
Sep 2004 |
CN#25 |
NP-040401 |
122 |
1 |
Optimization of User Profile Download |
6.4.0 |
|
|
Sep 2004 |
CN#25 |
NP-040396 |
124 |
2 |
Simplification of the User Profile Split concept |
6.4.0 |
|
|
Sep 2004 |
CN#25 |
NP-040416 |
120 |
3 |
Use of regular expressions |
6.4.0 |
|
|
Dec 2004 |
CN#26 |
NP-040523 |
138 |
1 |
HSS initiated deregistration with "not registered" registration state |
6.5.0 |
|
|
Dec 2004 |
CN#26 |
NP-040530 |
140 |
1 |
HSS initiated deregistration with user profile removal for permanent termination |
6.5.0 |
|
|
Dec 2004 |
CN#26 |
NP-040523 |
142 |
2 |
HSS initiated deregistration using the network initiated de-registration procedure |
6.5.0 |
|
|
Dec 2004 |
CN#26 |
NP-040530 |
146 |
1 |
Clarification of R6 authentication scheme |
6.5.0 |
|
|
Dec 2004 |
CN#26 |
NP-040523 |
150 |
– |
Regular Expressions |
6.5.0 |
|
|
Dec 2004 |
CN#26 |
NP-040530 |
155 |
– |
Correction to XML Root Element |
6.5.0 |
|
|
Dec 2004 |
CN#26 |
NP-040530 |
156 |
1 |
Modification of User-Data-Already-Available in SAR command. |
6.5.0 |
|
|
Dec 2004 |
CN#26 |
NP-040523 |
159 |
2 |
Handling of Information Element marked as (M), (C) or (O) |
6.5.0 |
|
|
Mar 2005 |
CN#27 |
NP-050030 |
166 |
– |
Avoiding undesired deregistration |
6.6.0 |
|
|
Mar 2005 |
CN#27 |
NP-050030 |
168 |
1 |
Correction to authentication procedures in not registered case |
6.6.0 |
|
|
Mar 2005 |
CN#27 |
NP-050037 |
170 |
3 |
Clarification of behaviour for Shared Public User Identities |
6.6.0 |
|
|
Mar 2005 |
CN#27 |
NP-050037 |
172 |
– |
Distribution of Cipher Key and Integrity Key |
6.6.0 |
|
|
Apr 2005 |
Editorial correction on figure figure A.4.1.1 and on clauses: 6.1.4.1, 6.2.2, B.2.1 and 6.2.1.1 |
6.6.1 |
|||||
|
Jun 2005 |
CT#28 |
CP-050086 |
181 |
– |
TEL-URI reference correction |
6.7.0 |
|
|
Jun 2005 |
CT#28 |
CP-050086 |
183 |
– |
Clarification on Server Capabilities |
6.7.0 |
|
|
Jun 2005 |
CT#28 |
CP-050086 |
185 |
– |
Incorrect Implementation of CR172 |
6.7.0 |
|
|
Jun 2005 |
CT#28 |
CP-050081 |
188 |
1 |
Clarification of the content of SIP-Authentication-Context |
6.7.0 |
|
|
Jun 2005 |
CT#28 |
CP-050086 |
192 |
– |
Syntax correction for XML |
6.7.0 |
|
|
Sep 2005 |
CT#29 |
CP-050422 |
196 |
– |
Authentication Registration with synchronization failure, Data requested from HSS |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050296 |
200 |
Correction to XML Schema for SharedIFCSet |
6.8.0 |
||
|
Sep 2005 |
CT#29 |
CP-050440 |
202 |
2 |
Private identities on the Cx |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050282 |
204 |
1 |
Charging-Information correction |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050296 |
207 |
1 |
Corrections to UAR and LIR for shared public identities |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050422 |
208 |
1 |
Behaviour of the Implicit Registration Set for the Unregistered state |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050296 |
210 |
– |
Change of stage 2 reference from Release 5 to Release 6 |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050294 |
211 |
– |
PSI Activation |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050271 |
213 |
2 |
Removal of redundant restrictions for one Public User Identity in SAR |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050296 |
216 |
– |
Error code clean up |
6.8.0 |
|
|
Sep 2005 |
CT#29 |
CP-050296 |
217 |
1 |
Clarification of User Profile update |
6.8.0 |
|
|
Dec 2005 |
CT#30 |
CP-050604 |
198 |
5 |
XML syntax correction |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050611 |
220 |
1 |
PSI impacts on the Cx Interface |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050611 |
221 |
3 |
Routing for PSIs Matching a Wildcarded PSI |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050611 |
222 |
2 |
Removal of overhead in Private Identities handling in RTR |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050605 |
229 |
2 |
Use-Data description corrections |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050605 |
232 |
2 |
S-CSCF assignment checking for notregistered state |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050605 |
236 |
4 |
RTR correction |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050605 |
238 |
1 |
PPR correction |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050611 |
239 |
1 |
Private User Id in RTR |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
CP-050611 |
246 |
1 |
Server capabilities associations with features |
6.9.0 |
|
|
Dec 2005 |
CT#30 |
Rel-7 version was created because of ETSI TISPAN references. |
7.0.0 |
||||
|
Mar 2006 |
CT#31 |
CP-060084 |
0243 |
1 |
SPT for mobile orig unregistered |
7.1.0 |
|
|
Mar 2006 |
CT#31 |
CP-060159 |
0247 |
2 |
Removal of the terms Mobile Originated and Mobile Terminated |
7.1.0 |
|
|
Mar 2006 |
CT#31 |
CP-060154 |
0254 |
– |
Alignment of Annex E with .xsd file |
7.1.0 |
|
|
Mar 2006 |
CT#31 |
CP-060154 |
0256 |
– |
Incorrect implementation of CR 0198 |
7.1.0 |
|
|
Mar 2006 |
CT#31 |
CP-060065 |
0260 |
2 |
Handling of unknown errors |
7.1.0 |
|
|
Mar 2006 |
CT#31 |
CP-060154 |
0263 |
2 |
Private User ID in PPR and RTR |
7.1.0 |
|
|
Mar 2006 |
CT#31 |
CP-060065 |
0269 |
– |
Message flow correction |
7.1.0 |
|
|
Mar 2006 |
CT#31 |
CP-060065 |
0274 |
– |
Default public-id and PPR |
7.1.0 |
|
|
Jun 2006 |
CT#32 |
CP-060302 |
0285 |
– |
S-CSCF reselection removal |
7.2.0 |
|
|
Jun 2006 |
CT#32 |
CP-060308 |
0290 |
3 |
Correction of the normative text in the table 6.7 |
7.2.0 |
|
|
Jun 2006 |
CT#32 |
CP-060308 |
0292 |
2 |
Using SiFC feature to define optional S-CSCF capabilities |
7.2.0 |
|
|
Sep 2006 |
CT#33 |
CP-060308 |
0296 |
– |
S-CSCF assignment correction |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060405 |
0299 |
– |
Default Public User ID either SIP URI or tel URI |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060399 |
0304 |
1 |
Barring Indication for public user identity |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060417 |
0306 |
2 |
Deletion of description about Authentication-Data-Item |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060399 |
0313 |
1 |
Registration message flow correction |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060417 |
0314 |
4 |
AS originating requests on behalf of a user |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060416 |
0317 |
2 |
Allowing a Display Name to be associated with a Public Identity. |
7.3.0 |
|
|
Sep 2006 |
CT#33 |
CP-060417 |
0320 |
– |
Update of the Table 6.7 "Guidelines for S-CSCF Capabilities" |
7.3.0 |
|
|
Dec 2006 |
CT#34 |
CP-060553 |
0325 |
1 |
SDP reference correction |
7.4.0 |
|
|
Dec 2006 |
CT#34 |
CP-060566 |
0326 |
1 |
New message flow about AS originating session |
7.4.0 |
|
|
Dec 2006 |
CT#34 |
CP-060566 |
0327 |
1 |
Correction of Private Identity description in SAR |
7.4.0 |
|
|
Dec 2006 |
CT#34 |
CP-060566 |
0330 |
3 |
Correction of error code in SAA |
7.4.0 |
|
|
Dec 2006 |
CT#34 |
CP-060566 |
0332 |
1 |
Clarification on use of Authentication pending flag |
7.4.0 |
|
|
Dec 2006 |
CT#34 |
CP-060566 |
0336 |
3 |
Optimization of handling of Wildcarded PSIs |
7.4.0 |
|
|
Dec 2006 |
CT#34 |
CP-060555 |
0338 |
1 |
Wildcarded PSI as key in PPR |
7.4.0 |
|
|
Dec 2006 |
CT#34 |
CP-060553 |
0342 |
1 |
Correction of the HSS behaviour in UAR/UAA command pair |
7.4.0 |
|
|
Dec 2006 |
CT#34 |
CP-060735 |
0343 |
3 |
Clarification regarding URI canonicalization – 29.228 |
7.4.0 |
|
|
Mar 2007 |
CT#35 |
CP-070020 |
0346 |
3 |
Clarification of the server name in LIA |
7.5.0 |
|
|
Mar 2007 |
CT#35 |
CP-070020 |
0350 |
3 |
User profile data synchronisation |
7.5.0 |
|
|
Mar 2007 |
CT#35 |
CP-070020 |
0352 |
– |
SAA result code correction |
7.5.0 |
|
|
Mar 2007 |
CT#35 |
CP-070019 |
0353 |
2 |
Removal of roaming restrictions for Emergency Registrations |
7.5.0 |
|
|
Mar 2007 |
CT#35 |
CP-070020 |
0354 |
– |
Definition and use of the Wildcarded PSI information element |
7.5.0 |
|
|
Jun 2007 |
CT#36 |
CP-070309 |
0358 |
1 |
Removal of editor’s note on IMS Recovery Procedures |
7.6.0 |
|
|
Jun 2007 |
CT#36 |
CP-070479 |
0359 |
2 |
Impacts of the IMS Communication Service Identifier |
7.6.0 |
|
|
Jun 2007 |
CT#36 |
CP-070309 |
0361 |
2 |
Clarification on LIA |
7.6.0 |
|
|
Jun 2007 |
CT#36 |
CP-070309 |
0365 |
1 |
Adding User-Authorization-Type is absent condition to UAR Detailed behaviour |
7.6.0 |
|
|
Jun 2007 |
CT#36 |
CP-070312 |
0367 |
– |
Modification to the tag RegistrationtType to RegistrationType in the Annex E |
7.6.0 |
|
|
Sep 2007 |
CT#37 |
CP-070520 |
0374 |
1 |
Authentication failure and timeout handling |
7.7.0 |
|
|
Sep 2007 |
CT#37 |
CP-070522 |
0378 |
– |
Incorrect implemented CR 120r3 |
7.7.0 |
|
|
Sep 2007 |
CT#37 |
CP-070527 |
0379 |
– |
User Data Already Available |
7.7.0 |
|
|
Nov 2007 |
CT#38 |
CP-070743 |
0388 |
1 |
Handling of USER_UNKNOWN and NOT_SUPPORTED_USER_DATA error in PPA |
7.8.0 |
|
|
Nov 2007 |
CT#38 |
CP-070744 |
0392 |
2 |
Alias |
7.8.0 |
|
|
Nov 2007 |
CT#38 |
CP-070755 |
0376 |
6 |
Updates to 29.228 for Digest on the Cx Interface |
8.0.0 |
|
|
Mar 2008 |
CT#39 |
CP-080019 |
0393 |
1 |
IMS Restoration after an S-CSCF failure |
8.1.0 |
|
|
Mar 2008 |
CT#39 |
CP-080022 |
0395 |
2 |
Update for Supporting NASS-Bundled-Authentication |
8.1.0 |
|
|
Mar 2008 |
CT#39 |
CP-080019 |
0398 |
– |
SIP Digest password push |
8.1.0 |
|
|
Mar 2008 |
CT#39 |
CP-080019 |
0400 |
1 |
Wildcarded Public User Identities |
8.1.0 |
|
|
Jun 2008 |
CT#40 |
CP-080261 |
0399 |
3 |
Originating services after call forwarding |
8.2.0 |
|
|
Jun 2008 |
CT#40 |
CP-080261 |
0406 |
XML example |
8.2.0 |
||
|
Jun 2008 |
CT#40 |
CP-080267 |
0408 |
Emergency Registration for REGISTRATION_AND_CAPABILITIES |
8.2.0 |
||
|
Jun 2008 |
CT#40 |
CP-080267 |
0410 |
Removal of restriction for barred user at Emergency Registrations |
8.2.0 |
||
|
Sep 2008 |
CT#41 |
CP-080456 |
0413 |
2 |
Emergency Public User Identity removal |
8.3.0 |
|
|
Sep 2008 |
CT#41 |
CP-080460 |
0420 |
1 |
Support of "Loose-Route" indication from HSS |
8.3.0 |
|
|
Sep 2008 |
CT#41 |
CP-080463 |
0421 |
Cx Impacts of IMS Restoration Procedures |
8.3.0 |
||
|
Sep 2008 |
CT#41 |
CP-080460 |
0423 |
2 |
Filter Criteria enhancement for 3rd party REGISTER |
8.3.0 |
|
|
Sep 2008 |
CT#41 |
CP-080463 |
0425 |
1 |
Addition of Registered Private Identities in SAA |
8.3.0 |
|
|
Sep 2008 |
CT#41 |
CP-080460 |
0426 |
1 |
Add Assigned S-CSCF name to SAA |
8.3.0 |
|
|
Dec 2008 |
CT#42 |
CP-080698 |
0427 |
2 |
Service Restoration for Registered IMPU |
8.4.0 |
|
|
Dec 2008 |
CT#42 |
CP-080707 |
0431 |
2 |
Support for IMS Service Level Trace |
8.4.0 |
|
|
Dec 2008 |
CT#42 |
CP-080708 |
0432 |
Removal of Digest Domain |
8.4.0 |
||
|
Dec 2008 |
CT#42 |
CP-080696 |
0433 |
3 |
Diameter Proxy Agent – an alternative User Identity to HSS resolution mechanism |
8.4.0 |
|
|
Dec 2008 |
CT#42 |
CP-080708 |
0434 |
2 |
S-CSCF and AS procedures with Enhanced Filter Criteria |
8.4.0 |
|
|
Mar 2009 |
CT#43 |
CP-090023 |
0435 |
1 |
Priority Service |
8.5.0 |
|
|
Mar 2009 |
CT#43 |
CP-090026 |
0436 |
1 |
Multiple Registrations in Registration |
8.5.0 |
|
|
Mar 2009 |
CT#43 |
CP-090036 |
0440 |
2 |
HSS Addresses |
8.5.0 |
|
|
Mar 2009 |
CT#43 |
CP-090025 |
0441 |
1 |
Loose Route Indication |
8.5.0 |
|
|
Mar 2009 |
CT#43 |
CP-090028 |
0442 |
2 |
Support for GPRS IMS Bundled Authentication (GIBA) in Cx |
8.5.0 |
|
|
Sep 2009 |
CT#45 |
CP-090728 |
0447 |
1 |
Incorrect CR implementation |
8.6.0 |
|
|
Dec 2009 |
CT#46 |
0452 |
1 |
Unregistered user clarification |
8.7.0 |
||
|
Dec 2009 |
CT#46 |
0456 |
2 |
Session-Priority AVP |
8.7.0 |
||
|
Dec 2009 |
CT#46 |
0457 |
2 |
HSS behaviour after PPA with unknown user |
8.7.0 |
||
|
Dec 2009 |
CT#46 |
0458 |
1 |
Check of the S-CSCF Name |
8.7.0 |
||
|
Dec 2009 |
CT#46 |
0460 |
IMPI must be sent in SAR for UE initiated requests |
8.7.0 |
|||
|
Dec 2009 |
CT#46 |
Upgraded unchanged from Rel-8 |
9.0.0 |
||||
|
Mar 2010 |
CT#47 |
CP-100033 |
0462 |
Default IMPU |
9.1.0 |
||
|
Mar 2010 |
CT#47 |
CP-100031 |
0468 |
1 |
Wildcarded Public Identity |
9.1.0 |
|
|
Mar 2010 |
CT#47 |
CP-100033 |
0470 |
1 |
Priority service attribute |
9.1.0 |
|
|
Mar 2010 |
CT#47 |
CP-100033 |
0474 |
1 |
User-Auth-Type not checked |
9.1.0 |
|
|
Mar 2010 |
CT#47 |
CP-100033 |
0476 |
1 |
GIBA is not allowed when auth. Scheme is Unknown |
9.1.0 |
|
|
Mar 2010 |
CT#47 |
CP-100042 |
0477 |
2 |
Clarification on the use of User-Data-Already-Available |
9.1.0 |
|
|
Mar 2010 |
CT#47 |
CP-100015 |
0482 |
Server Capabilities |
9.1.0 |
||
|
Mar 2010 |
CT#47 |
CP-100031 |
0466 |
RTR for wildcarded public user identity |
9.1.0 |
||
|
May 2010 |
Xml-file corrected |
9.1.1 |
|||||
|
Jun 2010 |
CT#48 |
CP-100412 |
0484 |
3 |
Table not aligned with XML schema for wildcarded identities |
9.2.0 |
|
|
Jun 2010 |
CT#48 |
CP-100412 |
0487 |
3 |
SAR with NO_ASSIGNMENT correction |
9.2.0 |
|
|
Jun 2010 |
CT#48 |
CP-100412 |
0489 |
2 |
Update of IETF Reference |
9.2.0 |
|
|
Sep 2010 |
CT#49 |
CP-100447 |
0493 |
2 |
Wildcarded Identities handling |
9.3.0 |
|
|
Sep 2010 |
CT#49 |
CP-100447 |
0495 |
Wrong order in table for XML schema |
9.3.0 |
||
|
Sep 2010 |
CT#49 |
CP-100447 |
0497 |
2 |
Cx-MAR handling correction in restoration procedures |
9.3.0 |
|
|
Sep 2010 |
CT#49 |
CP-100447 |
500 |
1 |
Ambiguity of Presence Conditions of IEs and AVP ABNF |
9.3.0 |
|
|
Sep 2010 |
CT#49 |
CP-100447 |
507 |
Correction for de-registration procedure at restoration |
9.3.0 |
||
|
Sep 2010 |
CT#49 |
CP-100447 |
504 |
2 |
Mandatory and optional capabilities handling |
9.3.0 |
|
|
Dec 2010 |
CT#50 |
CP-100668 |
0519 |
Coding of SIP-Authorization AVP and SIP-Authenticate AVP |
9.4.0 |
||
|
Dec 2010 |
CT#50 |
CP-100697 |
0509 |
1 |
Clarification on Alias |
10.0.0 |
|
|
Mar 2011 |
CT#51 |
CP-110044 |
0521 |
– |
Originating_CDIV Session Case including in XML |
10.1.0 |
|
|
Mar 2011 |
CT#51 |
CP-110060 |
0515 |
5 |
MPS over Cx |
10.1.0 |
|
|
Jun 2011 |
CT#52 |
CP-110349 |
0529 |
2 |
Handling of RTR for Emergency Registration |
10.2.0 |
|
|
Jun 2011 |
CT#52 |
CP-110356 |
0532 |
1 |
Emergency Restoration |
10.2.0 |
|
|
Jun 2011 |
CT#52 |
CP-110356 |
0535 |
– |
Incorrect Use of Result-Code AVP |
10.2.0 |
|
|
Jun 2011 |
CT#52 |
CP-110356 |
0538 |
1 |
Error in assignment type for backward compatibility scenarios |
10.2.0 |
|
|
Jun 2011 |
CT#52 |
CP-110383 |
0520 |
4 |
Reference Location over Cx interface |
11.0.0 |
|
|
Sep 2011 |
CT#53 |
CP-110566 |
0542 |
Priviledged sender |
11.1.0 |
||
|
Sep 2011 |
CT#53 |
CP-110566 |
0546 |
1 |
Public Identity in canonical form |
11.1.0 |
|
|
Dec 2011 |
CT#54 |
CP-110781 |
0552 |
1 |
Identity in the service profile |
11.2.0 |
|
|
Dec 2011 |
CT#54 |
CP-110781 |
0557 |
2 |
Providing the IMSI to the S-CSCF |
11.2.0 |
|
|
Dec 2011 |
CT#54 |
CP-110809 |
0553 |
1 |
Behaviour of HSS not supported IMS Restoration Procedures to LIR |
11.2.0 |
|
|
Mar 2012 |
CT#55 |
CP-120014 |
0562 |
1 |
Server-Capability AVP in LIA and UAA |
11.3.0 |
|
|
Mar 2012 |
CT#55 |
CP-120014 |
0566 |
1 |
Update of charging information and authentication data |
11.3.0 |
|
|
Jun 2012 |
CT#56 |
CP-120245 |
0558 |
2 |
Maximum Number of simultaneous registrations |
11.4.0 |
|
|
Sep 2012 |
CT#57 |
CP-120439 |
0576 |
1 |
Emergency registrations do not affect registration status |
11.5.0 |
|
|
Sep 2012 |
CT#57 |
CP-120456 |
0577 |
1 |
Add RequestURI parameter to SPT matching |
11.5.0 |
|
|
Nov 2012 |
The specification version number in the header corrected |
11.5.1 |
|||||
|
Dec 2012 |
CT#58 |
CP-120743 |
0578 |
– |
Experimental-Result-Code correction |
11.6.0 |
|
|
Dec 2012 |
CT#58 |
CP-120743 |
0582 |
3 |
PSI direct routing with restoration procedures |
11.6.0 |
|
|
Dec 2012 |
CT#58 |
CP-120743 |
0583 |
– |
Negated Session Case |
11.6.0 |
|
|
Mar 2013 |
CT#59 |
CP-130011 |
0593 |
1 |
Identities with emergency registration in RTR |
11.7.0 |
|
|
Mar 2013 |
CT#59 |
CP-130020 |
0599 |
1 |
Clarification on Reference Location information |
11.7.0 |
|
|
Jun 2013 |
CT#60 |
CP-130374 |
0600 |
1 |
Absent User-Name after S-CSCF recovery |
11.8.0 |
|
|
Sep 2013 |
CT#61 |
CP-130439 |
0606 |
2 |
Cancellation of the old S-CSCF for IMS Subscription and IMS Restoration Procedures |
11.9.0 |
|
|
Sep 2013 |
CT#61 |
CP-13046clause |
0601 |
– |
Correction on Emergency Registration |
12.0.0 |
|
|
Dec 2013 |
CT#62 |
CP-130627 |
0607 |
5 |
Cx Charging Information Download |
12.1.0 |
|
|
Jun 2014 |
CT#64 |
CP-140237 |
0609 |
2 |
Wildcarded Public Identity in SAA |
12.2.0 |
|
|
Jun 2014 |
CT#64 |
CP-140243 |
0611 |
2 |
Diameter Overload Control Over Cx |
12.2.0 |
|
|
Sep 2014 |
CT#65 |
CP-140506 |
0624 |
2 |
P-CSCF Restoration indication |
12.3.0 |
|
|
Sep 2014 |
CT#65 |
CP-140515 |
0626 |
– |
Clarification on REGISTRATION_AND_CAPABILITIES for De-registration |
12.3.0 |
|
|
Sep 2014 |
CT#65 |
CP-140515 |
0627 |
– |
Clarification on Unregistered User |
12.3.0 |
|
|
Dec 2014 |
CT#66 |
CP-140794 |
0628 |
2 |
HSS behaviour when P-CSCF Restoration indication is received |
12.4.0 |
|
|
Dec 2014 |
CT#66 |
CP-140790 |
0630 |
1 |
Priority Consideration for Diameter Overload Control |
12.4.0 |
|
|
Dec 2014 |
CT#66 |
CP-140777 |
0632 |
1 |
Addition of IMS-AKA based on HTTP Digest AKAv2 for WebRTC |
12.4.0 |
|
|
Mar 2015 |
CT#67 |
CP-150023 |
0639 |
1 |
IMSI Encoding over Cx |
12.5.0 |
|
|
Jun 2015 |
CT#68 |
CP-150251 |
0633 |
4 |
RTR handling when emergency registration |
12.6.0 |
|
|
Jun 2015 |
CT#68 |
CP-150251 |
0642 |
1 |
"Digest-AKAv1-MD5" is used as well for other Digest-AKA versions |
12.6.0 |
|
|
Jun 2015 |
CT#68 |
CP-150251 |
0643 |
Confidentiality-key is mandatory |
12.6.0 |
||
|
Jun 2015 |
CT#68 |
CP-150261 |
0640 |
– |
ADMINISTRATIVE_DEREGISTRATION with P-CSCF-Restoration-Indication |
12.6.0 |
|
|
July 2016 |
Correction of typo in previous line of history table. |
12.6.1 |
|||||
|
Sep 2015 |
CT#69 |
CP-150428 |
0647 |
1 |
Authentication tables and IE clarifications in MAR/MAA |
12.7.0 |
|
|
Sep 2015 |
CT#69 |
CP-150428 |
0649 |
– |
Wrong CR update |
12.7.0 |
|
|
Sep 2015 |
CT#69 |
CP-150432 |
0644 |
1 |
S-CSCF Restoration Information deletion with SAT=UNREGISTERED_USER |
12.7.0 |
|
|
Sep 2015 |
CT#69 |
CP-150436 |
0645 |
– |
P-CSCF Restoration when IMS Restoration is supported |
12.7.0 |
|
|
Dec 2015 |
CT#70 |
CP-150754 |
0653 |
2 |
Allowed WAF and/or WWSF Identities |
12.8.0 |
|
|
Dec 2015 |
CT#70 |
CP-150750 |
0654 |
1 |
Authentication Information IE clarification |
12.8.0 |
|
|
Dec 2015 |
CT#70 |
CP-150749 |
0655 |
1 |
De-registration without IMPI |
12.8.0 |
|
|
Dec 2015 |
CT#70 |
CP-150749 |
0656 |
1 |
IMSI change |
12.8.0 |
|
|
Dec 2015 |
CT#70 |
CP-150759 |
0658 |
1 |
Update reference to DOIC new IETF RFC |
12.8.0 |
|
|
Dec 2015 |
CT#70 |
CP-150775 |
0652 |
4 |
HSS supports IMS subscriptions corresponding to users managed by third parties |
13.0.0 |
|
|
Dec 2015 |
CT#70 |
CP-150768 |
0659 |
4 |
DRMP AVP Procedures over Cx/Dx |
13.0.0 |
|
|
Mar 2016 |
CT#71 |
CP-160031 |
0661 |
6 |
Introduction of AAA-1 interface |
13.1.0 |
|
|
Mar 2016 |
CT#71 |
CP-160046 |
0662 |
– |
De-registration of emergency registration correction |
13.1.0 |
|
|
Jun 2016 |
CT#72 |
CP-160215 |
0665 |
1 |
Diameter requests for priority traffic during overload control mechanism |
13.2.0 |
|
|
07-2016 |
Correction to spec version number on cover page |
13.2.1 |
|||||
|
09-2016 |
CT#73 |
CP-160431 |
0666 |
1 |
S-CSCF Restoration during Registration enhancement |
14.0.0 |
|
|
2016-12 |
CT#74 |
CP-160646 |
0673 |
2 |
Reference Location |
14.1.0 |
|
|
2016-12 |
CT#74 |
CP-160672 |
0674 |
1 |
Service Profile and iFC alignment between XML and text/UML |
14.1.0 |
|
|
2016-12 |
CT#74 |
CP-160681 |
0675 |
1 |
Load Control |
14.1.0 |
|
|
2016-12 |
CT#74 |
CP-160664 |
0677 |
– |
Correction to change IETF drmp draft version to official RFC 7944 |
14.1.0 |
|
|
2017-03 |
CT#75 |
CP-170045 |
0678 |
– |
Mission Critical Services |
14.2.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0679 |
1 |
Update of reference for the Diameter base protocol |
14.2.0 |
|
|
2017-06 |
CT#76 |
CP-171034 |
0680 |
1 |
IMS Trace (ISAT) Reference Updates |
14.3.0 |
|
|
2017-06 |
CT#76 |
CP-171018 |
0684 |
1 |
Support for signaling transport level packet marking |
14.3.0 |
|
|
2017-09 |
CT#77 |
CP-172012 |
0686 |
– |
Correction of DRMP Procedures |
14.4.0 |
|
|
2017-12 |
CT#78 |
CP-173011 |
0687 |
1 |
Cx Subscriber Deregistration Reason |
14.5.0 |
|
|
2018-06 |
CT#80 |
CP-181121 |
0688 |
1 |
Change of Reference Location Information |
15.0.0 |
|
|
2018-09 |
CT#81 |
CP-182069 |
0689 |
– |
P-CSCF restoration for 5GC |
15.1.0 |
|
|
2019-03 |
CT#83 |
CP-190035 |
0690 |
1 |
Reference Location Information change |
15.2.0 |
|
|
2019-09 |
CT#85 |
CP-192094 |
0693 |
2 |
draft-ietf-dime-load published as RFC 8583 |
15.3.0 |
|
|
2019-09 |
CT#85 |
CP-192150 |
0691 |
1 |
Wildcarded Public Identity in SAA |
16.0.0 |
|
|
2019-12 |
CT#86 |
CP-193047 |
0694 |
– |
RLOS related registrations |
16.1.0 |
|
|
2021-12 |
CT#94e |
CP-213104 |
0696 |
– |
B |
Update of SIP Digest Access Authentication |
17.0.0 |
|
2022-03 |
CT#95e |
CP-220052 |
0699 |
1 |
B |
Support of the hash value for alternate SIP Digest algorithm |
17.1.0 |
|
2022-03 |
CT#95e |
CP-220054 |
0697 |
– |
B |
Failed P-CSCF |
17.1.0 |