4 General
24.2813GPPMission Critical Video (MCVideo) signalling controlProtocol specificationRelease 18TS
4.1 MCVideo overview
The MCVideo service supports communication between several users (i.e. group call), where each user has the ability to send and receive video media. The MCVideo service also supports private calls between two users. Group calls and private calls can be provided on-network and off-network.
The present document provides the call control protocol to support the MCVideo architectural procedures specified in 3GPP TS 23.281 [26].
For on-network calls, the present document makes use of the existing IMS procedures specified in 3GPP TS 24.229 [11]. For on-network group calls, the procedures in the present document allow the use of unicast bearers.
The on-network procedures in this document allow an MCVideo user to:
– initiate a new MCVideo group session;
– join an MCVideo group session that has already been established;
– leave an established MCVideo group session and then re-join the same MCVideo group session if still established; and
– use a functional alias to identify the MCVideo user.
For off-network calls, the present document utilises the procedures for ProSe direct discovery for public safety and the procedures for one-to-one ProSe direct communication for Public Safety, as specified in 3GPP TS 24.334 [59] . ProSe is only supported in EPS. The present document specifies the MCVideo Off-Network Protocol (MVONP) and the MVONP application procedures.
For on-network and off-network calls, the present document provides support for MCVideo emergency calls, MCVideo imminent-peril calls and MCVideo emergency alerts.
NOTE: MCVideo emergency calls do not utilise emergency bearers. Instead the EPS bearer priority of a normal bearer is adjusted.
The MCVideo procedures provided by the present document refer to:
– the transmission-control procedures defined in 3GPP TS 24.581[5];
– the group management procedures defined in 3GPP TS 24.481 [24];
– the identity management procedures defined in 3GPP TS 24.482 [52];
– the security procedures defined in 3GPP TS 33.180 [8]; and
the PS-PS access transfer procedures defined in 3GPP TS 24.237 [60].
The MCVideo procedures provided by the present document access the configuration parameters provided by 3GPP TS 24.483 [4] and 3GPP TS 24.484 [25].
Codecs and media handling for MCVideo are specified in 3GPP TS 26.281 [61];
The following procedures are provided within this document:
– common procedures are specified in clause 6;
– procedures for registration in the IM CN subsystem and service authorisation are specified in clause 7;
– procedures for affiliation are specified in clause 8;
– procedures for on-network and off-network group call are specified in clause 9;
– procedures for on-network and off-network private call are specified in clause 10;
– procedures for on-network and off-network emergency alert are specified in clause 11; and
– procedures for management of functional alias in clause 20;
The MCVideo UE primarily obtains access to the MCVideo service via E-UTRAN or NG-RAN, using the procedures defined in 3GPP TS 24.301 [62] and 3GPP TS 24.501 [76].
4.2 URI and address assignments
In order to support MCVideo, the following URI and address assignments are assumed:
1) the participating MCVideo function is configured to be reachable using:
a) the public service identity of the participating MCVideo function serving the MCVideo user.
4.3 MCVideo media
A session that contains MCVideo media is either a full-duplex session or a half-duplex session with an SDP media component containing an MCVideo media type with a codec suitable that exists between an MCVideo client and an MCVideo server.
If the MCVideo media session is a half-duplex session, it additionally contains a media component that describes the characteristics of the media-transmission control entity.
In many instances, the MCVideo media has the video component and the audio component generated at the source as one unified (and usually video-audio synchronized) stream, in which case it makes sense to also transport the MCVideo packets as one multi-media stream and indicate the absence of a separate audio component, as described in 3GPP TS 24.581 [5], clause 9.3.3.3. The QoS information associated with the transmission (QCI and SDP) is set at the operator’s discretion, but the used QoS parameters need to have values that, on delivery to the UE, accommodate the desired QoS for reception. 3GPP TS 23.203 [69] has standardized the QCI value 67 for MCVideo transmissions, to be used in case a better suited value cannot be found.
NOTE 1: The intended use of the QCI is not for the QoS of the MBMS bearers, but for public safety UEs which receive the MBS Bearer Announcement message and use the QoS parameters associated with the QCI (e.g., Priority level, Packet error loss rate) for retransmission of packets, when acting as UE-to-UE relays.
There may be cases where the video component and audio component are streamed separately. In this situation, the presence of the separate audio stream is indicated as described in 3GPP TS 24.581 [5], clause 9.3.3.3, and both streams are carried over the same MBMS bearer.
NOTE 2: At any time, application‑level signalling supports the association of at most one MBMS bearer to an MCVideo group. That means that the used MBMS bearer has to be able to support the transport of both the video and the audio media.
NOTE 3: An MCVideo client may handle several MCVideo groups at a time, and those MCVideo groups may each use its own MBMS bearer or may share an MBMS bearer with another MCVideo group. Since there is only one SDP record (the one in the most recently received MBMS Bearer Announcement message containing an SDP record, as described in clause 16.3.2.1) associated with an MCVideo client at a given time, all used streams have to be identified by the line number of an "m=" line within the SDP record.
4.4 Warning header field
4.4.1 General
The MCVideo server can include a free text string in a SIP response to a SIP request. When the MCVideo server includes a text string in a response to a SIP INVITE request the text string is included in a Warning header field as specified in IETF RFC 3261 [15]. The MCVideo server includes the Warning code set to 399 (miscellaneous warning) and includes the host name set to the host name of the MCVideo server.
EXAMPLE: Warning: 399 "100 User not authorised to make group calls"
4.4.2 Warning texts
The text string included in a Warning header field consists of an explanatory text preceded by a 3-digit text code, according to the following format in Table 4.4.2-1.
Table 4.4.2-1 ABNF for the Warning text
warn-text =/ DQUOTE mcvideo-warn-code SP mcvideo-warn-text DQUOTE
mcvideo-warn-code = DIGIT DIGIT DIGIT
mcvideo-warn-text = *( qdtext | quoted-pair )
Table 4.4.2-2 defines the warning texts that are defined for the Warning header field when a Warning header field is included in a response to a SIP INVITE request as specified in clause 4.4.1.
Table 4.4.2-2: Warning texts defined for the Warning header field
|
Code |
Explanatory text |
Description |
|||||||||
|
100 |
function not allowed due to <detailed reason> |
The function is not allowed to this user. The <detailed reason> will be either "group definition", "access policy", "local policy", or "user authorisation", or can be a free text string. |
|||||||||
|
101 |
service authorisation failed |
The service authorisation of the MCVideo ID against the IMPU failed at the MCVideo server. |
|||||||||
|
102 |
too many simultaneous affiliations |
The MCVideo user already has N2 maximum number of simultaneous affiliations (see <MaxAffiliationsN2> element of user profile configuration document). |
|||||||||
|
103 |
maximum simultaneous MCVideo group calls reached |
The number of maximum simultaneous MCVideo group calls supported for the MCVideo user has been exceeded. |
|||||||||
|
104 |
isfocus not assigned |
A controlling MCVideo function has not been assigned to the MCVideo session. |
|||||||||
|
105 |
subscription not allowed in a broadcast group call |
Subscription to the conference event package rejected during a group call initiated as a broadcast group call. |
|||||||||
|
106 |
user not authorised to join chat group |
The MCVideo user is not authorised to join this chat group. |
|||||||||
|
107 |
user not authorised to make private calls |
The MCVideo user is not authorised to make private calls. |
|||||||||
|
108 |
user not authorised to make chat group calls |
The MCVideo user is not authorised to make chat group calls. |
|||||||||
|
109 |
user not authorised to make prearranged group calls |
The MCVideo user is not authorised to make group calls to a prearranged group. |
|||||||||
|
110 |
user declined the call invitation |
The MCVideo user declined to accept the call. |
|||||||||
|
111 |
group call proceeded without all required group members |
The required members of the group did not respond within the acknowledged call time, but the call still went ahead. |
|||||||||
|
112 |
group call abandoned due to required group members not part of the group session |
The group call was abandoned, as the required members of the group did not respond within the acknowledged call time. |
|||||||||
|
113 |
group document does not exist |
The group document requested from the group management server does not exist. |
|||||||||
|
114 |
unable to retrieve group document |
The group document exists on the group management server but the MCVideo server was unable to retrieve it. |
|||||||||
|
115 |
group is disabled |
The group has the <disabled> element set to "true" in the group management server. |
|||||||||
|
116 |
user is not part of the MCVideo group |
The group exists on the group management server but the requesting user is not part of this group. |
|||||||||
|
117 |
the group identity indicated in the request is a prearranged group |
The group id that is indicated in the request is for a prearranged group, but did not match the request from the MCVideo user. |
|||||||||
|
118 |
the group identity indicated in the request is a chat group |
The group id that is indicated in the request is for a chat group, but did not match the request from the MCVideo user, |
|||||||||
|
119 |
user is not authorised to initiate the group call |
The MCVideo user identified by the MCVideo ID is not authorised to initiate the group call. |
|||||||||
|
120 |
user is not affiliated to this group |
The MCVideo user is not affiliated to the group. |
|||||||||
|
121 |
user is not authorised to join the group call |
The MCVideo user identified by the MCVideo ID is not authorised to join the group call. |
|||||||||
|
122 |
too many participants |
The group call has reached its maximum number of participants. |
|||||||||
|
123 |
MCVideo session already exists |
Inform the MCVideo user that the group call is currently ongoing. |
|||||||||
|
124 |
maximum number of private calls reached |
The maximum number of private calls allowed at the MCVideo server for the MCVideo user has been reached. |
|||||||||
|
125 |
user not authorised to make private call with automatic commencement |
The MCVideo user is not authorised to make a private call with automatic commencement. |
|||||||||
|
126 |
user not authorised to make private call with manual commencement |
The MCVideo user is not authorised to make a private call with manual commencement. |
|||||||||
|
127 |
user not authorised to be called in private call |
The called MCVideo user is not allowed to be part of a private call. |
|||||||||
|
128 |
isfocus already assigned |
The MCVideo server owning an MCVideo group received a SIP INVITE request destined to the MCVideo group from another MCVideo server already assigned as the controlling MCVideo function and the MCVideo server owning the MCVideo group does not support mutual aid or supports trusted mutual aid but does not authorise trusted mutual aid. |
|||||||||
|
137 |
the indicated group call does not exist |
The participating MCVideo function cannot find an ongoing group session associated with the received MCVideo session identity. |
|||||||||
|
138 |
subscription of conference events not allowed |
The controlling MCVideo function could not allow the MCVideo user to subscribe to the conference event package. |
|||||||||
|
139 |
integrity protection check failed |
The integrity protection of an XML MIME body failed. |
|||||||||
|
140 |
unable to decrypt XML content |
The XML content cannot be decrypted. |
|||||||||
|
141 |
user unknown to the participating function |
The participating function is unable to associate the public user identity with an MCVideo ID. |
|||||||||
|
142 |
unable to determine the controlling function |
The participating function is unable to determine the controlling function for the group call or private call. |
|||||||||
|
143 |
not authorised to force auto answer |
The calling user is not authorised to force auto answer on the called user. |
|||||||||
|
144 |
user not authorised to call this particular user |
The calling user is not authorised to call this particular called user. |
|||||||||
|
145 |
unable to determine called party |
The participating function was unable to determine the called party from the information received in the SIP request. |
|||||||||
|
146 |
T-PF unable to determine the service settings for the called user |
The service settings have not been uploaded by the terminating client to the terminating participating server. |
|||||||||
|
147 |
user is authorized to initiate a temporary group call |
The non-controlling MCVideo function has authorized a request from the controlling MCVideo function to authorize a user to initiate an temporary group session. |
|||||||||
|
148 |
group is regrouped |
The MCVideo group hosted by a non-controlling MCVideo function is part of a temporary group session as the result of the group regroup function. |
|||||||||
|
149 |
SIP-INFO request pending |
The MCVideo client needs to wait for a SIP-INFO request with specific content, before taking further action. |
|||||||||
|
150 |
invalid combinations of data received in MIME body |
The MCVideo client included invalid combinations of data in the SIP request. |
|||||||||
|
154 |
user not authorised to make ambient viewing call |
The MCVideo user is not authorised to make an ambient viewing call. |
|||||||||
|
159 |
user not authorised to be called by this originating user |
The called user is not authorised to receive a call by this originating user. |
|||||||||
|
160 |
user not authorised to request creation of a regroup |
The user is not authorised to request creation of a regroup. |
|||||||||
|
161 |
user not authorised to request removal of a regroup |
The user is not authorised to request removal of a regroup. |
|||||||||
|
162 |
group call abandoned due to required group members not affiliated |
The group call was abandoned as the required number of affiliated group members is not met or some required members are not affiliated. |
|||||||||
|
163 |
the group identity indicated in the request does not exist |
The server determines that the group identity indicates a user or group regroup based on a preconfigured group that does not exist. |
|||||||||
|
165 |
group ID for regroup already in use |
The group ID proposed by the client for the user/group regroup based on a preconfigured group is already in use. |
|||||||||
|
166 |
maximum number of service authorizations reached |
The number of maximum simultaneous service authorizations for the MCVideo user has been reached. |
|||||||||
|
167 |
call is not allowed on the preconfigured group |
Calls are not allowed on this group that is administratively designated for preconfigured group use only. |
|||||||||
|
168 |
alert is not allowed on the preconfigured group |
Alerts are not allowed on this group that is administratively designated for preconfigured group use only. |
|||||||||
|
171 |
functional alias not allowed to call this particular functional alias |
The calling user is not authorised to call this particular functional alias by using this activated functional alias |
|||||||||
|
172 |
functional alias not allowed to be called from this functional alias |
The called functional alias is not authorised to receive a call from the originating user using this particular Functional Alias |
|||||||||
|
176 |
user not authorized to request for binding/unbinding of a functional alias with the MCVideo group(s) for the MCVideo user |
The function is not allowed to this user. |
|||||||||
|
177 |
unable to determine target functional alias or group for creating/removing a binding information for the MCVideo user |
The MCVideo server is unable to determine the targeted functional alias or group for creating/removing an binding information for the MCVideo user |
|||||||||
|
178 |
MCVideo group binding already exists with other functional alias for the MCVideo user |
The requested functional alias binding with MCVideo group already exist with other functional alias for the MCVideo user |
|||||||||
|
179 |
service not authorized with the interconnected system |
The MCVideo service is not authorized between the local and the interconnected system and is rejected in the local system |
|||||||||
|
180 |
service not authorized by the interconnected system |
The MCVideo service is not authorized between the local and the interconnected system and is rejected by the interconnected system |
4.5 MCVideo session identity
The MCVideo session identity is a SIP URI, which identifies the MCVideo session between:
– the MCVideo client and the participating MCVideo function; and
– the participating MCVideo function and the controlling MCVideo function;
The MCVideo session identity shall be a GRUU as defined in IETF RFC 5627 [41] assigned by the MCVideo server as per 3GPP TS 24.229 [11].
The MCVideo session identity identifies the MCVideo session in such a way that e.g.:
– the MCVideo user is able to subscribe to the participant information of the ongoing MCVideo session;
– the MCVideo user is able to re-join an ongoing MCVideo session; and
– the IM CN subsystem is able to route an initial SIP request to the controlling MCVideo function.
The controlling MCVideo function allocates a unique MCVideo session identity hosted at the controlling MCVideo function for the MCVideo session at the time of session establishment.
When protection of sensitive application data is required by the MCVideo operator, the MCVideo session identity cannot contain identity information that is classed as sensitive such as the MCVideo ID or the MCVideo Group ID, as specified in clause 4.8.
The controlling MCVideo function sends the MCVideo session identity towards the MCVideo client during MCVideo session establishment by including it in the Contact header field of the final SIP response to a session initiation request.
The participating MCVideo function allocates a unique MCVideo session identity hosted at the participating MCVideo function for the MCVideo session when it receives a MCVideo session identity in the Contact header field of a SIP request or a SIP response from the controlling MCVideo function and includes it in the Contact header field of the SIP request or SIP response sent towards the MCVideo client. The participating MCVideo function maintains a mapping of the MCVideo session identities it sends to the MCVideo client to the corresponding MCVideo session identities received from the controlling MCVideo function.
The MCVideo client can cache the MCVideo session identity until a time when it is no longer needed.
The MCVideo session identity is also used in transmission control requests and responses as specified in 3GPP TS 24.581 [5].
4.6 MCVideo priority calls and alerts
4.6.1 MCVideo emergency group calls
MCVideo emergency group calls as defined by 3GPP TS 23.281 [26] are supported by the procedures in this specification. The following MCVideo emergency group call functionalities are described:
– MCVideo emergency group call origination;
– upgrade of an MCVideo group call to an MCVideo emergency group call; and
– in-progress group emergency cancel.
NOTE 1: In-progress group emergency cancel means the cancellation of the in-progress emergency state of the group, which is managed by the controlling MCVideo function.
The above functionalities are supported using both MCVideo prearranged group calls and MCVideo chat group calls.
Key aspects of MCVideo emergency group calls include:
– adjusted EPS bearer priority for all participants whether or not they themselves are in an emergency condition (i.e. have their MCVideo emergency state set). For unicast bearers this is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [33] with namespaces defined for use by MCVideo specified in IETF RFC 8101 [48], and for MBMS bearers this is achieved by having the participating MCVideo function adjust the ARP (priority, PVI, PCI) and executing the Modify MBMS Bearer Procedure per 3GPP TS 29.468 [44];
– pre-emptive transmission control priority over MCVideo users in MCVideo emergency group calls who themselves do not have their MCVideo emergency state set;
– restoration of normal EPS bearer priority to the call participants when the in-progress emergency group state is cancelled;
– restoration of normal transmission control priority participants when the in-progress emergency group state is cancelled;
– requires the MCVideo user to be authorised to either originate or cancel an MCVideo emergency group call;
– requests to originate MCVideo emergency group calls may also include an indication of an MCVideo emergency alert; and
– requests to cancel MCVideo emergency group calls may also include an indication of cancelling a previously issued MCVideo emergency alert.
There are a number of states that are key in managing these aspects of MCVideo emergency group calls, which include:
– MCVideo emergency state: as defined in 3GPP TS 22.281 [36] and 3GPP TS 23.281 [26], indicates that the MCVideo user is in a life-threatening situation. Managed by the MCVideo user of the device or an authorised MCVideo user. While the MCVideo emergency state is set on the client, all calls originated by the client will be MCVideo emergency calls, assuming the MCVideo user is authorised for MCVideo emergency calls on them.
– in-progress emergency group state: as defined in 3GPP TS 22.281 [36] and 3GPP TS 23.281 [26], indicates whether or not there is an MCVideo emergency group call ongoing on the specified group. This state is managed by the controlling MCVideo function. All group calls originated on this MCVideo group when in an in-progress emergency state are MCVideo emergency group calls until this state is cancelled, whether or not the originator is themselves in an MCVideo emergency state.
– MCVideo emergency group (MVEG) state: this is an internal state managed by the MCVideo client which tracks the in-progress emergency state of the group as defined in 3GPP TS 22.281 [36] and 3GPP TS 23.281 [26] and managed by the controlling MCVideo function. Ideally, the MCVideo client would not need to track the in-progress emergency group state, but doing so enables the MCVideo client to request MCVideo emergency-level priority earlier than otherwise possible. For example, if the MCVideo user wishes to join an MCVideo emergency group call and is not in MCVideo emergency state itself, the MCVideo client should have emergency level priority. If it has knowledge of the in-progress emergency state of the group, it can request priority by including a Resource-Priority header field set to the MCVideo namespace specified in IETF RFC 8101 [38], and appropriate priority level in the SIP INVITE request (or SIP re-INVITE request).
– MCVideo emergency group call (MVEGC) state: this is an internal state managed by the MCVideo client which in conjunction with the MCVideo emergency alert state aids in managing the MCVideo emergency state and related actions.
– MCVideo emergency alert (MEA) state: this is also an internal state of the MCVideo client which in conjunction with the MCVideo emergency group call state aids in managing the MCVideo emergency state and related actions.
NOTE 2: The above states and their transitions are described in annex G.
4.6.2 MCVideo emergency private calls
MCVideo emergency private calls as defined by 3GPP TS 23.281 [26] are supported by the procedures in this specification. The following MCVideo emergency private call functionalities are specified in the present document:
– MCVideo emergency private call origination with optional MCVideo emergency alert initiation;
– upgrade of an MCVideo private call to an MCVideo emergency private; and
– cancellation of the MCVideo emergency private call priority.
Key aspects of MCVideo emergency private calls include:
– adjusted EPS bearer priority for both participants whether or not they are both in an emergency condition (i.e. both have their MCVideo emergency state set). This is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [33] with namespaces defined for use by MCVideo specified in IETF RFC 8101 [38];
– the initiator of the MCVideo emergency private call can override the other MCVideo user in the MCVideo emergency private call unless that user also has their MCVideo emergency state set;
– restoration of normal EPS bearer priority to the call according to system policy (e.g., configured time limit for the emergency priority of an MCVideo emergency private call or cancellation of the emergency condition of the private call);
– restoration of normal transmission control priority participants when the emergency elevated priority is cancelled;
– requires the MCVideo user to be authorised to either originate or cancel an MCVideo emergency private call;
– requires the targeted MCVideo user to be authorised to receive an MCVideo emergency private call;
– requests to originate MCVideo emergency private calls may also include an indication of an MCVideo emergency alert; and
– the originator of the MCVideo emergency private call can request that the call use either manaual or automatic commencement mode.
There are a number of states that are key in managing these aspects of MCVideo emergency private calls, which include:
– MCVideo emergency state (MVES): as defined in 3GPP TS 22.281 [36] and 3GPP TS 23.281 [26], indicates that the MCVideo user is in a life-threatening situation. Managed by the MCVideo user of the device or an authorised MCVideo user. While the MCVideo emergency state is set on the client, all MCVideo group and private calls originated by the client will be MCVideo emergency calls, assuming the MCVideo user is authorised for MCVideo emergency calls on them.
– MCVideo private emergency alert (MVPEA) state: this is an internal state of the MCVideo client which in conjunction with the MCVideo emergency private call state aids in managing the MCVideo emergency state and related actions.
– MCVideo emergency private call (MVEPC) state: this is an internal state managed by the MCVideo client which in conjunction with the MCVideo emergency alert state aids in managing the MCVideo emergency state and related actions.
– In-progress emergency private call (IPEPC) state: indicates whether or not there is an MCVideo emergency private call in-progress for the two participants. This state is managed by the controlling MCVideo function. All private calls originated between these two participants when in an in-progress emergency private call state are MCVideo emergency private calls until this state is cancelled, whether or not the originator is in an MCVideo emergency state.
– MCVideo emergency private priority (MVEPP) state: this is an internal state managed by the MCVideo client which tracks the in-progress emergency private call state of the private call managed by the controlling MCVideo function. Ideally, the MCVideo client would not need to track the in-progress emergency private priority state, but doing so enables the MCVideo client to request MCVideo emergency-level priority earlier than otherwise possible. For example, if the MCVideo user wishes to join an MCVideo emergency private call and is not in the MCVideo emergency state, the MCVideo client should have emergency level priority. If it has knowledge of the in-progress emergency private priority state of the private call (i.e., the two participants), it can request priority by including a Resource-Priority header field set to the MCVideo namespace specified in IETF RFC 8101 [38], and appropriate priority level in the SIP INVITE request (or SIP re-INVITE request).
NOTE: The above states and their transitions are described in annex G.
4.6.3 MCVideo emergency alerts
MCVideo emergency alerts as defined by 3GPP TS 23.281 [26] are supported by the procedures in this specification. The following MCVideo emergency group call functionalities are specified in the present document:
– MCVideo emergency alert origination; and
– MCVideo emergency alert cancellation.
MCVideo emergency alerts are supported procedurally by two general mechanisms. One mechanism is embedded within the MCVideo emergency call (both emergency private call and emergency group call using both prearranged and chat session models) signalling procedures documented in clause 9 and clause 10 of this specification. The other mechanism utilizes SIP MESSAGE requests and is documented in clause 11.
MCVideo emergency alerts can be initiated or cancelled as options in the following signalling procedures documented in clause 9 and clause 10:
– MCVideo emergency group call initiation;
– MCVideo group call upgraded to MCVideo emergency call;
– MCVideo emergency group call cancellation (i.e., in-progress emergency state of the group set to false);
– MCVideo emergency private call initiation; and
– MCVideo private call upgrade to MCVideo emergency private call.
MCVideo emergency alerts can also be initiated or cancelled as described in the procedures of clause 11 which include:
– MCVideo emergency alert initiation; and
– MCVideo emergency alert cancellation (with optional cancelling of the in-progress emergency state of a group).
When MCVideo emergency alerts are initiated as an option in initiating or upgrading to an MCVideo emergency group call or are initiated using SIP MESSAGE requests, they are targeted to an MCVideo group, and, if not already affiliated, will result in the initiator being implicitly affiliated to the MCVideo group. When initiated as an option in initiating or upgrading to an MCVideo emergency private call, an MCVideo emergency alert is targeted to an individual MCVideo user, not to an MCVideo group.
Key aspects of MCVideo emergency alerts include:
– MCVideo emergency (MVES) state: the MCVideo client’s MCVideo emergency state as described in clause G.1 is set upon initiation of an MCVideo emergency alert. While the MCVideo emergency state is set, assuming the MCVideo user has the needed authorisations, if the user initiates a private call and is authorised to do so, the MCVideo private call will be an MCVideo emergency private call. Similarly, assuming the needed authorisations, any subsequent MCVideo group call initiated by an MCVideo user with the MCVideo emergency state set will be an MCVideo emergency group call.
– MCVideo emergency alert (MVEA) state: the MCVideo client maintains the internal MCVideo emergency alert state (MVEA) which aids in the management of the MCVideo emergency state as described in clause G.5.
– MCVideo private emergency alert (MVPEA) state: the MCVideo client maintains the MCVideo private emergency alert state of an MCVideo emergency alert targeted to an MCVideo user which aids in the management of the MCVideo emergency state.
– In-progress emergency group (IPEG) state : MCVideo emergency alert initiation or cancellation in and of itself does not impact the in-progress emergency state of the targeted group, which is maintained by the controlling MCVideo function, nor does it impact the priority of the EPS bearers. However, in setting the MCVideo emergency state, assuming an MCVideo user is authorised to make MCVideo emergency calls on the targeted group, any subsequent MCVideo group call the MCVideo user initiates on the group will cause the in-progress emergency state of the group to be set as described in clause G.2 and will result in upgraded priority of the EPS bearers used in the MCVideo emergency call.
– Authorisations for emergency alerts: MCVideo users need to be authorised to initiate MCVideo emergency alerts and additionally need to be authorised to cancel MCVideo emergency alerts. The parameters related to these authorisations are specified in 3GPP TS 24.483 [4] and 3GPP TS 24.484 [25].
4.6.4 MCVideo imminent peril group call
MCVideo imminent peril group calls as defined by 3GPP TS 23.281 [26] are supported by the procedures in this specification. The following MCVideo imminent peril group calls functionalities are specified in the present document:
– MCVideo imminent peril group calls origination;
– upgrade of an MCVideo group call to an MCVideo imminent peril group call;
– upgrade from an MCVideo imminent peril group call to an MCVideo emergency group call; and
– cancellation of the in-progress imminent peril state of the group.
Key aspects of MCVideo imminent peril include:
– adjusted EPS bearer priority for all participants when the in-progress imminent peril state of the group is set whether or not they themselves initiated an imminent peril group call. For unicast bearers this is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [33] with namespaces defined for use by MCVideo specified in IETF RFC 8101 [38], and for MBMS bearers this is achieved by having the participating MCVideo function adjust the ARP (priority, PVI, PCI) and executing the Modify MBMS Bearer Procedure per 3GPP TS 29.468 [44];
– restoration of normal EPS bearer priority to the call when the in-progress imminent peril group state is cancelled; and
– requires the MCVideo user to be authorised to either originate or cancel an MCVideo imminent peril group call.
Relationship to other MCVideo priority group call types:
– A normal MCVideo group call can be upgraded to an MCVideo imminent peril group call;
– An MCVideo imminent peril group call can be upgraded to an MCVideo emergency group call;
– When either an MCVideo imminent peril group call or an MCVideo emergency group call (i.e., their respective "in-progress" states) the group call returns to the priority designated for normal group calls, i.e., their is no direct transition from an MCVideo emergency group call to an MCVideo imminent peril group call;
– MCVideo imminent peril functionality is only applicable to MCVideo group calls, not MCVideo private calls; and
– MCVideo imminent peril group calls have no associated alert capabilities such as the MCVideo emergency alert capability which is associated with MCVideo emergency group calls.
There are a number of states that are key in managing these aspects of MCVideo imminent peril group calls, which include:
– MCVideo imminent peril group (MVIG) state: this is an internal state of the MCVideo client which in conjunction with the MCVideo imminent peril group call state aids the client in managing the use of the Resource-Priority header field and related actions.
– MCVideo imminent peril group call (MVIGC) state: this is an internal state managed by the MCVideo client which in conjunction with the MCVideo imminent peril group state aids the client in managing the use of the Resource-Priority header field and related actions.
– In-progress imminent peril group (IPIG) state: this a state of the MCVideo group which is managed by the controlling MCVideo function. While an MCVideo group is in an in-progress imminent peril group state, all participants in group calls using this group will receive elevated priority.
The above states and their transitions are described in annex G.
4.7 Communication security
4.7.1 Media security
If a mission critical organisation requires MCVideo users to communicate using end-to-end security, a security context needs to be established between the initiator of the call and the recipient(s) of the call, prior to the establishment of media, or transmission control signalling. This provides assurance to MCVideo users that no unauthorised access to communications is taking place within the MCVideo network. An MCVideo key management server (KMS) manages the security domain. For any end-point to use or access end-to-end secure communications, it needs to be provisioned with keying material associated to its identity by the KMS as specified in 3GPP TS 33.180 [8].
The MIKEY-SAKKE message in the SIP INVITE/REFER provides a single PCK/PCK-ID, which is used to derive the SRTP session key for both the video and audio streams. For floor and media control, the SRTCP key is different depending on which interface the SRTCP key is currently traversing (see 3GPP TS 33.180 [8]). For unicast uplink and downlink between the client and the server, the SRTCP key is the appropriate CSK/CSK-ID. Between two MCVideo servers, the SRTCP key is the SPK/SPK-ID. For multicast (when used), the SRTCP key is the MuSiK/MuSiK-ID. For a more complete description of media plane security for MCVideo see clause 13 of 3GPP TS 24.581 [5].
For group calls, the security context is set up at the time of creation of the group. The group management server creates group call keying material associated with the group and distributes it to all members of the group, in advance of the initiation of a group call as specified in 3GPP TS 24.481 [24] and 3GPP TS 33.180 [8]. The establishment of a security context for group calls has no impact on this specification.
For private calls, the security context is initiated at call setup. An end-to-end security context is established that is unique to the pair of users involved in the call. The procedure involves transferral of an encapsulated private call key (PCK) and private call key id (PCK-ID) from the initiator to the terminator. The PCK is encrypted using the terminator’s MCVideo ID and domain-specific material provided from the terminating user’s KMS. The domain-specific key material of the terminator’s KMS is identified by a KMS URI stored in the terminating user profile. The domain-specific key material for all KMSs is downloaded in advance from the initiator’s home KMS as described in 3GPP TS 33.180 [8]. The PCK and PCK-ID are distributed within a MIKEY payload within the SDP offer of the private call request. This payload is called a MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [55], which ensures the confidentiality, integrity and authenticity of the payload. The encoding of the MIKEY payload in the SDP offer is described in IETF RFC 4567 [6] using an "a=key-mgmt" attribute. The payload is signed using a key associated to the identity of the initiating user. At the terminating side, the signature is validated. If valid, the UE extracts and decrypts the encapsulated PCK. The MCVideo UE also extracts the PCK-ID. This process is described in 3GPP TS 33.180 [8]. With the PCK successfully shared between the two MCVideo UEs, the UEs are able to use SRTP/SRTCP to create an end-to-end secure session.
End-to-end security is independent of the transmission path and hence is applicable to both on and off-network communications. With a security context established, the group call key and private call key can be used to encrypt media and, if required, transmission control traffic between the end-points as described in 3GPP TS 24.581 [5].
4.7.2 Signalling security
Signalling security is established between the participating MCVideo function and the MCVideo client. This allows the following signalling to be integrity and confidentiality protected through the SIP core:
– Sensitive application data (as described in clause 4.8)
– Transmission control messages sent using unicast
– Media control messages
For unicast signalling between the participating MCVideo function and the MCVideo client, the signalling is protected using the Client-Server Key (CSK), identified by a Client-Server Key Identifer (CSK-ID). The CSK and CSK-ID are uploaded from the MCVideo client to the MCVideo server within a MIKEY MIME payload within a SIP REGISTER message for service authorisation or a SIP PUBLISH message for service authorisation. The CSK is confidentiality and integrity protected to the public service identity identifying the participating MCVideo function serving the MCVideo user and signed by the MCVideo ID of the MCVideo user.
The CSK and CSK-ID may also be updated by the participating MCVideo function. The procedure involves the participating MCVideo function generating a new CSK and CSK-ID and distributing the new key to the MCVideo client using a CSK ‘key download’ SIP MESSAGE. The message contains a MIKEY MIME payload containing the CSK and CSK-ID. The CSK is confidentiality and integrity protected to the public service identity identifying the participating MCVideo function serving the MCVideo user and signed by the MCVideo ID of the MCVideo user. The client only uses a single CSK at any one time and discards the previously established CSK on receiving a new CSK.
4.8 Protection of sensitive application data.
In certain deployments, for example, in the case that the MCVideo operator uses the underlying SIP core infrastructure from the carrier operator, the MCVideo operator can prevent certain sensitive application data from being visible in the clear to the SIP layer. The following data are classed as sensitive application data:
– MCVideo ID;
– MCVideo group ID;
– user location information;
– emergency, alert and imminent-peril indicators;
– access token (containing the MCVideo ID);
– MCVideo client ID; and
– functional alias.
The above data is transported as XML content in SIP messages. in XML elements or XML attributes.
Data is transported in attributes in the following circumstances in the procedures in the present document:
– an MCVideo ID, an MCVideo Group ID, and an MCVideo client ID in an XML document published in SIP PUBLISH request for affiliation according to IETF RFC 3856 [13];
– an MCVideo ID or an MCVideo Group ID in XML document notified in a SIP NOTIFY request for affiliation according to IETF RFC 3856 [13];
– an MCVideo ID in application/resource-lists+xml document included in an SIP INVITE request setting up a private call according to IETF RFC 5366 [37]; and
– an MCVideo ID in XML document provided in SIP NOTIFY request of a conference event package according to IETF RFC 4575 [57];
– an MCVideo ID and functional alias in an XML document published in SIP PUBLISH request for functional alias management according to IETF RFC 3856 [13]; and
– an MCVideo ID and functional alias in an XML document notified in a SIP NOTIFY request for functional alias management according to IETF RFC 3856 [13].
3GPP TS 33.180 [8] describes a method to provide confidentiality protection of sensitive application data in elements by using XML encryption (i.e. xmlenc) and in attributes by using an attribute confidentiality protection scheme described in clause 6.6.2.3 of the present document. Integrity protection can also be provided by using XML signatures (i.e. xmlsig).
Protection of the data relies on a shared XML protection key (XPK) used to encrypt and sign data:
– between the MCVideo client and the MCVideo server, the XPK is a client-server key (CSK); and
– between MCVideo servers and between MCVideo domains, the XPK is a signalling protection key (SPK).
The CSK (XPK) and a key-id CSK-ID (XPK-ID) are generated from keying material provided by the key management server. Identity based public key encryption based on MIKEY-SAKKE is used to transport the CSK between SIP end-points. The encrypted CSK is transported from the MCVideo client to the MCVideo server when the MCVideo client performs service authorisation as described in clause 7 and is also used during service authorisation to protect the access token.
The SPK (XPK) and a key-id SPK-ID (XPK-ID) are directly provisioned in the MCVideo servers.
Configuration in the MCVideo client and MCVideo server is used to determine whether one or both of confidentiality protection and integrity protection are required.
4.9 MCVideo client ID
The MCVideo client assigns the MCVideo client ID when the MCVideo client is used for the first time. The MCVideo client generates the MCVideo client ID as specified in clause 4.2 of IETF RFC 4122 [58].
The MCVideo client preserves the MCVideo client ID:
– while the MCVideo client is SIP registered as specified in 3GPP TS 24.229 [11];
– while the MCVideo client is not SIP registered as specified in 3GPP TS 24.229 [11] and the UE serving the MCVideo client is switched on;
– while the UE serving the MCVideo client is switched off; and
– while the UE serving the MCVideo client is power-cycled.
NOTE: MCVideo client ID is not preserved when the UE is reset to factory settings.
4.10 Off-network MCVideo
Off-network services are available for the user if the value of "/<x>/<x>/OffNetwork/Authorised" leaf node present in the MCVideo user profile as specified in 3GPP TS 24.483 [4] is set to "true".