22 Functional alias

24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS

22.1 General

Clause 22.2 contains the procedures for management of functional alias at the MCData client, the MCData server serving the MCData user and the MCData server owning the functional alias.

Clause 22.3 describes the coding used for management of functional aliases.

22.2 Procedures

22.2.1 MCData client procedures

22.2.1.1 General

The MCData client procedures consist of:

– a functional alias status change procedure;

– a functional alias status determination procedure; and

– a location based functional alias status change procedure.

In order to obtain information about success or rejection of changes triggered by the functional alias status change procedure for an MCData user, the MCData client needs to initiate the functional alias status determination procedure for the MCData user before starting the functional alias status change procedure for the MCData user.

22.2.1.2 Functional alias status change procedure

In order:

– to indicate that an MCData user requests to activate one or more functional aliases;

– to indicate that the MCData user requests to deactivate one or more functional aliases;

– to refresh indication of an MCData user interest in one or more functional aliases due to near expiration of the expiration time of a functional alias with the status set to the "activated" state received in a SIP NOTIFY request in clause 22.2.1.3;

– to indicate that the MCData client entering into or exiting from a location area triggers one or more functional aliases to be activated;

– to indicate that the MCData client entering into or exiting from a location area triggers one or more functional aliases to be deactivated; or

– any combination of the above;

the MCData client shall generate a SIP PUBLISH request according to TS 24.229 [5], IETF RFC 3903 [34], and IETF RFC 3856 [39].

When the MCData user requests to deactivate a functional alias, the MCData client shall first check the <manual-deactivation-not-allowed-if-location-criteria-met> element within the <anyExt> element of the <entry> element corresponding to the functional alias within the <FunctionalAliasList> list element of the <anyExt> element of the <OnNetwork> element of the MCData user profile document (see the MCData user profile document in TS 24.484 [12]). If the functional alias has been activated due to a location area trigger and the <manual-deactivation-not-allowed-if-location-criteria-met> element is set to a value of "true", the MCData client shall suppress the MCData user’s request.

NOTE 1: If the request is suppressed, a notification message can be displayed to the user.

In the SIP PUBLISH request, the MCData client:

1) shall set the Request-URI to the public service identity identifying the originating participating MCData function serving the MCData user;

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData client shall include the <mcdata-request-uri> element set to the MCData ID of the MCData user;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7];

4) if the MCData client requests to activate one or more functional aliases, shall set the Expires header field according to IETF RFC 3903 [34], to 4294967295;

NOTE 2: 4294967295, which is equal to 232-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) if the MCData client requests to deactivate one or more functional aliases, shall set the Expires header field according to IETF RFC 3903 [34], to zero; and

NOTE 3: Activation and deactivation of functional alias cannot be performed with the same PUBLISH request.

6) shall include an application/pidf+xml MIME body indicating per-user functional alias information according to clause 22.3.1. In the MIME body, the MCData client:

a) shall include all functional aliases where the MCData user requests activation for the MCData ID;

b) shall include the MCData client ID of the targeted MCData client;

c) shall not include the "status" attribute and the "expires" attribute in the <functionalalias> element;

d) if the MCData client has received an indication that take over of a functional alias is possible and intends to take over a functional alias, shall include a <take-over> child element set to "true"; and

e) shall set the <p-id-fa> child element of the <presence> root element to a globally unique value.

The MCData client shall send the SIP PUBLISH request according to TS 24.229 [5].

22.2.1.3 Functional alias status determination procedure

NOTE 1: The MCData UE also uses this procedure to determine which functional alias have been successfully activated for the MCData ID.

In order to discover functional aliases:

1) which which are activated for the MCData user; or

2) which another MCData user has activated;

the MCData client shall generate an initial SIP SUBSCRIBE request according to TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36].

In the SIP SUBSCRIBE request, the MCData client:

1) shall set the Request-URI to the public service identity identifying the originating participating MCData function serving the MCData user;

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData client shall include:

a) the <mcdata-request-uri> element set to the MCData ID of the targeted MCData user; and

b) the <request-type> element in the <mcdata-Params> element of the <mcdatainfo> element set to the value "functional-alias-status-determination";

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7];

4) if the MCData client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295;

NOTE 2: 4294967295, which is equal to 232-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) if the MCData client wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [36], to zero;

6) shall include an Events header field set to "presence"; and

7) shall include an Accept header field containing the application/pidf+xml MIME type.

In order to re-subscribe or de-subscribe, the MCData client shall generate an in-dialog SIP SUBSCRIBE request according to TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36]. In the SIP SUBSCRIBE request, the MCData client:

1) if the MCData client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295;

NOTE 3: 4294967295, which is equal to 232-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

2) if the MCData client wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [36], to zero;

3) shall include an Events header field set to "presence"; and

4) shall include an Accept header field containing the application/pidf+xml MIME type.

Upon receiving a SIP NOTIFY request according to TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36], if SIP NOTIFY request contains an application/pidf+xml MIME body indicating per-user functional alias information constructed according to clause 22.3.1, then the MCData client shall determine the status of the MCData user for each functional alias in the MIME body. If the <p-id-fa> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request is included, the <p-id-fa> element value indicates the SIP PUBLISH request which triggered sending of the SIP NOTIFY request.

If the MCData client detected a functional alias activation or deactivation, it shall perform the procedure specified in clause 8.2.6.

22.2.1.4 Location based functional alias status change procedure

If a location criterion for functional alias activation or de-activation is met, the MCData client shall initiate the functional alias status change procedure as specified in clause 22.2.1.2.

22.2.2 MCData server procedures

22.2.2.1 General

The MCData server procedures consist of:

– procedures of MCData server serving the MCData user; and

– procedures of MCData server owning the functional alias.

22.2.2.2 Procedures of MCData server serving the MCData user

22.2.2.2.1 General

The procedures of MCData server serving the MCData user consist of:

– a receiving functional alias status change from MCData client procedure;

– a receiving subscription to functional alias status procedure;

– a sending notification of change of functional alias status procedure;

– a sending functional alias status change towards MCData server owning the functional procedure; and

– a functional alias status determination from MCData server owning the functional alias procedure.

22.2.2.2.2 Stored information

The MCData server shall maintain a list of MCData user information entries. The list of the MCData user information entries contains one MCData user information entry for each served MCData ID.

In each MCData user information entry, the MCData server shall maintain:

1) an MCData ID. This field uniquely identifies the MCData user information entry in the list of the MCData user information entries; and

2) a list of functional alias information entries.

In each functional alias information, the MCData server shall maintain:

1) a functional alias ID. This field uniquely identifies the functional alias information entry in the list of the functional alias information entries;

2) a functional alias status;

3) an expiration time;

4) a functional alias p-id-fa; and

5) a next publishing time.

22.2.2.2.3 Receiving functional alias status change from MCData client procedure

Upon receiving a SIP PUBLISH request such that:

1) Request-URI of the SIP PUBLISH request contains either the public service identity identifying the originating participating MCData function serving the MCData user, or the public service identity identifying the terminating participating MCData function serving the MCData user;

