5 MCPTT Client Configuration
36.579-33GPPMission Critical (MC) services over LTEPart 3: Mission Critical Push To Talk (MCPTT) Server Application conformance specificationRelease 13TS
5.1 MCPTT Server – MCPTT Client / Configuration / Authentication / User Authorisation / UE Configuration / User Profile
5.1.1 Test Purpose (TP)
(1)
with { IUT (MCPTT Server) connected to PLMN1 }
ensure that {
when { the SS-UE1 (MCPTT client) activates an MCPTT application and requests MCPTT initialisation }
then { IUT (MCPTT Server) provides the initial UE configuration and performs MCPTT User Authentication and provides id_token, access_token and refresh token to the successfully authenticated user}
}
(2)
with { IUT (MCPTT Server) having authenticated the SS-UE1 (MCPTT client) }
ensure that {
when { the SS (MCPTT Client) initiates key management authorization }
then { IUT (MCPTT Server) provides identity management key material }
}
(3)
with { IUT (MCPTT Server) having provided identity management key material }
ensure that {
when { the SS-UE1 (MCPTT client) requests user service authorization }
then { IUT (MCPTT Server) responds to the SS (MCPTT Client) with SIP 200 (OK) messages }
}
(4)
with { IUT (MCPTT Server) having provided service authorization }
ensure that {
when { the SS-UE1 (MCPTT client) requests configuration management authorization}
then { IUT (MCPTT Server) responds to the SIP SUBSCRIBE message with a SIP 200 (OK) message and sends a SIP NOTIFY message containing the XCAP-URI of the documents and sends the MCPTT UE Configuration Document and MCPTT User Profile Configuration Document MCPTT Service Configuration Document via HTPP 200 (OK) messages in response to HTTP GET requests }
}
(5)
with { IUT (MCPTT Server) having provided user configuration data }
ensure that {
when { the SS-UE1 (MCPTT client) requests group management authorization }
then { IUT (MCPTT Server) responds to the SS (MCPTT Client) with SIP 200 (OK) messages and sends the XCAP-URI of the Group documents via a SIP NOTIFY message and sends the Group Document ‘MCPTT UE Configuration document’ via a HTPP 200 (OK) message in response to a HTTP GET request and sends the group key transport payloads (GKTP) document via a SIP NOTIFY message }
}
(6)
with { IUT (MCPTT Server) having provided all required configuration data }
ensure that {
when { the SS-UE1 (MCPTT client) requests to refresh its service settings }
then { IUT (MCPTT Server) responds to the SS (MCPTT Client) with a SIP 200 (OK) message }
}
5.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.482 clause 6.3.1, Annex A.2.1.3, Annex A.2.3, TS 24.484 clauses 4.3, 4.4, 6.2.3, 6.3.1.2, 6.3.2.3, 6.3.13.3.2.2, TS 24.481 clauses 6.2.4, 6.3.3.3, 6.3.13.3.2.2, TS 24.379 clauses 7.3.2, 7.3.3, 7.3.4, TS 33.179 clauses 5.6.1, 7.2.3, Annex D.1. Unless otherwise stated these are Rel-13 requirements.
[TS 24.482, clause 6.3.1]
Upon receipt of an OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and IETF RFC 6749 [5] via a secure TLS tunnel between the identity management client and the authorisation endpoint of the IdM server, the IdM server:
1) shall validate the received OIDC Authentication Request message as specified in the OpenID Connect 1.0 [6] and IETF RFC 6749 [5];
2) shall generate an HTTP 200 (OK) response according to IETF RFC 2616 [4] including form data to prompt the MCPTT user for their username and password credentials; and
NOTE 1: The username will be the MCPTT user’s MC ID.
3) shall send the HTTP 200 (OK) response towards the IdM client.
Upon receipt of an HTTP POST request method from the IdM client containing the MCPTT user’s username and password, the IdM server authenticates the MCPTT user and:
NOTE 2: Other methods of authentication can be used by the MCPTT service provider and are not defined by the OIDC specifications. 3GPP TS 33.179 [2] has defined username and password as a mandatory authentication method to be supported for MCPTT, hence a procedure to realize that method is included here.
1) shall generate an OIDC Authentication Response message as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:
a) shall generate an HTTP 302 (FOUND) response according to IETF RFC 2616 [4]; and
b) shall include the required parameters including the authorization_code as specified in 3GPP TS 33.179 [2] in the query component of the redirection URI contained in the Location header field of the HTTP FOUND request method using the "application/x-www-form-urlencoded" format as specified in W3C.REC-html401-19991224 [7]; and
2) shall send the HTTP 302 (FOUND) response towards the IdM client.
Upon receipt of an OIDC Token Request message via a secure TLS tunnel established between the identity management client and the token endpoint of the IdM server, the IdM server:
1) shall validate the OIDC Token Request message and if valid shall generate an OIDC Token Response message as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5] with the following clarifications:
a) shall generate an HTTP 200 (OK) response according to IETF RFC 2616 [4];
b) shall based on the received MC ID obtained from the received user authentication credentials, determine the MCPTT ID of the MCPTT user;
c) shall include an id_token, access_token and refresh_token and MCPTT ID as specified in 3GPP TS 33.179 [2]; and
d) shall include the other required parameters as specified in OpenID Connect 1.0 [6] and IETF RFC 6749 [5]; and
2) shall send the HTTP 200 (OK) response towards the IdM client.
[TS 24.482, Annex A.2.1.3]
The HTTP client in the network entity is configured with the following parameters:
1) a home HTTP proxy FQDN; and
2) a home HTTP proxy port.
The HTTP client in the network entity shall send and receive all HTTP messages via the home HTTP proxy.
The HTTP client in the network entity shall insert an X-3GPP-Asserted-Identity header field as specified in 3GPP TS 24.109 [15] in the HTTP request and shall set X-3GPP-Asserted-Identity header field to the identity of the HTTP client in the network entity. The identity of the HTTP client in the network entity can be a public service identity, an MCPTT group ID, or an MCPTT ID.
[TS 24.482, Annex A.2.3]
The HTTP server shall support the server role of IETF RFC 2616 [4].
Upon reception of an HTTP request:
1) if the received HTTP request does not contain an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in IETF RFC 6750 [14] and the received HTTP request does not contain an X-3GPP-Asserted-Identity header field as specified in 3GPP TS 24.109 [15], the HTTP server shall reject the request with HTTP 403 (Forbidden) response;
2) if the received HTTP request contains an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in IETF RFC 6750 [14];
a) the HTTP server shall validate the bearer access token as specified in IETF RFC 6750 [14]; and
b) the HTTP server shall consider the MCPTT ID derived from the bearer access token as the identity of the sender of the HTTP request; and
3) if the received HTTP request does not contain an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in IETF RFC 6750 [14] and the received HTTP request contains an X-3GPP-Asserted-Identity header field as specified in 3GPP TS 24.109 [15], the HTTP server shall consider the URI in the X-3GPP-Asserted-Identity header field as the identity of the sender of the HTTP request.
[TS 24.484, clause 4.3]
The MCPTT server obtains the MCPTT service configuration document that contains the mission critical organisation configured parameters that defined the behaviour of the MCPTT service from the configuration management server.
The format of the MCPTT service configuration document downloaded to the MCPTT server is defined in subclause 7.5.
The MCPTT server obtains the MCPTT service configuration document that contains the mission critical organisation configured parameters that defined the behaviour of the MCPTT service from the configuration management server.
The MCPTT server subscribes to the MCPTT service configuration document for each mission critical organisation that is provisioned that is supported by the MCPTT server using the procedure specified in subclause 6.3.13.2.3. How the MCPTT server is provisioned with the identities of the mission critical organisations is out of scope of the present document.
If the MCPTT service configuration document has been updated since the current version stored at the MCPTT server, then the MCPTT server will receive a SIP NOTIFY request containing an HTTPS URI of the MCPTT service configuration document. Retrieval by the MCPTT server, using the notified HTTPS URI, of the MCPTT service configuration document is performed as specified in subclause 6.3.3.2.3.
NOTE: The MCPTT server can be notified of changes to the MCPTT service management configuration document at any time while operating the MCPTT service.
The format of the MCPTT service configuration document downloaded to the MCPTT server is defined in subclause 7.5.
[TS 24.484, clause 4.4]
The following applies to the configuration management server used for online configuration.
The configuration management server needs to convert the MCPTT UE initial configuration document received from a MCPTT administrator into an appropriate format for configuration of the MCPTT UE initial configuration MO.
If the MCPTT UE initial configuration MO contains a <default-user-profile> element that identifies a MCPTT user profile configuration document, the configuration management server needs to convert the identified MCPTT user profile configuration document received from a MCPTT administrator into an appropriate format for configuration of the MCPTT user profile configuration MO.
Once an MCPTT User Profile configuration document has been created or updated by the MCPTT UE, the configuration management server uses the procedures specified in 3GPP TS 29.283 [7] to store MCPTT user profile configuration document as the user profile in the MCPTT user database.
In order to download MCPTT the user profile configuration document to an MCPTT UE or to support an MCPTT UE updating the MCPTT user profile configuration document, the configuration management server uses the procedures specified in 3GPP TS 29.283 [7] to obtain the MCPTT user profile from the MCPTT user database.
In order to be notified of changes to an MCPTT user profile configuration document that have been subscribed to by an MCPTT UE, the configuration management server uses the procedures specified in 3GPP TS 29.283 [7] to be notified of changes to the MCPTT user profile stored in the MCPTT user database.
In order to delete the MCPTT user profile when requested by an MCPTT UE, the configuration management server uses the procedures specified in 3GPP TS 29.283 [7] to delete the MCPTT user profile from the MCPTT user database.
NOTE: The configuration management server and group management server functionality for offline configuration is out of scope of the present document.
[TS 24.484, clause 6.2.3]
The MCPTT server shall send the HTTP request as specified for the HTTP client in the network entity in annex A of 3GPP TS 24.382 [6].
[TS 24.484, clause 6.2.4]
The CMS shall handle the HTTP request as specified for the HTTP server in annex A of 3GPP TS 24.382 [6].
The CMS shall be configured with an authorized MCPTT server list, containing public service identities of MCPTT servers of the MCPTT provider of the CMS.
When handling an HTTP request, the CMS shall determine the identity of the sender of the HTTP request as specified in 3GPP TS 24.382 [6], and shall use the identity of the sender of the HTTP request as an authenticated identity when performing the authorization.
[TS 24.484, clause 6.3.1.2]
A CMS shall support subclause 6.2.1 "Document Management", and subclause 6.2.4 "Access Permissions" of OMA OMA-TS-XDM_Core-V2_1 [2] and subclause 6.3.13.3 for accepting subscriptions to configuration management documents.
[TS 24.484, clause 6.3.2.3]
A CMS shall support receiving XML documents of the application usages specified in subclause 7.2.1, subclause 7.3.1, subclause 7.4.1 and subclause 7.5.1according to procedures specified in IETF RFC 4825 [14] "PUT Handling" where the Request-URI of the HTTP PUT request identifies an XML document and include the "auid" as per the appropriate application usage in clause 7.
[TS 24.484, clause 6.3.13.3.2.2]
Upon reception of an initial SIP SUBSCRIBE request:
a) with the Event header field set to xcap-diff;
b) with the Request-URI set to own public service identity for performing subscription proxy function of the CMS;
c) with a P-Asserted-Identity header field not containing an identity listed in the authorized MCPTT server list specified in subclause 6.2.4;
d) with an application/vnd.3gpp.mcptt-info+xml MIME body containing the <mcptt-access-token> element;
e) with an application/resource-lists+xml MIME body; and
f) with the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24 229 [12]), in a P-Asserted-Service header field according to IETF RFC 6050 [23];
the CMS:
a) if an <EncryptedData> XML tag is included in the application/vnd.3gpp.mcptt-info+xml MIME body and the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/vnd.3gpp.mcptt-info+xml MIME body;
b) if an <EncryptedData> XML tag is included in the application/resource-lists+xml MIME body and the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/resource-lists+xml MIME body;
c) shall identify the originating MCPTT ID from <mcptt-access-token> element received in the application/vnd.3gpp.mcpttinfo+xml MIME body and shall use the originating MCPTT ID as an authenticated identity when performing the authorization;
d) if the authenticated identity is not authorized to subscribe to notification of changes of any resource in the application/resource-lists+xml MIME body, shall reject the request with a SIP 403 (Forbidden) response and shall not continue with rest of the steps;
e) act as a notifier according to IETF RFC 5875 [11]. Additionally, if an XCAP URI in the "uri" attribute of the <entry> element of the application/resource-lists+xml MIME body of the initial SIP SUBSCRIBE request contains an "auid" parameter set to an application usage identifying a configuration management document as described in clause 7;
shall return the XCAP URI identifying the configuration management document in SIP NOTIFY requests associated with a subscription created as result of the received initial SIP SUBSCRIBE request.
Upon sending a SIP NOTIFY request associated with a subscription created as result of the received initial SIP SUBSCRIBE request, if the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, the CMS shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MCPTT server.
Upon reception of a SIP re-SUBSCRIBE request:
a) with the Event header field set to xcap-diff; and
b) with an application/resource-lists+xml MIME body;
the CMS:
a) if an <EncryptedData> XML tag is included in the application/resource-lists+xml MIME body of the received SIP re-SUBSCRIBE request and the CSK was received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/resource-lists+xml MIME body; and
b) act as a notifier according to IETF RFC 5875 [11]. Additionally, if an XCAP URI in the "uri" attribute of the <entry> element of the application/resource-lists+xml MIME body of the SIP re-SUBSCRIBE request contains an "auid" parameter set to an application usage identifying a configuration management document as described in clause 7:
and for which there is no related subscription established according to the subclause 6.3.13.3.2.3, shall return the XCAP URI identifying the configuration management document in SIP NOTIFY requests associated with a subscription created as result of the received initial SIP SUBSCRIBE request.
[TS 24.481, clause 6.2.4]
The MCPTT server shall send the HTTP request as specified for the HTTP client in the network entity in annex A of 3GPP TS 24.382 [10].
The MCPTT server shall perform the procedures in subclause 6.2.2 specified for GC.
[TS 24.481, clause 6.3.3.3]
A GMS shall support handling an HTTP GET request from a GMC according to procedures specified in IETF RFC 4825 [22] "GET Handling" where the Request-URI of the HTTP GET request identifies an XML document of the application usage specified in subclause 7.2.
[TS 24.481, clause 6.3.13.3.2.2]
Upon reception of an initial SIP SUBSCRIBE request:
a) with the Event header field set to xcap-diff;
b) with the Request-URI set to own public service identity for performing subscription proxy function of the GMS;
c) with a P-Asserted-Identity header field not containing an identity listed in the authorized MCPTT server list specified in subclause 6.2.5.1 and not containing an identity listed in the authorized GMS list as specified in subclause 6.2.5.1;
d) with an application/vnd.3gpp.mcptt-info+xml MIME body containing the <mcptt-access-token> element;
e) with an application/resource-lists+xml MIME body; and
f) with the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24 229 [12]), in a P-Asserted-Service header field according to IETF RFC 6050 [14];
the GMS:
a) if an <EncryptedData> XML tag is included in the application/vnd.3gpp.mcptt-info+xml MIME body and the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/vnd.3gpp.mcptt-info+xml MIME body;
b) if an <EncryptedData> XML tag is included in the application/resource-lists+xml MIME body and the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/resource-lists+xml MIME body;
c) shall identify the originating MCPTT ID from <mcptt-access-token> element received in the application/vnd.3gpp.mcptt-info+xml MIME body and shall use the originating MCPTT ID as an authenticated identity when performing the authorization;
d) if the authenticated identity is not authorized to subscribe to notification of changes of any resource in the application/resource-lists+xml MIME body, shall reject the request with a SIP 403 (Forbidden) response and shall not continue with rest of the steps;
e) act as a notifier according to IETF RFC 5875 [13]. Additionally, if an XCAP URI in the "uri" attribute of the <entry> element of the application/resource-lists+xml MIME body of the initial SIP SUBSCRIBE request identifies:
1) a group document addressed by a group ID as described in subclause 7.2.10.2 where the group ID is an MCPTT group ID owned by an MCPTT provider other than the MCPTT provider of the GMS; or
2) a element of an MCPTT GKTP document as described in subclause 7.7.10 where the group ID is an MCPTT group ID owned by an MCPTT provider other than the MCPTT provider of GMS;
shall perform the procedure in subclause 6.3.13.3.2.4 for each such MCPTT group ID and shall interwork information of received SIP NOTIFY requests in subclause 6.3.13.3.2.4 in SIP NOTIFY requests associated with a subscription created as result of the received initial SIP SUBSCRIBE request.
Upon sending a SIP NOTIFY request associated with a subscription created as result of the received initial SIP SUBSCRIBE request, if the CSK is received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, the GMS shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [5] for MCPTT server.
Upon reception of a SIP re-SUBSCRIBE request:
a) with the Event header field set to xcap-diff; and
b) with an application/resource-lists+xml MIME body;
the GMS:
a) if an <EncryptedData> XML tag is included in the application/resource-lists+xml MIME body of the received SIP re-SUBSCRIBE request and the CSK was received in an application/mikey MIME body of the initial SIP SUBSCRIBE request, shall decrypt the application/resource-lists+xml MIME body; and
b) act as a notifier according to IETF RFC 5875 [13]. Additionally, if an XCAP URI in the "uri" attribute of the <entry> element of the application/resource-lists+xml MIME body of the SIP re-SUBSCRIBE request identifies:
1) a group document addressed by a group ID as described in subclause 7.2.10.2 where the group ID is an MCPTT group ID owned by an MCPTT provider other than the MCPTT provider of the GMS; or
2) a element of an MCPTT GKTP document as described in subclause 7.7.10 where the group ID is an MCPTT group ID owned by an MCPTT provider other than the MCPTT provider of GMS;
and for which there is no related subscription established according to the subclause 6.3.13.3.2.4, shall perform the procedure in subclause 6.3.13.3.2.4 for each such MCPTT group ID and shall interwork information of received SIP NOTIFY requests in subclause 6.3.13.3.2.4 in SIP NOTIFY requests associated with a subscription created as result of the received initial SIP SUBSCRIBE request.
[TS 24.379, clause 7.3.2]
The MCPTT server shall support obtaining service authorization specific information from the SIP REGISTER request sent from the MCPTT client and included in the body of a third-party SIP REGISTER request.
NOTE 1: 3GPP TS 24.229 [4] defines how based on initial filter criteria the SIP REGISTER request sent from the UE is included in the body of the third-party SIP REGISTER request.
Upon receiving a third party SIP REGISTER request with a message/sip MIME body containing the SIP REGISTER request sent from the MCPTT client containing an application/vnd.3gpp.mcptt-info+xml MIME body with an <mcptt-access-token> element and an <mcptt-client-id> element within a message/sip MIME body of the SIP REGISTER request sent from the MCPTT client, the MCPTT server:
1) shall identify the IMS public user identity from the third-party SIP REGISTER request;
2) shall identify the MCPTT ID from the SIP REGISTER request sent from the MCPTT client and included in the message/sip MIME body of the third-party SIP REGISTER request by following the procedures in subclause 7.3.1A;
3) shall perform service authorization for the identified MCPTT ID as described in 3GPP TS 33.179 [46];
4) if service authorization was successful, shall bind the MCPTT ID to the IMS public user identity; and
NOTE 2: The MCPTT server will store the binding MCPTT ID, IMS public user identity and an identifier addressing the MCPTT server in an external database.
5) if a Resource-Share header field with the value "supported" is contained in the "message/sip" MIME body of the third-party REGISTER request, shall bind the MCPTT ID to the identity of the MCPTT UE contained in the "+g.3gpp.registration-token" header field parameter in the Contact header field of the incoming third-party REGISTER request.
[TS 24.379, clause 7.3.3]
The MCPTT server shall support obtaining service authorization specific information from a SIP PUBLISH request for MCPTT server settings.
Upon receiving a SIP PUBLISH request containing:
1) an Event header field set to the "poc-settings" value;
2) an application/poc-settings+xml MIME body; and
3) an application/vnd.3gpp.mcptt-info+xml MIME body containing an <mcptt-access-token> element and an <mcptt-client-id> element;
the MCPTT server:
1) shall identify the IMS public user identity from the P-Asserted-Identity header field;
2) shall perform the procedures in subclause 7.3.1A;
3) if the procedures in subclause 7.3.1A were not successful shall send a SIP 403 (Forbidden) response towards the MCPTT server with the warning text set to: "140 unable to decrypt XML content " in a Warning header field as specified in subclause 4.4, and not continue with the rest of the steps in this subclause;
4) shall perform service authorization for the identified MCPTT ID as described in 3GPP TS 33.179 [46];
5) if service authorization was successful:
a) shall bind the MCPTT ID to the IMS public user identity;
b) if a Resource-Share header field with the value "supported" was included in the "message/sip" MIME body of the third-party REGISTER request, shall bind the MCPTT ID to the identity of the MCPTT UE contained in the "+g.3gpp.registration-token" header field parameter in the Contact header field of the third-party REGISTER request that contained this IMS public user identity;
NOTE 1: The MCPTT server will store the binding MCPTT ID, IMS public user identity and an identifier addressing the MCPTT server in an external database.
c) shall download the MCPTT user profile from the MCPTT user database as defined in 3GPP TS 29.283 [73] if not already stored at the MCPTT server;
d) if multiple MCPTT user profiles are stored at the MCPTT server or downloaded for the MCPTT user from the MCPTT user database, shall determine the pre-selected MCPTT user profile by identifying the MCPTT user profile (see the MCPTT user profile document in 3GPP TS 24.384 [50]) in the collection of MCPTT user profiles that contains a <Pre-selected-indication> element; and
NOTE 2: If only one MCPTT user profile is stored at the MCPTT server or only one MCPTT user profile is downloaded from the MCPTT user database, then by default this MCPTT user profile is the pre-selected MCPTT user profile.
e) if an <ImplicitAffiliations> element is contained in the <OnNetwork> element of the MCPTT user profile document with one or more <entry> elements containing an MCPTT group ID (see the MCPTT user profile document in 3GPP TS 24.384 [50]) for the served MCPTT ID, shall perform implicit affiliation as specified in subclause 9.2.2.2.15;
6) if service authorization was not successful, shall send a SIP 403 (Forbidden) response towards the MCPTT server with the warning text set to: "101 service authorisation failed" in a Warning header field as specified in subclause 4.4, and not continue with the rest of the steps in this subclause;
7) shall process the SIP PUBLISH request according to rules and procedures of IETF RFC 3903 [37] and if processing of the SIP request was not successful, do not continue with the rest of the steps;
8) shall cache the received MCPTT service settings until the MCPTT service settings expiration timer expires;
9) shall send a SIP 200 (OK) response according 3GPP TS 24.229 [4]; and
10) shall use the Answer-Mode Indication setting in the <am-settings> element of the poc-settings event package as the current Answer-Mode Indication of the MCPTT client.
[TS 24.379, clause 7.3.4]
Upon receiving a SIP PUBLISH request containing:
1) an Event header field set to the "poc-settings" value;
2) an application/poc-settings+xml MIME body; and
3) an application/vnd.3gpp.mcptt-info+xml MIME body containing an <mcptt-request-uri> element and an <mcptt-client-id> element;
The MCPTT server:
1) shall identify the IMS public user identity from the P-Asserted-Identity header field;
2) shall perform the procedures in subclause 7.3.1A;
3) if the procedures in subclause 7.3.1A were not successful, shall send a SIP 403 (Forbidden) response towards the MCPTT server with the warning text set to: "140 unable to decrypt XML content" in a Warning header field as specified in subclause 4.4, and not continue with the rest of the steps in this subclause;
4) shall verify that a binding between the IMS public user identity in the Request-URI and the MCPTT ID in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml exists at the MCPTT server;
5) if a binding exists between the IMS public user identity and the MCPTT ID in the request and the validity period of the binding has not expired:
a) shall download the MCPTT user profile from the MCPTT user database as defined in 3GPP TS 29.283 [73] if not already stored at the MCPTT server;
b) if multiple MCPTT user profiles are stored at the MCPTT server or downloaded for the MCPTT user from the MCPTT user database, shall determine the pre-selected MCPTT user profile by identifying the MCPTT user profile (see the MCPTT user profile document in 3GPP TS 24.384 [50]) in the collection of MCPTT user profiles that contains a <Pre-selected-indication> element; and
NOTE: If only one MCPTT user profile is stored at the MCPTT server or only one MCPTT user profile is downloaded from the MCPTT user database, then by default this MCPTT user profile is the pre-selected MCPTT user profile.
c) if an <ImplicitAffiliations> element is contained in the <OnNetwork> element of the MCPTT user profile document with one or more <entry> elements containing an MCPTT group ID (see the MCPTT user profile document in 3GPP TS 24.384 [50]) for the served MCPTT ID, shall perform implicit affiliation as specified in subclause 9.2.2.2.15.
6) if a binding does not exist between the IMS public user identity and the MCPTT ID in the request or the binding exists, but the validity period of the binding has expired, shall reject the SIP PUBLISH request with a SIP 404 (Not Found) response and not continue with any of the remaining steps;
7) shall process the SIP PUBLISH request according to rules and procedures of IETF RFC 3903 [37] and if processing of the SIP request was not successful, do not continue with the rest of the steps;
8) shall cache the received MCPTT service settings until the MCPTT service settings expiration timer expires;
9) shall send a SIP 200 (OK) response according 3GPP TS 24.229 [4]; and
10) shall use the Answer-Mode Indication setting in the <am-settings> element of the poc-settings event package as the current Answer-Mode Indication of the MCPTT client.
[TS 33.179 clause 5.6.1]
For key management authorization, the KM client in the UE presents an access token to the KMS over HTTP. The KMS validates the access token and if successful, provides user specific key material back to the UE KM client based on the MCPTT ID of the user. This includes identity based key information used for media and signalling protection.
For user service authorization, the MCPTT client in the UE presents an access token to the MCPTT server over SIP. The MCPTT server validates the access token and if successful, authorizes the user for full MCPTT services and sends an acknowledgement back to the MCPTT client. The MCPTT server then maps and maintains the IMPU to MCPTT ID association. The MCPTT ID to IMPU association shall only be known to the application layer. The SIP message used to convey the access token from the MCPTT client to the MCPTT server may be either a SIP REGISTER or SIP PUBLISH message.
The UE can now perform configuration management authorization and download the user profile. Following the flow described in subclause 10.1.4.2 of 3GPP TS 23.179 [2] "MCPTT user obtains the user profile (UE initiated)", the Configuration Management (CM) client in the UE sends an access token in the user profile query to the Configuration Management server over HTTP. The CM server receives the request and validates the access token, and if valid, the CM server uses the MCPTT ID to obtain the user profile from the MCPTT user database. The CM server then sends the user profile back to the CM client over HTTP.
Upon receiving the user’s profile, the Group Management (GM) client in the UE can now perform group management authorization. The GM client obtains the user’s group membership information from the user’s profile, and following the flow shown in clause 10.1.5.2 of 3GPP TS 23.179 [2] "Retrieve group configurations at the group management client", the Group Management (GM) client in the UE sends an access token in the Get group configuration request to the host GM server of the group membership over HTTP. The GM server validates the access token, and if valid, completes the flow. As part of group management authorization, group key information is provided as per subclause 7.3.2 of the present document.
[TS 33.179 clause 7.2.3]
The procedure for the provision of identity-specific key material when the MCPTT proxy is supported between the KMS and the KMS client is described in figure 7.2.3-1. The procedure is the same whether the key management client in the MCPTT UE, MCPTT Server or group management server is making the request.
Figure 7.2.3-1: Provisioning of key material via the HTTP proxy
The procedure in figure 7.2.3-1 is now described step-by-step.
0) The key management client establishes a connection to the MCPTT KMS. As with other elements in the Common Services Core, the connection routed via, and secured by, the HTTP Proxy. The message flow below is within this secure connection.
NOTE: Additionally, the connection between the MCPTT KMS and the HTTP Proxy is secured according to clause 8.
1) The key management client makes a request for user key material from the MCPTT KMS. The request contains details of the identity (e.g. the MCPTT ID) requested for key management, and the time for which the key material is required.
2) The KMS provides a response containing key material. The response includes the type of key material, the period of use for the material and any domain-specific parameters required for its use. For public safety use, the key material itself shall be wrapped using a 256-bit transport key (TrK). The TrK is distributed via an out-of-band mechanism along with a 32-bit identifier, TrK-ID.
The procedure for the provisioning of identity-specific key material when the MCPTT proxy is not used between the KMS and the KMS client is as described in Figure 7.2.3-2.
Figure 7.2.3-2: Provisioning of key material without a proxy
The procedure in Figure 7.2.3-2 is now described step-by-step:
0) The key management client establishes a direct HTTPS connection to the MCPTT KMS. The following message flow is within this secure connection.
1) The key management client makes a request for user key material from the MCPTT KMS. The request contains details of the identity requested for key management, and the time at which the key material is required.
2) The KMS provides a response containing key material. The response includes the type of key material, the period of use for the material and any domain-specific parameters required for its use. Optionally, the key material itself may also be wrapped using a 256-bit transport key (TrK), distributed via an out-of-band mechanism along with a 32-bit identifier (TrK-ID).
As a result of this procedure, the key management client has securely obtained key material for use within the MCPTT system.
[TS 33.179 Annex D.1]
All KMS communications are made via HTTPS. The MCPTT key management client is provisioned via XML content in the KMS’s response. The XML content is designed to be extendable to allow KMS/client providers to add further information in the XML. Where the interface is extended, a different XML namespace should be used (so that may be ignored by non-compatible clients).
It is assumed that transmissions between the KMS and the key management client are secure and that the KMS has authenticated the identity of the key management client.
Additionally, to allow the transmission of key material securely between a secure element within the KMS and a secure element within the key management client, a security extension is defined which allows messages to be signed and key material to be encrypted using a shared Transport Key (TrK).
5.1.3 Test description
5.1.3.1 Pre-test conditions
System Simulator:
– SS-UE1 (MCPTT client)
– For the underlying "transport bearer" over which the SS-UE1 (MCPTT client) and the MCPTT Server will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in 3GPP TS 36.508 [22] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCPTT operation in the MCPTT configuration document).
IUT:
– IUT (MCPTT Server)
– The IUT (MCPTT Server) consists of all sub-systems of the Common Services Core, including the Group Management Server, the Configuration Management Server, the Key Management Server, the Identity Management Server, the HTTP Server, and the SIP AS. The IUT (MCPTT Server) also consists of all sub-systems of the MCPTT Server, including the Media Distribution Function, the MCPTT User Database, the SIP AS, the HTPP Server, the HTTP Client, and the Floor Control Server.
– The IUT (MCPTT Server) is the acting Participating Server and Controlling Server
Preamble:
– The IUT (MCPTT Server) is connected to PLMN1.
– The IUT (MCPTT Server) is connected to the SS-UE1 (MCPTT client) as defined in TS 36.579-1 [2], Figure 4.2.4.
5.1.3.2 Test procedure sequence
Table 5.1.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
0A |
The SS-UE1 (MCPTT client) sends an HTTP GET (initial UE configuration) request to retrieve the initial UE configuration from the Server. |
<– |
HTTP GET |
– |
– |
|
0B |
Check: Does the IUT (MCPTT Server) respond by sending an HTTP 200 (OK) including the initial UE configuration document? |
–> |
HTTP 200 (OK) |
1 |
P |
|
0C |
The SS-UE1 (MCPTT client) establishes a secure TLS tunnel as specified by 3GPP TS 33.310 [23] to the authorisation endpoint of the IdM server as specified in 3GPP TS 33.180 [24] using the configured URL of the authorisation endpoint of the IdM server as specified in the "<x>/OnNetwork/AppServerInfo/IDMSAuthEndpoint" leaf node, Table 5.5.8.1-1, TS 36.579-1 [2]. |
– |
– |
– |
– |
|
1 |
The SS-UE1 (MCPTT client) sends an OpenID Connect Authentication Request using HTTP POST |
<– |
HTTP POST (Authorization) |
– |
– |
|
2 |
Check: Does the IUT (MCPTT Server) respond by sending an HTTP 200 (OK) including the HTML form requesting username and password? |
–> |
HTTP 200 (OK) |
1 |
P |
|
3 |
The SS-UE1 (MCPTT client) sends an HTTP POST Request message to the SS containing user name and password |
<– |
HTTP POST |
– |
– |
|
4 |
Check: Does the IUT (MCPTT Server) send an HTTP 302 (Found) as the OpenID Connect Authentication Response? |
–> |
HTTP 302 (Found) |
1 |
P |
|
5 |
The SS-UE1 (MCPTT client) establishes a secure TLS tunnel as specified by 3GPP TS 33.310 [23] to the token endpoint of the IdM server as specified in 3GPP TS 33.180 [24] using the configured URL of the token endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSTokenEndpoint" leaf node, Table 5.5.8.1-1, TS 36.579-1 [2] |
– |
– |
– |
– |
|
6 |
The SS-UE1 (MCPTT client) sends an HTTP POST Request message to the IUT (MCPTT Server) over the TLS connection established to the IdM token endpoint (OIDC Token Request message) passing the authorization code sent in step 4. |
<– |
HTTP POST |
– |
– |
|
7 |
Check: Does the IUT (MCPTT Server) send an HTTP 200 (OK) providing id_token, access_token and refresh token? |
–> |
HTTP 200 (OK) |
1 |
P |
|
7A |
The SS-UE1 (MCPTT client) establishes a secure TLS tunnel as specified by 3GPP TS 33.310 [23] to the HTTP Proxy as specified in 3GPP TS 33.180 [24] using the configured URL of the HTTP Proxy as specified in the "/<x>/OnNetwork/AppServerInfo/HTTPproxy" leaf node, Table 5.5.8.1-1, TS 36.579-1 [2] |
– |
– |
– |
– |
|
8 |
The SS-UE1 (MCPTT client) sends an HTTP POST message presenting an access token sent in step 7 for Key Management Initialisation. |
<– |
HTTP POST |
– |
– |
|
9 |
Check: Does the IUT (MCPTT Server) respond by sending identity-specific key information? |
–> |
HTTP 200 (OK) |
2 |
P |
|
10 |
The SS-UE1 (MCPTT client) sends an HTTP POST message presenting an access token for Key Material Request |
<– |
HTTP POST |
– |
– |
|
11 |
Check: Does the IUT (MCPTT Server) respond by sending identity-specific key information? |
–> |
HTTP 200 (OK) |
2 |
P |
|
12 |
The SS-UE1 (MCPTT client) sends a SIP REGISTER request for service authorisation |
<– |
SIP REGISTER |
– |
– |
|
13 |
Check: Does the IUT (MCPTT Server) respond by sending an SIP 200 (OK) message? |
–> |
SIP 200 (OK) |
3 |
P |
|
14 |
The SS-UE1 (MCPTT client) sends a SIP SUBSCRIBE – subscription to multiple documents simultaneously – containing the access token and a resource list mime body containing a list of the following documents: MCPTT UE Configuration document, MCPTT User Profile Configuration Document, and the MCPTT Service configuration document. The base URI of each list entry is set to the CMS XCAP-ROOT-URI |
<– |
SIP SUBSCRIBE |
– |
– |
|
15 |
Check: Does the IUT (MCPTT Server) respond by sending an SIP 200 (OK) message? |
–> |
SIP 200 (OK) |
4 |
P |
|
16 |
Check: Does the IUT (MCPTT Server) send a SIP NOTIFY message containing the XCAP-URI of the documents? |
–> |
SIP NOTIFY |
4 |
P |
|
17 |
The SS-UE1 (MCPTT client) responds with a SIP 200 (OK) message |
<– |
SIP 200 (OK) |
– |
– |
|
18 |
The SS-UE1 (MCPTT client) sends an HTTP GET Request message that contains the access token and the XCAP-URI of the MCPTT UE Configuration document |
<– |
HTTP GET |
– |
– |
|
19 |
Check: Does the IUT (MCPTT Server) send the HTTP 200 (OK) message including the MCPTT UE Configuration Document? |
–> |
HTTP 200 (OK) |
4 |
P |
|
20 |
The SS-UE1 (MCPTT client) sends an HTTP GET Request message that contains the access token and the XCAP-URI of the MCPTT User Profile Configuration Document |
<– |
HTTP GET |
– |
– |
|
21 |
Check: Does the IUT (MCPTT Server) send the HTTP 200 (OK) message including the MCPTT User Profile Configuration Document? |
–> |
HTTP 200 (OK) |
4 |
P |
|
22 |
The SS-UE1 (MCPTT client) sends an HTTP GET Request message that contains the access token and the XCAP-URI of the MCPTT Service Configuration Document |
<– |
HTTP GET |
– |
– |
|
23 |
Check: Does the IUT (MCPTT Server) send the HTTP 200 (OK) message including the MCPTT Service Configuration Document? |
–> |
HTTP 200 (OK) |
4 |
P |
|
24 |
The SS-UE1 (MCPTT client) sends a SIP SUBSCRIBE containing the access token and a resource list mime body and a list of the Groups to be obtained. The base URI of each list entry is set to the GMS XCAP-ROOT-URI, and the MCPTT group ID identifies a group document |
<– |
SIP SUBSCRIBE |
– |
– |
|
25 |
Check: Does the IUT (MCPTT Server) respond with a HTTP 200 (OK) message |
–> |
SIP 200 (OK) |
5 |
P |
|
26 |
Check: Does the IUT (MCPTT Server) send a SIP NOTIFY message to the UE that contains the XCAP-URI of the Group documents? |
–> |
SIP NOTIFY |
5 |
P |
|
27 |
The SS-UE1 (MCPTT client) sends a SIP 200 (OK) message |
<– |
SIP 200 (OK) |
– |
– |
|
28 |
The SS-UE1 (MCPTT client) sends an HTTP GET Request message that contains the access token and the XCAP-URI of the Group Configuration document |
<– |
HTTP GET |
– |
– |
|
29 |
Check: Does the IUT (MCPTT Server) send an HTTP 200 (OK) message including the Group Document ‘MCPTT UE Configuration document’? |
–> |
HTTP 200 (OK) |
5 |
P |
|
29A |
Check: Does the IUT (MCPTT Server) send a SIP NOTIFY message to the UE that contains the group key transport payloads (GKTP) document. |
–> |
SIP NOTIFY |
5 |
P |
|
29B |
The SS-UE1 (MCPTT client) sends a SIP 200 (OK) message |
<– |
SIP 200 (OK) |
– |
– |
|
30 |
The SS-UE1 (MCPTT client) sends a SIP PUBLISH request for update of PoC-settings. NOTE: The PoC-settings document contains the user profile index of the selected user profile. |
<– |
SIP PUBLISH |
– |
– |
|
31 |
Check: Does the IUT (MCPTT Server) send a SIP 200 (OK)? |
–> |
SIP 200 (OK) |
6 |
P |
|
32-33 |
Void |
— |
– |
– |
– |
5.1.3.3 Specific message contents
Table 5.1.3.3-1: HTTP POST (Step 1, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.3-1, condition AUTH |
Table 5.1.3.3-2: HTTP POST (Step 3, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.3-1, condition USERAUTH |
Table 5.1.3.3-3: HTTP POST (Step 6, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.3-1, condition TOKEN |
Table 5.1.3.3-4: HTTP POST (Step 8, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.3-1, condition KMSINIT. |
Table 5.1.3.3-5: HTTP POST (Step 10, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.3-1, condition KMSKEY. |
Table 5.1.3.3-5A: HTTP 200 (OK) (Step 0B, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition UEINITIALCONFIG |
Table 5.1.3.3-6: HTTP 200 (OK) (Step 2, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1 |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Content-Type |
||||
|
media-type |
"text/html" |
RFC 2854 [111] |
||
|
Message-body |
||||
|
HTML form |
<!DOCTYPE html> <html> <body> <form action="/idms/userauth" method="post"> Username: <input type="text" name="user"><br> Password: <input type="password" name="password"><button type="submit">Login</button> </form> </body> </html> |
"/idms/userauth" given by tsc_MCX_IdMS_userauth_UriPath is the URI to be used by the UE as request URI in the HTTP POST request for user authentication |
HTML 4.01 Specification [105] |
|
Table 5.1.3.3-7: HTTP 200 (OK) (Step 7, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition TOKEN |
Table 5.1.3.3-8: HTTP 200 (OK) (Step 9, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition KMSINIT. |
Table 5.1.3.3-9: HTTP 200 (OK) (Step 11, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition KMSKEY. |
Table 5.1.3.3-10: HTTP 200 (OK) (Step 19, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition UECONFIG. |
Table 5.1.3.3-11: HTTP 200 (OK) (Step 21, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition UEUSERPROF. |
Table 5.1.3.3-12: HTTP 200 (OK) (Step 23, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition UESERVCONFIG. |
Table 5.1.3.3-13: HTTP 200 (OK) (Step 29, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.6-1, condition GROUPCONFIG. |
Table 5.1.3.3-14: HTTP 302 (Found) (Step 4, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.8-1, condition AUTH. |
Table 5.1.3.3-14A: HTTP GET (Step 0A, Table 5.1.3.2-1)
|
Derivation Path: Table 5.5.4.2-1, condition UEINITIALCONFIG |
Table 5.1.3.3-15: HTTP GET (Step 18, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.2-1, condition UECONFIG. |
Table 5.1.3.3-16: HTTP GET (Step 20, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.2-1, condition UEUSERPROF. |
Table 5.1.3.3-17: HTTP GET (Step 22, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.2-1, condition UESERVCONFIG. |
Table 5.1.3.3-18: HTTP GET (Step 28, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.4.2-1, condition GROUPCONFIG |
Table 5.1.3.3-19: SIP REGISTER (Step 12, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.13-1, condition SIP_REGISTER_INITIAL, CONFIG |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Request-Line |
||||
|
Request-URI |
tsc_MCPTT_PublicServiceId_B |
SIP URI of the home domain name |
||
Table 5.1.3.3-20: SIP SUBSCRIBE (Step 14, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1, condition CONFIG |
Table 5.1.3.3-20A: SIP SUBSCRIBE (Step 24, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.14-1, condition GROUPCONFIG |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Message-body |
||||
|
MIME body part |
Resource lists |
|||
|
MIME-part-body |
Resource-lists as described in Table 5.1.3.3-20B |
|||
Table 5.1.3.3-20B: Resource-lists in SIP SUBSCRIBE (Table 5.1.3.3-20A)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.3.1-1, condition GROUPCONFIG |
Table 5.1.3.3-21: SIP NOTIFY (Step 16, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1, condition CONFIG |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Contact |
||||
|
addr-spec |
||||
|
user-info and host |
tsc_MCPTT_PublicServiceId_B |
|||
Table 5.1.3.3-21A: SIP NOTIFY (Step 26, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1, condition GROUPCONFIG |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Contact |
||||
|
addr-spec |
||||
|
user-info and host |
tsc_MCPTT_PublicServiceId_B |
|||
Table 5.1.3.3-21B: SIP NOTIFY (Step 29A, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.8-1, condition GROUPCONFIG |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Contact |
||||
|
addr-spec |
||||
|
user-info and host |
tsc_MCPTT_PublicServiceId_B |
|||
|
Message-body |
||||
|
xcap-diff document |
xcap-diff document as described in Table 5.1.3.3-21C |
|||
Table 5.1.3.3-21C: Xcap-Diff Document (Table 5.1.3.3-21B)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.12-2, condition GROUPKEY |
Table 5.1.3.3-22: SIP PUBLISH (Step 30, Table 5.1.3.2-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.11-1, condition POC-SETTINGS-EVENT |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Request-Line |
||||
|
Request-URI |
tsc_MCPTT_PublicServiceId_B |
The public service identity identifying the originating participating MCPTT function serving the MCPTT user |
||
Table 5.1.3.3-23: Void
Table 5.1.3.3-24: SIP 200 (OK) (Steps 13, Table 5.1.3.2-1))
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition REGISTER-RSP |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
Table 5.1.3.3-25: SIP 200 (OK) (Steps 15, 25, Table 5.1.3.2-1))
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition SUBSCRIBE-RSP |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
Contact |
||||
|
addr-spec |
||||
|
user-info and host |
tsc_MCPTT_PublicServiceId_B |
|||
Table 5.1.3.3-26: SIP 200 (OK) (Step 31, Table 5.1.3.2-1))
|
Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition PUBLISH-RSP |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |