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