2) the SIP PUBLISH request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the<mcdata-request-uri> element which identifies an MCData ID served by the MCData server;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) the Event header field of the SIP PUBLISH request contains the "presence" event type; and

5) SIP PUBLISH request contains an application/pidf+xml MIME body indicating per-user functional alias information according to clause 22.3.1;

then the MCData server:

1) shall identify the served MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP PUBLISH request;

2) if the Request-URI of the SIP PUBLISH request contains the public service identity identifying the originating participating MCData function serving the MCData user, shall identify the originating MCData ID from public user identity in the P-Asserted-Identity header field of the SIP PUBLISH request;

3) if the Request-URI of the SIP PUBLISH request contains the public service identity identifying the terminating participating MCData function serving the MCData user, shall identify the originating MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP PUBLISH request;

4) if the originating MCData ID is different than the served MCData ID or the originating MCData ID is not authorized to modify functional alias status of the served MCData ID, shall send a SIP 403 (Forbidden) response and shall not continue with the rest of the steps;

5) if the Expires header field of the SIP PUBLISH request is not included or has nonzero value lower than 4294967295, shall send a SIP 423 (Interval Too Brief) response to the SIP PUBLISH request, where the SIP 423 (Interval Too Brief) response contains a Min-Expires header field set to 4294967295, and shall not continue with the rest of the steps;

6) if the Expires header field of the SIP PUBLISH request has nonzero value, shall determine the candidate expiration interval to according to IETF RFC 3903 [34];

7) if the Expires header field of the SIP PUBLISH request has zero value, shall set the candidate expiration interval to zero;

8) shall respond with SIP 200 (OK) response to the SIP PUBLISH request according to TS 24.229 [5], IETF RFC 3903 [34]. In the SIP 200 (OK) response, the MCData server:

a) shall set the Expires header field according to IETF RFC 3903 [34], to the candidate expiration time;

9) if the "entity" attribute of the <presence> element of the application/pidf+xml MIME body of the SIP PUBLISH request is different than the served MCData ID, shall not continue with the rest of the steps;

10) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of MCData user information entries described in clause 22.2.2.2.2; and

b) the MCData ID of the MCData user information entry is equal to the served MCData ID;

as the served MCData user information entry;

11) shall consider a copy of the list of the MCData functional alias entries of the served MCData user information entry as the served list of the MCData functional alias information entries;

12) if the candidate expiration interval is nonzero, shall construct the candidate list of the MCData functional alias entries as follows:

a) for each functional alias ID which has a functional alias information entry in the served list of the functional alias information entries, such that the expiration time of the functional alias information entry has not expired yet, and which is indicated in a "functionalAliasID" attribute of a <functionalAlias> element of the <status> element of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request:

i) shall copy the functional alias information entry into a new functional alias information entry of the candidate list of the functional alias information entries;

ii) if the functional alias status of the functional alias information entry is "deactivating" or "deactivated", shall set the functional alias status of the new functional alias information entry to the "activated" state and shall set the activating p-id-fa of the new functional alias information entry to the value of the <p-id-fa> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request; and

iii) shall set the expiration time of the new functional alias information entry to the current time increased with the candidate expiration interval;

b) for each functional alias ID which has a functional alias information entry in the served list of the functional alias information entries, such that the expiration time of the functional alias information entry has not expired yet, and which is not indicated in any "functionalAliasID" attribute of the <functionalAlias> element of the <status> element of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request:

i) shall copy the functional alias information entry into a new functional alias information entry of the candidate list of the functional alias information entries; and

ii) if the functional alias status of the functional alias information entry is "activated" or "activating":

– shall set the functional alias status of the new functional alias entry to the "deactivating" state; and

– shall set the expiration time of the new functional alias information entry to the current time increased with twice the value of timer F; and

c) for each functional alias ID:

i) which does not have a functional alias information entry in the served list of the functional alias entries; or

ii) which has a functional alias information entry in the served list of the functional alias information entries, such that the expiration time of the functional alias information entry has already expired;

and which is indicated in a "functionalAliasID" element of the <functionalAlias> element of the <status> element of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request:

i) shall add a new functional alias information entry in the candidate list of the functional alias information list for the functional alias ID;

ii) shall set the functional alias status of the new functional alias information entry to the "activating" state;

iii) shall set the expiration time of the new functional alias information entry to the current time increased with the candidate expiration interval; and

iv) shall set the activating p-id-fa of the new functional alias information entry to the value of the <p-id-fa> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request;

13) if the candidate expiration interval is zero, constructs the candidate list of the functional alias information entries as follows:

a) for each functional alias ID which has an entry in the served list of the functional alias information entries:

i) shall copy the functional alias entry of the served list of the functional alias information into a new functional alias information entry of the candidate list of the functional alias information entries;

ii) shall set the functional alias status of the new functional alias information entry to the "de-activating" state; and

iii) shall set the expiration time of the new functional alias information entry to the current time increased with twice the value of timer F;

14) shall replace the list of the functional alias information entries stored in the served MCData user information entry with the candidate list of the functional alias information entries;

15) shall perform the procedures specified in clause 22.2.2.2.6 for the served MCData ID and each functional alias:

a) which does not have a functional alias information entry in the served list of the functional alias information entries and which has a functional alias information entry in the candidate list of the functional alias information entries with the functional alias status set to the "activating" state;

b) which has a functional alias information entry in the served list of the functional alias information entries with the expiration time already expired, and which has a functional alias information entry in the candidate list of the functional alias information entries with the functional alias status set to the "activating" state;

c) which has a functional alias information entry in the served list of the functional alias information entries with the functional alias status set to the "deactivating" state or the "deactivated" state and with the expiration time not expired yet, and which has an functional alias information entry in the candidate list of the functional alias information entries with the functional alias status set to the "activating" state; or

d) which has a functional alias information entry in the served list of the functional alias information entries with the functional alias status set to the "activated" state and with the expiration time not expired yet, and which has an functional alias information entry in the candidate list of the functional alias information entries with the functional alias status set to the "deactivating" state;

16) shall identify the handled p-id-fa in the <p-id-fa> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request; and

17) shall perform the procedures specified in clause 22.2.2.2.5 for the served MCData ID.

22.2.2.2.4 Receiving subscription to functional alias status procedure

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains either the public service identity identifying the originating participating MCData function serving the MCData user, or the public service identity identifying the terminating participating MCData function serving the MCData user;

2) the SIP SUBSCRIBE request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing:

a) the<mcdata-request-uri> element which identifies an MCData ID served by the MCData server; and

b) the <mcdatainfo> element with the <mcdata-Params> element with the <request-type> element set to a value of "functional-alias-status-determination";

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in TS 24.229 [5]), in a P‑Asserted-Service header field according to IETF RFC 6050 [7]; and

4) the Event header field of the SIP SUBSCRIBE request contains the "presence" event type;

the MCData server:

1) shall identify the served MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

2) if the Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the originating participating MCData function serving the MCData user, shall identify the originating MCData ID from public user identity in the P-Asserted-Identity header field of the SIP SUBSCRIBE request;

3) if the Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the terminating participating MCData function serving the MCData user, shall identify the originating MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

