14 Handling of Interworking Security Data messages
29.3793GPPMission Critical Push To Talk (MCPTT) call control interworking with Land Mobile Radio (LMR) systemsRelease 16Stage 3TS
14.1 IWF
14.1.1 IWF originates Interworking Security Data message
Upon deciding to send an Interworking Security Data message, the IWF:
1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [3] and IETF RFC 3428 [18];
2) shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [5];
3) the IWF shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [5];
4) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-request-uri> element set to the value of the MCPTT ID of the targeted MCPTT user; and
5) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [3]), in a P-Asserted-Service-Id header field according to IETF RFC 6050 [7];
6) shall set the Request-URI to the address of the terminating participating function associated with the MC service ID of the targeted MC service user;
7) shall include a P-Asserted-Identity header field set to the public service identity of the IWF;
8) shall include an application/vnd.3gpp.interworking-data MIME body with the Interworking Security Data message payload as defined in clause 14.2.1;
9) if a security context between the MCPTT client and the IWF needs to be established and the security context does not exist or if the existing security context has expired, procedures in clause 11.2.2 in 3GPP TS 33.180 [29] shall be followed; and
10) send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [3].
14.1.2 IWF receives Interworking Security Data message
Upon receiving a "SIP MESSAGE request for Interworking Security Data message for participating function", the actions performed by the IWF are out of scope of the present document. The received message, described in clause 14.2, contains an opaque payload, the contents of which are out of scope of the present document.
14.2 Interworking Security Data message payload
14.2.1 Message definition
This clause specifies the payload to be used when sending an Interworking Security Data message between the IWF and MCPTT clients. The Interworking Security Data (InterSD) message is defined as a MONP message.
Message type: InterSD-MESSAGE
Direction: IWF to MCPTT client, MCPTT client to IWF
Table 14.2.1-1: Interworking Security Data message content
|
IEI |
Information Element |
Type/Reference |
Presence |
Format |
Length |
|
SDS signalling payload message identity |
Message type |
M |
V |
1 |
|
|
External network type |
14.2.2 |
M |
V |
1 |
|
|
7D |
URI of LMR key management functional entity |
URI encoded as specified in IETF RFC 3986 [32] |
O |
TLV-E |
3-x |
|
78 |
Payload |
3GPP TS 24.282 [30], clause 15.2.13 with Payload content type set to ‘BINARY’ |
O |
TLV-E |
3-x |
14.2.2 External network type
The purpose of the external network type information element is to identify the type of the network represented by the IWF.
The value part of the external network type information element is coded as shown in Table 14.2.2-1.
The external network type information element is a type 3 information element with a length of 1 octet.
Table 14.2.2-1: External network type
|
Bits |
|||||||||
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
P25 |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
TETRA |
|
|
All other values are reserved. |
|||||||||
Annex A (normative):
XML Schema