A.2.3 MCPTT server subscribing to and obtaining MCPTT service configuration document
24.4843GPPMission Critical Services (MCS) configuration managementProtocol specificationRelease 18TS
Figure A.2.3-1 shows a flow for the MCPTT server subscribing to and obtaining the MCPTT service configuration document
The hostname of CMS-1 is cms1.example.com.
Figure A.2.3-1: MCPTT server subscribing to and obtaining the MCPTT service configuration document
Figure A.2.3-1 shows a MCPTT server subscribing to and obtaining the MCPTT service configuration document. The details of the flow are as follows:
1. SIP SUBSCRIBE request (MCPTT server to SIP Core) – see example in table A.2.3-1
A MCPTT server needs to obtain and get a notification when the service configuration document of a hosted mission critical organisation are modified. In order to initiate a subscription to XCAP document changes in the CMS, the MCPTT server generates a SIP SUBSCRIBE request indicating support for "xcap-diff", together with "message/external-body".
Table A.2.3-1: SIP SUBSCRIBE request (CMC in MCPTT UE to SIP core)
SUBSCRIBE sip:MissionCriticalOrg.MCO-12345@cms1.example.net;auid=org.3gpp.mcptt.service-config SIP/2.0
Via: SIP/2.0/UDP McpttServer1.home1.net;branch=z9hG4bKehuefdam
Max-Forwards: 70
Route: <sip:orig@scscf1.home1.net;lr>
P-Asserted-Identity: <sip:McpttServer1.home1.net>
Privacy: none
From: <sip:McpttServer1.home1.net>;tag=31415
To: <sip:cms1.example.nett>
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 123 SUBSCRIBE
P-Asserted-Service:urn:urn-7:3gpp-service.ims.icsi.mcptt
Event: xcap-diff;diff-processing=aggregate
Expires: 7200
Accept: application/xcap-diff+xml, message/external-body
Contact: <sip:McpttServer1.home1.net;gr>;+g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mcptt"
Content-Length: 0
Request-URI: The XCAP-URI for the service configuration document based on the CMS XCAP root URI configured in the MCPTT server at the public service identity of CMS-1 (sip: MissionCriticalOrg.MCO-12345@cms1.example.net).
Event: This header field is populated with the value "xcap-diff" to specify the use of the xcap-diff package to get notified of changes to XCAP configuration management documents.
Accept: This header field is populated with the value "application/xcap-diff+xml" indicating that the MCPTT UE supports the XCAP-diff MIME type and also the value "message/external-body" indicating that the MCPTT server supports content indirection (to avoid XCAP content that contains sensitive information being included in a SIP NOTIFY request).
To: Same as the Request-URI.
.
2. SIP SUBSCRIBE request (SIP core to CMS) – see example in table A.2.3-2
The SIP core forwards the SIP SUBSCRIBE request to the CMS.
Table A.2.3-2 SIP SUBSCRIBE request (SIP core to CMS)
SUBSCRIBE sip:MissionCriticalOrg.MCO-12345@cms1.example.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP McpttServer1.home1.net;branch=z9hG4bKehuefdam
Max-Forwards: 69
P-Asserted-Identity:
Privacy:
Record-Route: <sip:scscf1.home1.net;lr>,
Route: <sip:cms1.home1.net;lr>, <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
CSeq:
P-Asserted-Service:
Event:
Supported:
Expires:
Accept:
Contact:
Content-Length:
3. Authorization
The CMS performs authorization of the MCPTT server based on the P-Asserted-Identity header field of the SIP SUBSCRIBE request to ensure that MCPTT server is authorized to subscribe to MCPTT service configuration document changes.
– In this example authorisation is sucessful, so the CMS sends a SIP 200 (OK) response to the SIP core.
4. SIP 200 (OK) response (CMS to SIP core) – see example in table A.2.3-4
The CMS sends a SIP 200(OK) response to the SIP core.
Table A.2.3-4: SIP 200 (OK) response (CMS to SIP core)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP McpttServer1.home1.net;branch=z9hG4bKehuefdam
Record-Route:
From:
To: <sip:cms1.example.com;tag=151170
Call-ID:
CSeq:
Expires:
Contact: <sip:cms1.example.com;gr>
Content-Length: 0
5. SIP 200 (OK) response (S-CSCF to MCPTT server) – see example in table A.2.3-5
The SIP core forwards the SIP 200(OK) response to the CMC in the MCPTT UE.
Table A.2.3-5: SIP 200 (OK) response (SIP core to MCPTT server
SIP/2.0 200 OK
Via: SIP/2.0/UDP McpttServer1.home1.net;branch=z9hG4bKehuefdam
Record-Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
CSeq:
Expires:
Contact:
Content-Length:
6. Obtaining the MCPTT service configuration document
The CMS obtains the MCPTT service configuration document for the Mission Critical organisation based on the Request-URI. The CMS generates a MCPTT service configuration document containing the <common> and <on-network> elements and mints an XCAP URI for the generated MCPTT service configuration document.
7. SIP NOTIFY request (CMS to SIP core) – see example in table A.2.3-7
The CMS generates a SIP NOTIFY request including the xcap-diff document as a result of the SIP SUBSCRIBE request. As this is the initial SIP NOTIFY it contains only the new-etag, a previous etag and sel attributes for the MCPTT service configuration document.
Table A.2.3-7 SIP NOTIFY request (CMS to SIP core)
NOTIFY sip:McpttServer1.home1.net;gr SIP/2.0
Via: SIP/2.0/UDP cms1.example.com;branch=z9hG4bK240f34.1
Max-Forwards: 70
Route: sip:scscf1.home1.net;lr
From: <sip:cms1.example.com>;tag=151170
To: <sip:McpttServer1.home1.com;gr>;tag=31415
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 89 NOTIFY
P-Asserted-Service:urn:urn-7:3gpp-service.ims.icsi.mcptt
Subscription-State: active;expires=7200
Event: xcap-diff
Contact: <sip:cms1.example.net;gr>
Content-Type: application/xcap-diff+xml;charset="UTF-8"
Content-Length: (..)
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff">
<document sel="service-coinfig.xml"
new-etag="ffds66a"
previous-etag="ffds66a">
</document>
</xcap-diff>
The content of the document element contains a new-etag and a previous etag attribute with identical value and no list of instructions. This way it is indicated that this is the reference XML diff document. This document has only the information about the etags and the document URI’s covered by that subscription
8. SIP NOTIFY request (SIP core to MCPTT server) – see example in table A.2.3-8
The SIP core forwards the SIP NOTIFY request to the MCPTT server.
Table A.2.3-8: SIP NOTIFY request (SIP core to MCPTT server)
NOTIFY sip:McpttServer1.home1.net;gr SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=240f34.1, SIP/2.0/UDP McpttServer1.home1.net
Max-Forwards: 69
Record-Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
P-Asserted-Service:
CSeq:
Subscription-State:
Event:
Contact:
Content-Length:
(…)
9. SIP 200 (OK) response (MCPTT server to SIP core) – see example in table A.2.3-9
The MCPTT server acknowledges the SIP NOTIFY request with a SIP 200 (OK) response to the SIP core.
Table A.2.3-9: SIP 200 (OK) response (MCPTT server to SIP core)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP cms1.example.com;branch=z9hG4bK240f34.1
From:
To:
Call-ID:
CSeq:
Content-Length: 0
10. SIP 200 (OK) response (SIP core to CMS) – see example in table A.2.3-10
The SIP core forwards the SIP 200(OK) response to the CMS.
Table A.2.3-10: SIP 200 (OK) response (SIP core to CMS)
SIP/2.0 200 OK
Via: SIP/2.0/UDP cms1.example.com;branch=z9hG4bK240f34.1
From:
To:
Call-ID:
CSeq:
Content-Length:
11. HTTP GET request (MCPTT server to CMS) – see example in table A.23-11
The MCPTT server obtains the MCPTT service configuration document by generating an HTTP GET request using the XCAP URI from the sel attribute of the <document> element in the SIP NOTIFY request.
Table A.2.3-11: HTTP GET request (MCPTT server to CMS)
GET https://MissionCriticalOrg/MCO-12345/service-coinfig.xml HTTP/1.1
Host: cms1.example.com
X-3GPP-Asserted-Identity: cms1.example.com
Content-Length: 0
12. HTTP GET request (MCPTT server to CMS) – see example in table A.2.3-12
After the CMS has authenticated the MCPTT server based on the X-3GPP-Asserted-Identity header field to ensure that the MCPTT server is allowed to fetch the MCPTT service configuration document, the CMS sends a HTTP 200 (OK) response to the CMC including the MCPTT sevice configuration document in the body of the response.
Table A.2.3-12: HTTP 200 (OK) response (CMS to MCPTT server)
HTTP/1.1 200 OK
Etag: "ffds66a"
Content-Type: application/org.3gpp.mcptt-service-config+xml; charset="utf-8"
Content-Length: (…)
<?xml version="1.0" encoding="UTF-8"?>
<service-configuration-info xmlns="urn:3gpp:ns:mcpttServiceConfig:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="Servconf.xsd">
<service-configuration-params domain="example.com">
<common>
<min-length-alias>12</min-length-alias>
<broadcast-group>
<num-levels-group-hierarchy>6</num-levels-group-hierarchy>
<num-levels-user-hierarchy>6</num-levels-user-hierarchy>
<anyExt />
</broadcast-group>
<anyExt />
</common>
<on-network>
<emergency-call>
<private-cancel-timeout>PT13S</private-cancel-timeout>
<group-time-limit>PT1300S</group-time-limit>
<anyExt />
</emergency-call>
<private-call>
<hang-time>PT13S</hang-time>
<max-duration-with-floor-control>PT1300S</max-duration-with-floor-control>
<max-duration-without-floor-control>PT1300S</max-duration-without-floor-control>
<anyExt />
</private-call>
<num-levels-priority-hierarchy>6</num-levels-priority-hierarchy>
<transmit-time>
<time-limit>PT13S</time-limit>
<time-warning>PT1300S</time-warning>
<anyExt />
</transmit-time>
<hang-time-warning>PT8S</hang-time-warning>
<floor-control-queue>
<depth>4</depth>
<max-user-request-time>PT30S</max-user-request-time>
<anyExt />
</floor-control-queue>
<fc-timers-counters>
<T1-end-of-rtp-media>PT4S</T1-end-of-rtp-media>
<T3-stop-talking-grace>PT3S</T3-stop-talking-grace>
<T7-floor-idle>PT4S</T7-floor-idle>
<T8-floor-revoke>PT1S</T8-floor-revoke>
<T11-end-of-RTP-dual>PT4S</T11-end-of-RTP-dual>
<T12-stop-talking-dual>PT30S</T12-stop-talking-dual>
<T15-conversation>PT30S</T15-conversation>
<T16-map-group-to-bearer>PT0.5S</T16-map-group-to-bearer>
<T17-unmap-group-to-bearer>PT0.2S</T17-unmap-group-to-bearer>
<T20-floor-granted>PT1S</T20-floor-granted>
<T55-connect>PT2S</T55-connect>
<T56-disconnect>PT2S</T56-disconnect>
<C7-floor-idle>10</C7-floor-idle>
<C17-unmap-group-to-bearer>3</C17-unmap-group-to-bearer>
<C20-floor-granted>3</C20-floor-granted>
<C55-connect>3</C55-connect>
<C56-disconnect>3</C56-disconnect>
<anyExt />
</fc-timers-counters>
<signalling-protection>
<confidentiality-protection>true</confidentiality-protection>
<integrity-protection>true</integrity-protection>
<anyExt />
</signalling-protection>
<protection-between-mcptt-servers>
<allow-signalling-protection>true</allow-signalling-protection>
<allow-floor-control-protection>true</allow-floor-control-protection>
<anyExt />
</protection-between-mcptt-servers>
<emergency-resource-priority>
<resource-priority-namespace>"mcpttq.12"</resource-priority-namespace>
<resource-priority-priority>"mcpttq.12"</resource-priority-priority>
<anyExt />
</emergency-resource-priority>
<imminent-peril-resource-priority>
<resource-priority-namespace>"mcpttq.10"</resource-priority-namespace>
<resource-priority-priority>"mcpttq.10"</resource-priority-priority>
<anyExt />
</imminent-peril-resource-priority>
<normal-resource-priority>
<resource-priority-namespace>"mcpttq.7"</resource-priority-namespace>
<resource-priority-priority>"mcpttq.7"</resource-priority-priority>
<anyExt />
</normal-resource-priority>
<anyExt />
</on-network>
<anyExt />
</service-configuration-params>
<anyExt />
</service-configuration-info>
Annex B (informative):
IANA registration templates