4) if the originating MCData ID is different than the served MCData ID and the originating MCData ID is not authorized to modify functional alias status of the served MCData ID, shall send a SIP 403 (Forbidden) response and shall not continue with the rest of the steps; and

5) shall generate a SIP 200 (OK) response to the SIP SUBSCRIBE request according to TS 24.229 [5], IETF RFC 6665 [36].

For the duration of the subscription, the MCData server shall notify the subscriber about changes of the information of the served MCData ID, as described in clause 22.2.2.2.5.

22.2.2.2.5 Sending notification of change of functional alias status procedure

In order to notify the subscriber about changes of functional aliases of the served MCData ID, the MCData server:

1) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of MCData user information entries described in clause 22.2.2.2.2; and

b) the MCData ID of the MCData user information entry is equal to the served MCData ID;

as the served MCData user information entry;

2) shall generate an application/pidf+xml MIME body indicating per-user functional alias information according to clause 22.3.1 and the served list of the MCData user information entries with the following clarifications:

a) the MCData server shall not include information from functional alias information entry with the expiration time already expired;

b) the MCData server shall not include information from a functional alias information entry with the functional alias status set to the "deactivated" state;

c) if this procedures is invoked by procedure in clause 22.2.2.2.3 where the handled p-id-fa value was identified, the MCData server shall set the <p-id-fa> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request to the handled p-id-fa value; and

3) send a SIP NOTIFY request according to 3GPP TS 24.229 [5], and IETF RFC 6665 [36] for the subscription created in clause 22.2.2.2.4. In the SIP NOTIFY request, the MCData server shall include the generated application/pidf+xml MIME body indicating per-user functional alias information.

22.2.2.2.6 Sending functional alias status change towards MCData server owning the functional alias procedure

NOTE 1: Usage of one SIP PUBLISH request to carry information about change of functional alias state of several MCData users served by the same MCData server is not supported in this version of the specification.

In order:

– to send an activation request of a served MCData ID for a handled functional alias ID;

– to send a deactivation request of a served MCData ID for a handled functional alias ID;

– to send a take over request of a served MCData ID for a handled functional alias ID due to take over; or

– to send an activation request of a served MCData ID for a handled functional alias ID due to near expiration of the previously published information;

the MCData server shall generate a SIP PUBLISH request according to TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39]. In the SIP PUBLISH request, the MCData server:

1) shall set the Request-URI to the public service identity of the controlling MCData function associated with the handled functional alias ID;

NOTE 2: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.

NOTE 3: If the controlling MCData function is in an interconnected MCData system in a different trust domain, then the public service identity can identify the MCData gateway server that acts as an entry point in the interconnected MCData system from the local MCData system.

NOTE 4: If the controlling MCData function is in an interconnected MCData system in a different trust domain, then the local MCData system can route the SIP request through an MCData gateway server that acts as an exit point from the local MCData system to the interconnected MCData system.

NOTE 5: How the MCData server determines the public service identity of the controlling MCData function serving the target MCData ID or of the MCData gateway server in the interconnected MCData system is out of the scope of the present document.

NOTE 6: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData server:

a) shall include the <mcdata-request-uri> element set to the handled functional alias ID; and

b) shall include the <mcdata-calling-user-id> element set to the served MCData ID;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) if sending an activation request, shall set the Expires header field according to IETF RFC 3903 [34], to 4294967295;

NOTE 7: 4294967295, which is equal to 232-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) if sending a deactivation request, shall set the Expires header field according to IETF RFC 3903 [34], to zero;

6) shall include a P-Asserted-Identity header field set to the public service identity of the MCData server according to 3GPP TS 24.229 [5];

7) shall set the current p-id-fa to a globally unique value;

8) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of MCData user information entries described in clause 22.2.2.2.2; and

b) the MCData ID of the MCData user information entry is equal to the served MCData ID;

as the served MCData user information entry;

9) for each functional alias information entry such that:

a) the functional alias information entry has the "activating" functional alias status, the functional alias ID set to the handled functional alias ID, the expiration time has not expired yet and the activating p-id-fa is not set; and

b) the functional alias information entry is in the list of the functional alias information entries of the served MCData user information entry;

shall set the activating p-id-fa of the functional alias information entry to the current p-id-fa; and

10) shall include an application/pidf+xml MIME body indicating per-functional alias status information constructed according to clause 22.3.1.2. The MCData server shall indicate all served MCData user IDs, such that:

a) the functional alias status is set to "activating" with or without "take-over" element or "activated", and the expiration time has not expired yet in a functional alias information entry with the functional alias ID set to the handled functional alias;

b) the functional alias information entry is in the list of the functional alias information entries of an MCData user information entry; and

c) the MCData user information entry is a served MCData user information entry.

The MCData server shall set the <p-id-fa> child element of the <presence> root element to the current p-id-fa.

The MCData server shall not include the "expires" attribute in the <functionalAlias> element.

NOTE 8: The MCData server sets the "status" attribute in the <functionalAlias> element to indicate whether the request is for functional alias take over.

The MCData server shall send the SIP PUBLISH request according to 3GPP TS 24.229 [5].

If timer F expires for the SIP PUBLISH request sent for a (de)activation request of served MCData ID for the functional alias ID or upon receiving a SIP 3xx, 4xx, 5xx or 6xx response to the SIP PUBLISH request, the MCData server:

1) shall remove each functional alias ID entry such that:

a) the functional alias information entry has the functional alias ID set to the handled functional alias ID; and

b) the functional alias information entry is in the list of the functional alias information entries of the served MCData user information entry.

22.2.2.2.7 Functional alias status determination from MCData server owning functional alias procedure

NOTE 1: Usage of one SIP SUBSCRIBE request to subscribe for notification about change of functional alias state of several MCData users served by the same MCData server is not supported in this version of the specification.

In order to discover whether a served MCData user successfully activated a handled functional alias in the MCData server owning the functional alias, the MCData server shall generate an initial SIP SUBSCRIBE request according to TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36].

In the SIP SUBSCRIBE request, the MCData server:

1) shall set the Request-URI to the public service identity of the controlling MCData function associated with the handled functional alias;

NOTE 2: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.

NOTE 3: If the controlling MCData function is in an interconnected MCData system in a different trust domain, then the public service identity can identify the MCData gateway server that acts as an entry point in the interconnected MCData system from the local MCData system.

NOTE 4: If the controlling MCData function is in an interconnected MCData system in a different trust domain, then the local MCData system can route the SIP request through an MCData gateway server that acts as an exit point from the local MCData system to the interconnected MCData system.

NOTE 5: How the MCData server determines the public service identity of the controlling MCData function serving the target MCData ID or of the MCData gateway server in the interconnected MCData system is out of the scope of the present document.

NOTE 6: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData server:

a) shall include the <mcdata-request-uri> element set to the handled functional alias ID; and

b) shall include the <mcdata-calling-user-id> element set to the served MCData ID;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) if the MCData server wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295;

NOTE 7: 4294967295, which is equal to 232-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) if the MCData server wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [36], to zero;

6) shall include an Accept header field containing the application/pidf+xml MIME type;

7) shall include an Events header field set to "presence"; and

8) shall include an application/simple-filter+xml MIME body indicating per-user restrictions of presence event package notification information according to clause 22.3.2, indicating the served MCData ID.

In order to re-subscribe or de-subscribe, the MCData server shall generate an in-dialog SIP SUBSCRIBE request according to TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36]. In the SIP SUBSCRIBE request, the MCData server:

1) if the MCData server wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295;

NOTE 8: 4294967295, which is equal to 232-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

2) if the MCData server wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [36], to zero;

3) shall include an Events header field set to "presence"; and

4) shall include an Accept header field containing the application/pidf+xml MIME type.

Upon receiving a SIP NOTIFY request according to TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36], if SIP NOTIFY request contains an application/pidf+xml MIME body indicating per-functional alias information constructed according to clause 22.3.1, then the MCData server:

1) for each served MCData ID such that the application/pidf+xml MIME body of SIP NOTIFY request contains:

a) a <tuple> element of the root <presence> element;

b) the "id" attribute of the <tuple> element indicating the served MCData ID;

c) an <functionalAlias> child element of the <status> element of the <tuple> element; and

d) the "expires" attribute of the <functionalAlias> element indicating expiration of activation of functional alias;

perform the following:

a) if a functional alias information entry exists such that:

i) the functional alias information entry has the "activating" functional alias status, the functional alias ID set to the handled functional alias ID, and the expiration time has not expired yet;

ii) the functional alias information entry is in the list of the functional alias information entries of an MCData user information entry with the MCData ID set to the served MCData ID; and

iii) the MCData user information entry is in the list of MCData user information entries described in clause 22.2.2.2.2;

shall set the functional alias status of the functional alias information entry to "activated"; and

shall set the next publishing time of the functional alias information entry to the current time and half of the time between the current time and the expiration of the functional alias; and

2) for each functional alias information entry such that:

a) the functional alias information entry has the "activated" functional alias status or the "deactivating" functional alias status, the functional alias ID set to the handled functional alias ID, and the expiration time has not expired yet;

b) the functional alias information entry is in the list of the functional alias information entries of an MCData user information entry with the MCData ID set to a served MCData ID; and

c) the MCData user information entry is in the list of MCData user information entries described in clause 22.2.2.2.2; and

for which the application/pidf+xml MIME body of SIP NOTIFY request does not contain:

a) a <tuple> element of the root <presence> element;

b) the "id" attribute of the <tuple> element indicating the served MCData ID; and

c) an <functionalAlias> child element of the <status> child element of the <tuple> element.

perform the following:

a) shall set the functional alias status of the functional alias information entry to "deactivated"; and

b) shall set the expiration time of the functional alias information entry to the current time; and

3) if a <p-id-fa> element is included in the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request, then for each functional alias information entry such that:

a) the functional alias information entry has the "activating" functional alias status, the functional alias ID set to the handled functional alias ID, the expiration time has not expired yet and with the activating p-id-fa set to the value of the <p-id-fa> element;

b) the functional alias information entry is in the list of the functional alias information entries of an MCData user information entry with the MCData ID set to a served MCData ID; and

d) the MCData user information entry is in the list of MCData user information entries described in clause 22.2.2.2.2; and

for which the application/pidf+xml MIME body of SIP NOTIFY request does not contain:

a) a <tuple> element of the root <presence> element;

b) the "id" attribute of the <tuple> element indicating the served MCData ID; and

c) an <functionalAlias> child element of the <status> child element of the <tuple> element;

perform the following:

a) shall set the functional alias status of the functional alias information entry to "deactivated"; and

b) shall set the expiration time of the functional alias information entry to the current time.

22.2.2.2.8 Functional alias resolution from MCData server owning the functional alias procedure

In order to discover the MCData users that have successfully activated a handled functional alias in the MCData server owning the functional alias, the MCData server shall generate an initial SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36].

In the SIP SUBSCRIBE request, the MCData server:

1) shall set the Request-URI to the public service identity of the controlling MCData function associated with the handled functional alias;

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata -info+xml MIME body, the MCData server shall include the <mcdata-request-uri> element set to the handled functional alias ID;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) shall set the Expires header field according to IETF RFC 6665 [36] to zero;

NOTE: if the MCData server wants to receive the current status and later notification, can set the Expires header field according to IETF RFC 6665 [36], to 4294967295, which is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) shall include an Accept header field containing the application/pidf+xml MIME type;

6) shall include an Events header field set to "presence"; and

7) shall include an application/simple-filter+xml MIME body indicating per-functional alias restrictions of presence event package notification information indicating the served functional alias.

Upon receiving a SIP NOTIFY request according to 3GPP TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36], if SIP NOTIFY request contains an application/pidf+xml MIME body indicating per-functional alias status information constructed according to clause 22.3.1, then the MCData client shall determine activation status for the MCData ID(s) of the MCData user(s) that have activated the functional alias in the received MIME body.

22.2.2.2.9 Forwarding subscription to functional alias status towards another MCData server procedure

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the originating participating MCData function serving the MCData user;

2) the SIP SUBCRIBE request contains an application/vnd.3gpp.mcdata-info MIME body containing the<mcdata-request-uri> element which identifies an MCData ID not served by MCData server;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7]; and

4) the Event header field of the SIP SUBSCRIBE request contains the "presence" event type;

then the MCData server:

1) shall identify the target MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info MIME body of the SIP SUBSCRIBE request;

2) shall identify the originating MCData ID from public user identity in the P-Asserted-Identity header field of the SIP SUBSCRIBE request;

3) shall generate a SIP SUBSCRIBE request from the received SIP SUBSCRIBE request. In the generated SIP SUBSCRIBE request, the MCData server:

a) shall set the Request-URI to the public service identity identifying the terminating participating MCData function serving the target MCData ID;

b) shall include a P-Asserted-Identity header field containing the public service identity identifying the originating participating MCData function serving the MCData user;

c) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData server:

A) shall include the <mcdata-request-uri> element set to the target MCData ID; and

B) shall include the <mcdata-calling-user-id> element set to the originating MCData ID; and

d) shall include other signalling elements from the received SIP SUBSCRIBE request; and

4) shall send the generated SIP SUBSCRIBE request according to 3GPP TS 24.229 [5].

The MCData server shall forward to the originating MCData ID any received SIP responses to the SIP SUBSCRIBE request, and for the duration of the subscription any received SIP NOTIFY requests and any received SIP responses to the SIP NOTIFY request according to 3GPP TS 24.229 [5].

22.2.2.3 Procedures of MCData server owning the functional alias

22.2.2.3.1 General

The procedures of MCData server owning the functional alias consist of:

– receiving functional alias status change procedure;

– receiving subscription to functional alias status procedure;

– sending notification of change of functional alias status procedure; and

– modification of functional alias eligibility check procedure.

22.2.2.3.2 Stored information

The MCData server shall maintain a list of functional alias information entries.

In each functional alias information entry, the MCData server shall maintain:

1) a functional alias ID. This field uniquely identifies the functional alias information entry in the list of the functional alias information entries; and

2) a list of MCData user information entries.

In each MCData user information entry, the MCData server shall maintain:

1) an MCData ID. This field uniquely identifies the MCData user information entry in the list of the MCData user information entries;

2) a take-over possible indication; and

3) an expiration time.

22.2.2.3.3 Receiving functional alias status change procedure

Upon receiving a SIP PUBLISH request such that:

1) Request-URI of the SIP PUBLISH request contains the public service identity of the controlling MCData function associated with the served functional alias;

2) the SIP PUBLISH request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the <mcdata-request-uri> element and the <mcdata-calling-user-id> element;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) the Event header field of the SIP PUBLISH request contains the "presence" event type; and

5) SIP PUBLISH request contains an application/pidf+xml MIME body indicating per-functional alias information constructed according to clause 22.3.1.2;

then the MCData server:

1) shall identify the served functional alias in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP PUBLISH request;

2) shall identify the handled MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP PUBLISH request;

3) if the Expires header field of the SIP PUBLISH request is not included or has nonzero value lower than 4294967295, shall send a SIP 423 (Interval Too Brief) response to the SIP PUBLISH request, where the SIP 423 (Interval Too Brief) response contains a Min-Expires header field set to 4294967295, and shall not continue with the rest of the steps;

4) if the functional alias does not exist in the MCData server, shall reject the SIP PUBLISH request with SIP 403 (Forbidden) response to the SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps;

4a) if SIP PUBLISH request is for activation of a functional alias then:

a) if handled MCData ID does not match with any of the entries in the <mcdata-user-list> which contains the MCData IDs of MCData users which are allowed to activate the functional alias; or

b) if no local policy exists that authorizes the request by the handled MCData ID;

shall reject the SIP PUBLISH request with SIP 403 (Forbidden) response according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps;

5) if SIP PUBLISH request is for activation of a functional alias and the number of activations for the handled functional alias is equal <max-simultaneous-activations>, shall reject the SIP PUBLISH request with SIP 403 (Forbidden) response to the SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps;

6) if SIP PUBLISH request is for take over of a functional alias, the MCData server shall use the <allow-takeover> and <allow-takeover-functional-alias-other-user> elements to determine if take over is possible. If take over is not possible, the MCData server shall reject the SIP PUBLISH request with SIP 403 (Forbidden) response to the SIP PUBLISH request according to TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps;

7) shall respond with SIP 200 (OK) response to the SIP PUBLISH request according to TS 24.229 [5], IETF RFC 3903 [34]. In the SIP 200 (OK) response, the MCData server:

a) shall set the Expires header field according to IETF RFC 3903 [34], to the selected expiration time;

8) if the "entity" attribute of the <presence> element of the application/pidf+xml MIME body of the SIP PUBLISH request is different than the served functional alias ID, shall not continue with the rest of the steps;

9) if the handled MCData ID is different from the MCData ID in the "id" attribute of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request, shall not continue with the rest of the steps;

10) shall consider a functional alias information entry such that:

a) the functional alias information entry is in the list of functional alias information entries described in clause 22.2.2.3.2; and

b) the functional alias ID of the functional alias information entry is equal to the served functional alias ID;

as the served functional alias information entry;

11) if the selected expiration time is zero:

a) shall remove the MCData user information entry such that:

i) the MCData user information entry is in the list of the MCData user information entries of the served functional alias information entry; and

ii) the MCData user information entry has the MCData ID set to the served MCData ID;

12) if the selected expiration time is not zero:

a) shall consider an MCData user information entry such that:

i) the MCData user information entry is in the list of the MCData user information entries of the served functional alias information entry; and

ii) the MCData ID of the MCData user information entry is equal to the handled MCData ID;

as the served MCData user information entry;

b) if the MCData user information entry does not exist:

i) shall insert an MCData user information entry with the MCData ID set to the handled MCData ID into the list of the MCData user information entries of the served functional alias information entry; and

ii) shall consider the inserted MCData user information entry as the served MCData user information entry; and

c) shall set the expiration time in the served MCData user information entry according to the selected expiration time;

13) shall identify the handled p-id-fa in the <p-id-fa> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request; and

14) shall perform the procedures specified in clause 22.2.2.3.5 for the served functional alias ID.

22.2.2.3.4 Receiving subscription to functional alias status procedure

NOTE: Usage of one SIP SUBSCRIBE request to subscribe for notification about change of functional alias state of several MCData users served by the same MCData server is not supported in this version of the specification.

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains the public service identity of the controlling MCData function associated with the served functional alias;

2) the SIP SUBSCRIBE request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the<mcdata-request-uri> element and the <mcdata-calling-user-id> element;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in TS 24.229 [5]), in a P‑Asserted-Service header field according to IETF RFC 6050 [7];

4) the Event header field of the SIP SUBSCRIBE request contains the "presence" event type; and

5) the SIP SUBSCRIBE request contains an application/simple-filter+xml MIME body indicating per-user restrictions of presence event package notification information according to clause 22.3.2 indicating the same MCData ID as in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

then the MCData server:

1) shall identify the served functional alias ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

2) shall identify the handled MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

3) if the Expires header field of the SIP SUBSCRIBE request is not included or has nonzero value lower than 4294967295, shall send a SIP 423 (Interval Too Brief) response to the SIP SUBSCRIBE request, where the SIP 423 (Interval Too Brief) response contains a Min-Expires header field set to 4294967295, and shall not continue with the rest of the steps;

4) if a functional alias does not exist in the MCData server, shall reject the SIP PUBLISH request with SIP 403 (Forbidden) response to the SIP PUBLISH request according to TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps;

5) if the handled MCData ID based on local policy is not authorized for notifications of the functional alias identified by the served functional alias ID, shall reject the SIP SUBSCRIBE request with SIP 403 (Forbidden) response to the SIP SUBSCRIBE request according to TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps; and

6) shall generate a SIP 200 (OK) response to the SIP SUBSCRIBE request according to TS 24.229 [5], IETF RFC 6665 [36].

For the duration of the subscription, the MCData server shall notify subscriber about changes of the information of the served MCData ID, as described in clause 22.2.2.3.5.

22.2.2.3.5 Sending notification of change of functional alias status procedure

In order to notify the subscriber identified by the handled MCData ID about changes of the functional alias status of the served functional alias ID, the MCData server:

1) shall consider a functional alias information entry such that:

a) the functional alias information entry is in the list of functional alias information entries described in clause 22.2.2.3.2; and

b) the functional alias ID of the functional alias information entry is equal to the served functional alias ID;

2) shall consider an MCData user information entry such:

a) the MCData user information entry is in the list of the MCData user information entries of the served functional alias information entry; and

b) the MCData ID of the MCData user information entry is equal to the handled MCData ID;

as the served MCData user information entry;

3) shall generate an application/pidf+xml MIME body indicating per-functional alias information according to clause 22.3.1 and the served list of the served MCData user information entry of the functional alias information entry with following clarifications:

a) the MCData server shall include the "expires" attribute in the <functionalAlias> element; and

b) if this procedures is invoked by procedure in clause 22.2.2.3.3 where the handled p-id-fa was identified, the MCData server shall set the <p-id-fa> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request to the handled p-id-fa value; and

4) send a SIP NOTIFY request according to 3GPP TS 24.229 [5], and IETF RFC 6665 [36] for the subscription created in clause 22.2.2.3.4. In the SIP NOTIFY request, the MCData server shall include the generated application/pidf+xml MIME body indicating per-functional alias information.

22.2.2.3.6 Functional alias status automatic deactivation procedure

In order to deactivate a functional alias associated with a target MCData ID:

1) externally triggered by an MCData administrator by a mechanism outside of the scope of the standard; or

2) directly by the MCData function owning the functional alias as a result of an internal trigger like the expiration of the functional alias association;

the MCData server

1) shall consider a functional alias information entry such that:

a) the functional alias information entry is in the list of functional alias information entries described in clause 22.2.2.3.2; and

b) the functional alias ID of the functional alias information entry is equal to the served functional alias ID;

as the served functional alias information entry;

2) shall remove the MCData user information entry such that:

a) the MCData user information entry is in the list of the MCData user information entries of the served functional alias information entry; and

b) the MCData user information entry has the MCData ID set to the target MCData ID; and

3) shall perform the procedures specified in clause 22.2.2.3.5 for the served functional alias ID.

22.2.2.3.7 Receiving subscription to functional alias resolution procedure

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains the public service identity of the controlling MCData function associated with the requested functional alias;

2) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

3) the Event header field of the SIP SUBSCRIBE request contains the "presence" event type; and

4) the SIP SUBSCRIBE request contains an application/simple-filter+xml MIME body indicating per-functional alias restrictions of presence event package notification information according to clause 22.3.2;

then the MCData server:

1) shall identify the requested functional alias ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

2) if the Expires header field of the SIP SUBSCRIBE request is not included or has nonzero value lower than 4294967295, shall send a SIP 423 (Interval Too Brief) response to the SIP SUBSCRIBE request, where the SIP 423 (Interval Too Brief) response contains a Min-Expires header field set to 4294967295, and shall not continue with the rest of the steps;

3) if the requested functional alias does not exist in the MCData server, shall reject the SIP SUBSCRIBE request with SIP 403 (Forbidden) response to the SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps; and

4) shall generate a SIP 200 (OK) response to the SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 6665 [36].

For the duration of the subscription, the MCData server shall notify subscriber about changes of the information of the requested functional alias, as described in clause 22.2.2.3.8.

22.2.2.3.8 Sending notification to functional alias resolution procedure

In order to notify the subscriber about the MCData users that have successfully activated the functional alias corresponding to the requested functional alias ID, the MCData server:

1) shall consider a functional alias information entry such that:

a) the functional alias information entry is in the list of functional alias information entries described in clause 22.2.2.3.2; and

b) the functional alias ID of the functional alias information entry is equal to the requested functional alias ID;

2) shall consider any MCData user information entry such that the MCData user information entry is in the list of the MCData user information entries of the served functional alias information entry, as the served MCData user information entry;

3) shall generate an application/pidf+xml MIME body indicating per-functional alias information according to clause 22.3.1 and the served list of the served MCData user information entry of the functional alias information entry

4) send a SIP NOTIFY request according to 3GPP TS 24.229 [5], and IETF RFC 6665 [36] for the subscription created in clause 22.2.2.3.7. In the SIP NOTIFY request, the MCData server shall include the generated application/pidf+xml MIME body indicating per-functional alias information.

22.3 Coding

22.3.1 Extension of application/pidf+xml MIME type

22.3.1.1 Introduction

The clauses of the parent clause describe an extension of the application/pidf+xml MIME body specified in IETF RFC 3863 [40]. The extension is used to indicate:

– per-user functional alias information; and

– per-functional alias status information.

22.3.1.2 Syntax

The application/pidf+xml MIME body indicating per-user functional alias information is constructed according to IETF RFC 3863 [40] and:

1) contains a <presence> root element according to IETF RFC 3863 [40];

2) contains an "entity" attribute of the <presence> element set to the MCData ID of the MCData user;

3) contains one <tuple> child element according to IETF RFC 3863 [40] per <presence> element;

4) can contain a <p-id-fa> child element defined in the XML schema defined in table 22.3.1.2-1, of the <presence> element set to an identifier of a SIP PUBLISH request;

5) contains an "id" attribute of the <tuple> element set to the MCData client ID;

6) contains one <status> child element of each <tuple> element;

7) contains one <functionalAlias> child element defined in the XML schema defined in table 22.3.1.2-1, of the <status> element, for each functional alias in which the MCData user is interested;

8) contains a "functionalAliasID" attribute of each <fucntionalAlias> element set to the functional alias ID of the functional alias in which the MCData user is interested;;

9) can contain a "status" attribute of each <functionalAliasID> element indicating the activation status of functional alias for the MCData user; and

10) can contain an "expires" attribute of each <functionalAlias> element indicating expiration of activation of the functional alias for the MCData user.

The application/pidf+xml MIME body indicating per-functional alias status information is constructed according to IETF RFC 3856 [39] and:

1) contains the <presence> root element according to IETF RFC 3863 [40];

2) contains an "entity" attribute of the <presence> element set to the functional alias ID of the functional alias;

3) contains one <tuple> child element according to IETF RFC 3863 [40] of the <presence> element;

4) can contain a <p-id-fa> child element defined in the XML schema defined in table 22.3.1.2-1, of the <presence> element set to an identifier of a SIP PUBLISH request;

5) contains an "id" attribute of the <tuple> element set to the MCData ID;

6) contains one <status> child element of each <tuple> element;

7) contains one <functionalAlias> child element defined in the XML schema defined in table 22.3.1.2-1, of the <status> element, for each MCData ID for which functional alias information is provided;

8) contains one "user" attribute defined in the XML schema defined in table 22.3.1.2-2, of the <functionalAlias> element set to the MCData client ID; and

9) can contain an "expires" attribute defined in the XML schema defined in table 22.3.1.2-2, of the <functionalAlias> element indicating expiration of activation of the functional alias for the MCData user.

Table 22.3.1.2-1: XML schema with elements and attributes extending the application/pidf+xml MIME body

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

targetNamespace="urn:3gpp:ns:mcdataPresInfoFA:1.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:mcdataPIFA10="urn:3gpp:ns:mcdataPresInfoFA:1.0"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<!– MCData functional alias specific child elements of tuple element –>

<xs:element name="functionalAlias" type="mcdataPIFA10:functionalAliasType"/>

<xs:complexType name="functionalAliasType">

<xs:sequence>

<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="functionalAliasID" type="xs:anyURI" use="optional"/>

<xs:attribute name="user" type="xs:anyURI" use="optional"/>

<xs:attribute name="status" type="mcdataPIFA10:statusType" use="optional"/>

<xs:attribute name="expires" type="xs:dateTime" use="optional"/>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

<xs:simpleType name="statusType">

<xs:restriction base="xs:string">

<xs:enumeration value="activating"/>

<xs:enumeration value="activated"/>

<xs:enumeration value="deactivating"/>

<xs:enumeration value="take-over-possible"/>

</xs:restriction>

</xs:simpleType>

<xs:element name="p-id-fa" type="xs:string"/>

<xs:element name="take-over" type="xs:boolean"/>

</xs:schema>

The application/pidf+xml MIME body refers to namespaces using prefixes specified in table 22.3.1.2-2.

Table 22.3.1.2-2: Assignment of prefixes to namespace names in the application/pidf+xml MIME body

Prefix

Namespace

mcdataPIFA10

urn:3gpp:ns:mcdataPresInfoFA:1.0

NOTE: The "urn:ietf:params:xml:ns:pidf" namespace is the default namespace so no prefix is used for it in the application/pidf+xml MIME body.

22.3.2 Extension of application/simple-filter+xml MIME type

22.3.2.1 Introduction

The clauses of the parent clause describe an extension of the application/simple-filter+xml MIME body specified in IETF RFC 4661 [41].

The extension is used to indicate per-user restrictions of presence event package notification information for functional alias information.

22.3.2.2 Syntax

The application/simple-filter+xml MIME body indicating per-user restrictions of presence event package notification information is constructed according to IETF RFC 4661 [41] and:

1) contains a <filter-set> root element according to IETF RFC 4661 [41];

2) contains an <ns-bindings> child element according to IETF RFC 4661 [41], of the <filter-set> element;

3) contains an <ns-binding> child element according to IETF RFC 4661 [41], of the <ns-bindings> element where the <ns-binding> element:

A) contains a "prefix" attribute according to IETF RFC 4661 [41] set to "pidf"; and

B) contains a "urn" attribute set to the "urn:ietf:params:xml:ns:pidf" value;

4) contains a <ns-binding> child element according to IETF RFC 4661 [41], of the <ns-bindings> element where the <ns-binding> element:

A) contains a "prefix" attribute according to IETF RFC 4661 [41], set to "mcdataPIFA10"; and

B) contains an "urn" attribute according to IETF RFC 4661 [41], set to the "urn:3gpp:ns:mcdataPresInfoFA:1.0" value;

5) contains a <filter> child element according to IETF RFC 4661 [41], of the <filter-set> element where the <filter> element;

A) contains an "id" attribute set to a value constructed according to IETF RFC 4661 [41];

B) does not contain a "uri" attribute of the <filter> child element according to IETF RFC 4661 [41]; and

C) does not contain a "domain" attribute according to IETF RFC 4661 [41];

6) contains a <what> child element according to IETF RFC 4661 [41], of the <filter> element; and

7) contains an <include> child element according to IETF RFC 4661 [41], of the <what> element where the <include> element;

A) does not contain a "type" attribute according to IETF RFC 4661 [41]; and

B) contains the value, according to IETF RFC 4661 [41], set to concatenation of the ‘//pidf:presence/pidf:tuple[@id="’ string, the MCData ID, and the ‘"]’ string.

22.4 Functional alias to group binding for the MCData user procedures

22.4.1 General

This clause describes the functional alias to group binding for the MCData user procedures for on-network.

For on-network functional alias to group binding for the MCData user, the procedures for originating MCData clients, participating MCData functions and controlling MCData function are specified in clause X.2.

An MCData user can bind the same functional alias with multiple MCData groups but an MCData user cannot bind multiple functional aliases to the same MCData group.

22.4.2 On-network functional alias to group binding

22.4.2.1 Client procedures

22.4.2.1.1 General

On request from an MCData user at MCData client, a request to create binding of a functional alias with group for the MCData user is initiated by the MCData client towards the participating MCData function.

22.4.2.1.2 Functional alias to group binding

Upon receiving a request from an MCData user to bind a functional alias with an MCData group or a list of MCData groups for the MCData user, if the <allow-functional-alias-binding-with-group> element of the <ruleset> element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", the MCData client shall inform the MCData user and shall exit this procedure.

Upon receiving a request from an MCData user to bind a functional alias with an MCData group or a list of MCData groups for the MCData user, if the requested functional alias is not activated by MCData user at MCData client, the MCData client shall inform the MCData user and shall exit this procedure.

Upon receiving a request from an MCData user to bind a functional alias with an MCData group for the MCData user, the MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The MCData client:

1) shall set the Request-URI to the public service identity identifying the participating MCData function serving the MCData user;

2) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7];

3) shall include an Accept-Contact header field containing the g.3gpp.mcdata media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];

4) 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.mcdata" along with parameters "require" and "explicit" according IETF RFC 3841 [8];

5) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [5];

6) shall include an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 with the <mcdatainfo> element containing the <mcdata-Params> element with:

a) the <request-type> element set to a value of "fa-group-binding-req";

b) the <binding-ind> element set to a value of "true";

c) the <binding-fa-uri> element set to the URI of an activated functional alias that shall be bound with the specified list of MCData groups found in the "uri" attributes of the <entry> element of the <list> elements of the <resource-lists> element in an application/resource-lists+xml MIME body;

d) the <mcdata-client-id> element set to the MCData client ID of the originating MCData client; and

e) if the MCData client needs to include an active functional alias in the SIP MESSAGE request, the <anyExt> element of the <functional-alias-URI> element set to the URI of the used functional alias;

7) shall include an application/resource-lists+xml MIME body with one or more <entry> elements of the <list> elements of the <resource-lists> element where each <entry> element contains a "uri" attribute set to an MCData group ID; and

8) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [5].

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCData client shall inform the MCData user of success in binding of a functional alias with the MCData group or list of MCData groups for the MCData user.

On receiving a SIP 4xx response a SIP 5xx response or a SIP 6xx response to the SIP MESSAGE request, the MCData client shall inform the MCData user of unsuccess in binding of a functional alias with the MCData group or list of MCData groups for the MCData user, possibly taking into account Warning header information for the failure reason.

22.4.2.1.3 Functional alias to group unbinding

Upon receiving a request from an MCData user to unbind a functional alias with an MCData group or a list of MCData groups for the MCData user, if the <allow-functional-alias-binding-with-group> element of the <ruleset> element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", the MCData client shall inform the MCData user and shall exit this procedure.

Upon receiving a request from an MCData user to unbind a functional alias with an MCData group for the MCData user, the MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The MCData client:

1) shall set the Request-URI to the public service identity identifying the participating MCData function serving the MCData user;

2) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7];

3) shall include an Accept-Contact header field containing the g.3gpp.mcdata media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];

4) 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.mcdata" along with parameters "require" and "explicit" according IETF RFC 3841 [8];

5) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [5];

6) shall include an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 with the <mcdatainfo> element containing the <mcdata-Params> element with:

a) the <request-type> element set to a value of "fa-group-binding-req";

b) the <binding-ind> element set to a value of "false";

c) the <unbinding-fa-uri> element set to the URI of a functional alias that shall be unbound from the specified list of MCData groups found in the "uri" attributes of the <entry> elements of the <list> elements of the <resource-lists> element in an application/resource-lists+xml MIME body;

d) the <mcdata-client-id> element set to the MCData client ID of the originating MCData client; and

e) if the MCData client needs to include an active functional alias in the SIP MESSAGE request, the <anyExt> element of the <functional-alias-URI> element set to the URI of the used functional alias;

7) shall include an application/resource-lists+xml MIME body with one or more <entry> elements in one or more <list> elements in the <resource-lists> element where each <entry> element contains a "uri" attribute set to an MCData group ID; and

8) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [5].

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCData client shall inform the MCData user of success in unbinding the functional alias with the MCData group or list of MCData groups for the MCData user.

On receiving a SIP 4xx response a SIP 5xx response or a SIP 6xx response to the SIP MESSAGE request, the MCData client shall inform the MCData user of unsuccess in unbinding of a functional alias with the MCData group or list of MCData groups for the MCData user, possibly taking into account Warning header information for the failure reason.

22.4.2.2 Participating MCData function procedures

22.4.2.2.1 General

The participating MCData function has procedures to:

– receive a request for binding/unbinding of a functional alias with the MCData group(s) for the MCData user from the MCData client.

22.4.2.2.2 Receipt of a SIP MESSAGE request for binding/unbinding of a functional alias with the MCData group(s) for the MCData user

Upon receipt of a "SIP MESSAGE request for binding of a functional alias with the MCData group(s) for the MCData user for originating participating MCData function", the participating MCData function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The participating MCData function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;

2) shall determine the MCData ID of the calling user from the public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request;

NOTE 1: The MCData ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.

3) if the participating MCData function cannot find a binding between the public user identity and an MCData ID or if the validity period of an existing binding has expired, then the participating MCData function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.9, and shall not continue with any of the remaining steps;

4) if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request is set to a value of "fa-group-binding-req" and:

a) the <allow-functional-alias-binding-with-group> element of the <ruleset> element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "176 user not authorized to request for binding/unbinding of a functional alias with the MCData group(s) for the MCData user" in a Warning header field, and shall not continue with the rest of the steps in this clause;

b) the SIP MESSAGE request does not contain an application/resource-lists+xml MIME body or the < binding-ind> element and the <binding-fa-uri> element in the application/vnd.3gpp.mcdata-info+xml MIME body, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "177 unable to determine target functional alias or group for creating/removing a binding information for the MCData user" in a Warning header field, and shall not continue with the rest of the steps in this clause; and

c) the SIP MESSAGE request does not contain an application/resource-lists+xml MIME body or the < binding-ind> element and the <unbinding-fa-uri> element in the application/vnd.3gpp.mcdata-info+xml MIME body, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "177 unable to determine target functional alias or group for creating/removing a binding information for the MCData user" in a Warning header field, and shall not continue with the rest of the steps in this clause;

5) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6];

6) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCData function for the binding of a functional alias with the MCData group(s) for the MCData user service associated with the originating user’s MCData ID identity;

7) shall copy the contents of the application/vnd.3gpp.mcdata-info+xml MIME body in the received SIP MESSAGE request into an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 included in the outgoing SIP MESSAGE request;

8) if the received SIP MESSAGE request contains a <functional-alias-URI> element of the application/vnd.3gpp.mcdata-info+xml MIME body, shall check the status of the functional alias for the MCData ID. If the functional alias status is activated, then the participating MCData function shall set the <functional-alias-URI> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the outgoing SIP MESSAGE request to the received value, otherwise it shall not include a <functional-alias-URI> element;

9) shall set the <mcdata-calling-user-id> element of the <mcdatainfo> element containing the <mcdata-Params> element to the MCData ID determined in step 2) above;

10) shall copy the contents of the application/resource-lists+xml MIME body in the received SIP MESSAGE request into an application/resource-lists+xml MIME body in the outgoing SIP MESSAGE request;

11) shall set the P-Asserted-Identity in the outgoing SIP MESSAGE request to the public user identity in the P-Asserted-Identity header field contained in the received SIP MESSAGE request;

12) shall include an Accept-Contact header field containing the g.3gpp.mcdata media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];

13) 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.mcdata" along with parameters "require" and "explicit" according to IETF RFC 3841 [8];

14) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), into the P-Asserted-Service header field of the outgoing SIP MESSAGE request; and

15) shall send the SIP MESSAGE request as specified to 3GPP TS 24.229 [5].

Upon receipt of a SIP 2xx response in response to the SIP MESSAGE request sent in step 15):

1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5] with the following clarifications:

a) shall include the public user identity received in the P-Asserted-Identity header field of the incoming SIP 200 (OK) response into the P-Asserted-Identity header field of the outgoing SIP 200 (OK) response; and

2) shall send the SIP 200 (OK) response to the MCData client according to 3GPP TS 24.229 [5].

Upon receipt of a SIP 4xx, 5xx or 6xx response to the SIP MESSAGE request, shall forward the error response to the MCData client.

22.4.2.3 Controlling MCData function procedures

22.4.2.3.1 General

The participating MCData function has procedures to:

– receive a request for binding/unbinding of a functional alias with the MCData group(s) for the MCData user from the MCData client.

22.4.2.3.2 Receipt of a SIP MESSAGE request for binding/unbinding of a functional alias with the MCData group(s) for the MCData user

Upon receiving a:

– "SIP MESSAGE request for binding of a functional alias with the MCData group(s) for the MCData user for controlling MCData function";

the controlling MCData function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The controlling MCData function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;

2) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata";

3) the SIP MESSAGE request does not contain an application/resource-lists+xml MIME body or the <binding-ind> element and the <binding-fa-uri> element in the application/vnd.3gpp.mcdata-info+xml MIME body, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "177 unable to determine target functional alias or group for creating/removing a binding information for the MCData user " in a Warning header field, and shall not continue with the rest of the steps in this clause;

4) the SIP MESSAGE request does not contain an application/resource-lists+xml MIME body or the <binding-ind> element and the <unbinding-fa-uri> element in the application/vnd.3gpp.mcdata-info+xml MIME body, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "177 unable to determine target functional alias or group for creating/removing a binding information for the MCData user " in a Warning header field, and shall not continue with the rest of the steps in this clause;

5) if any of the <entry> elements of a <list> element of the <resource-lists> element in the application/resource-lists+xml MIME body of the incoming SIP MESSAGE request contains a "uri" attribute set to an MCData group ID where the indicated MCPTT group has an existing binding with any other functional alias from same MCData user, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "178 MCData group binding already exists with other functional alias" in a Warning header field as specified in clause 4.9, and shall skip the rest of the steps;

6) if the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request contains the <request-type> element set to a value of "fa-group-binding-req" and:

a) if the <binding-ind> element is set to a value of "true", shall update or store the record for the MCData client, and create a binding information for the functional alias specified in the <binding-fa-uri> element with the list of the MCData group(s) included in the "uri" attributes of the <entry> elements of the set of <list> elements of the <resource-lists> element in an application/resource-lists+xml MIME body; or

b) if the <binding-ind> element is set to a value of "false", shall update or store the record for the MCData client, and remove a binding information of the functional alias specified in the <unbinding-fa-uri> element from the list of the MCData group(s) included in the "uri" attributes of the <entry> elements of the set of <list> elements of the <resource-lists> element in an application/resource-lists+xml MIME body;

7) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5]with the following clarifications:

a) shall include the public user identity in the P-Asserted-Identity header field of the outgoing SIP 200 (OK) response; and

8) shall send the SIP 200 (OK) response to the MCData client according to 3GPP TS 24.229 [5].