Content for  TS 23.333  Word version:  18.1.0

The MRFC and the MRFP may support the video Region-of-Interest (ROI) as defined in TS 26.114. Three modes are specified for supporting ROI, including "Far End Camera Control (FECC)", "Arbitrary ROI" and "Predefined ROI". The MRFC and the MRFP may independently support any of these modes. For the forthcoming clauses on "Far End Camera Control (FECC)", "Arbitrary ROI" and "Predefined ROI", the MRF procedures allow for only a single ROI-sending client in a given conference to receive and act on ROI requests for a given ROI mode, but they allow for multiple ROI-receiving clients to issue and send ROI requests. Once the MRFC successfully completes the ROI capability negotiation with the ROI-sending client, it offers the corresponding ROI capabilities to other ROI-receiving clients in the conference and instructs the MRFP to signal ROI request(s) to the ROI-sending client based on the ROI requests it receives from the ROI-receiving clients.

The MRFC and MRFP may support the "Far End Camera Control" mode as specified in TS 26.114. If the MRFC and MRFP support the "Far End Camera Control" mode, the MRFC and MRFP shall apply the procedures in the present clause. Upon receipt of an SDP offer containing an "m=" line with a media type "application/h224", as defined by RFC 4573 which indicates support for FECC (ITU-T Recommendation H.281 [56]) using ITU-T Recommendation H.224 [55], the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "FECC" offer. If the "FECC" offer is accepted, the MRFC shall:

• include the "m=" and "a=" lines related to the "application/h224" media types (see the related SDP examples in Annex A.4.2e of TS 26.114) in the SDP answer that will be sent within the SIP signalling;
• request the MRFP to provide a separate IP/UDP/RTP transport for the "application/h224" media stream by setting the "m=" line media type to "application" and "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol when reserving the transport resources, and forward transparently RTP/UDP packets (with the transparent (H.224)-PDU); and
• only one of the SDP offers containing "a=sendrecv" or "a=recvonly" capabilities shall be responded by the MRFC with an SDP answer with an indication of "a=sendonly" and other such SDP offers, if accepted, shall be responded by the MRFC with an SDP answer with an indication of "a=recvonly".
• request the MRFP to pass RTP flows from the terminations where the MRFC replied with "a=recvonly" in the SDP answer to the termination where the MRFC replied with "a=sendonly" in the SDP answer.

If the MRFP does not support the FECC feature or the MRFC determines that the "FECC" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any "m=" and "a=" lines related to the "application/h224" media types within the SIP signalling. If the MRFC and MRFP support the FECC feature then before sending an SDP offer, the MRFC shall:

1. determine based on the local policy and the FECC negotiation results on other call legs to offer FECC; and
2. if the MRFC determines to offer FECC:
   • the MRFC shall include the "m=" and "a=" lines related to the "application/h224" media types in the SDP offer it sends within the SIP signalling; and
   • request the MRFP to provide a separate IP/UDP/RTP transport for the "application/h224" media stream by setting the "m=" line media type to "application" and "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol when reserving the transport resources, and forward transparently RTP/UDP packets (with the transparent (H.224)-PDU)
   • only one of the SDP offers from the MRFC shall contain "a=sendonly" and remaining SDP offers from the MRFC shall contain "a=recvonly".
   • request the MRFP to pass RTP flows from the terminations where the MRFC indicated with "a=recvonly" in the SDP offer to the termination where the MRFC indicated with "a=sendonly" in the SDP offer.

If the MRFP does not support the FECC feature, the MRFC shall send the SDP offer without any FECC related SDP attributes within the SIP signalling.

The MRFC and MRFP may support the "Predefined ROI" mode as specified in TS 26.114. If the MRFC and MRFP support the "Predefined ROI", the MRFC and MRFP shall apply the procedures in the present clause. Upon receipt of an SDP offer containing the predefined ROI attribute(s) "a=predefined_ROI" defined in TS 26.114, the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Predefined ROI" offer. If the "Predefined ROI" offer is accepted, the MRFC shall include the accepted set of predefined ROIs in the SDP answer by indicating them using the "a=predefined_ROI" attributes that will be sent within the SIP signalling (see the related SDP examples in Annex A.4.2e of TS 26.114). The accepted set of predefined ROIs shall be based on the predefined ROIs offered by the client designated by the MRFC as the ROI-sending client. For the response to the ROI-sending client, the SDP answer from the MRFC shall not contain "a=predefined_ROI" attributes. If the MRFP does not support the Predefined ROI feature or the MRFC determines that the "Predefined ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any "a=predefined_ROI" attributes within the SIP signalling. Upon receipt of an SDP offer containing an "a=rtcp-fb" line with the "Predefined ROI" type expressed by the parameter "3gpp-roi-predefined", as described in TS 26.114, the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Predefined ROI" offer. If the "Predefined ROI" offer is accepted, the MRFC shall:

• at the termination towards the ROI-sending client, include the "Predefined ROI Sent" information element when seizing resources in the MRFP to indicate to the MRFP that it shall signal RTCP "FB ROI" feedback message(s) related to predefined ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey pre-defined ROI information;
• at a termination towards an ROI-receiving client, include the "Predefined ROI Received" information element when seizing resources in the MRFP to indicate to the MRFP that it shall accept RTCP "FB ROI" feedback message(s) related to predefined ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey pre-defined ROI information; and
• include "a=rtcp-fb" lines related to the "3gpp-roi-predefined" parameter in the SDP answer that will be sent within the SIP signalling (see the related SDP examples in Annex A.4.2e of TS 26.114); and

If the MRFP does not support the Predefined ROI feature or the MRFC determines that the "Predefined ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any "a=rtcp-fb" lines related to the "3gpp-roi-predefined" parameter within the SIP signalling. Upon receipt of an SDP offer containing "a=extmap" attribute(s), as defined in RFC 5285, and the "a=extmap" attribute(s) contain the pre-defined ROI URN(s) (i.e. the ROI URN for carriage of pre-defined region of interest information in the sent video stream is given by "urn:3gpp:predefined-roi-sent") as defined in TS 26.114, then the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Predefined ROI" offer. If the "Predefined ROI" offer is accepted, the MRFC shall:

• include the "Extended RTP header for Sent ROI" information element when seizing resources in the MRFP to indicate to the MRFP that it shall allow the RTP header extension for predefined ROI to pass; and
• include "a=extmap" attributes containing the pre-defined ROI URN in the SDP answer that will be sent within the SIP signalling (see the related SDP examples in Annex A.4.2e of TS 26.114).

If the MRFP does not support the Predefined ROI feature or the MRFC determines that the "Predefined ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any Predefined ROI related "a=extmap" attribute within the SIP signalling. If the MRFC and MRFP support the Predefined ROI feature then before sending an SDP offer, the MRFC shall:

1. determine based on the local policy and the Predefined ROI negotiation results on other call legs if, and with what configurations to offer Predefined ROI; and
2. if the MRFC determines to offer Predefined ROI:
   • at the termination towards the ROI sending client, the MRFC shall include the "Predefined ROI Sent" information element when seizing resources in the MRFP to indicate to the MRFP that it shall signal RTCP "FB ROI" feedback message(s) related to predefined ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey pre-defined ROI information;
   • at a termination towards an ROI receiving client, the MRFC shall include the "Predefined ROI Received" information element when seizing resources in the MRFP to indicate to the MRFP that it shall accept RTCP "FB ROI" feedback message(s) related to predefined ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey pre-defined ROI information;
   • the MRFC shall include "a=rtcp-fb" lines related to the "3gpp-roi-predefined" parameter along with the associated "a=predefined_ROI" attributes in the SDP offer it sends within the SIP signalling;
   • the MRFC shall include the offered set of predefined ROIs by indicating them using the "a=predefined_ROI" attributes in the SDP offer it sends within the SIP signalling, where the offered set of predefined ROIs shall be based on the predefined ROIs offered by the client designated by the MRFC as the ROI-sending client.;
   • the MRFC shall include the "extended RTP header for Sent ROI" information element for Predefined ROI when seizing resources in the MRFP to indicate the MRFP that it shall allow the RTP header extension for predefined ROI to pass; and
   • the MRFC shall include the Predefined ROI related "a=extmap" attribute in the SDP offer it sends within the SIP signalling.

If the MRFP does not support the Predefined ROI feature, the MRFC shall send the SDP offer without any Predefined ROI related SDP attributes within the SIP signalling. If the MRFP has been instructed to pass on the extended RTP header for predefined ROI as described above then:

• if the MRFP does not apply video transcoding, it shall pass any received RTP header extension for Predefined ROI to succeeding RTP streams; or
• if the MRFP applies video transcoding, it shall keep the predefined ROI information unchanged during the transcoding and copy the received RTP header extension for Predefined ROI to the succeeding outgoing RTP stream(s) after transcoding the associated group of packets.

The MRFC and MRFP may support the "Arbitrary ROI" mode as specified in TS 26.114. If the MRFC and MRFP support the "Arbitrary ROI", the MRFC and MRFP shall apply the procedures in the present clause. Upon receipt of an SDP offer containing an "a=rtcp-fb" line with the " Arbitrary ROI" type expressed by the parameter "3gpp-roi-arbitrary", as described in TS 26.114, the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Arbitrary ROI" offer. If the "Arbitrary ROI" offer is accepted, the MRFC shall:

• at the termination towards the ROI-sending client, include the "Arbitrary ROI Sent" information element when seizing resources in the MRFP to indicate to the MRFP that it shall signal RTCP "FB ROI" feedback message(s) related to arbitrary ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey arbitrary ROI information;
• at a termination towards an ROI-receiving client, include the "Arbitrary ROI Received" information element when seizing resources in the MRFP to indicate to the MRFP that it shall accept RTCP "FB ROI" feedback message(s) related to arbitrary ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey arbitrary ROI information; and
• include "a=rtcp-fb" lines related to the "3gpp-roi-arbitrary" parameter in the SDP answer that will be sent within the SIP signalling (see the related SDP examples in Annex A.4.2e of TS 26.114).

If the MRFP does not support the Arbitrary ROI feature or the MRFC determines that the "Arbitrary ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any "a=rtcp-fb" lines related to the "3gpp-roi-arbitrary" parameter within the SIP signalling. Upon receipt of an SDP offer containing "a=extmap" attribute(s), as defined in RFC 5285, and the "a=extmap" attribute(s) contain the arbitrary ROI URN(s) (i.e. the ROI URN for carriage of arbitrary region of interest information in the sent video stream is given by "urn:3gpp:roi-sent") as defined in TS 26.114, then the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Arbitrary ROI" offer. If the "Arbitrary ROI" offer is accepted, the MRFC shall:

• include the "Extended RTP header for Sent ROI" information element when seizing resources in the MRFP to indicate to the MRFP that it shall allow the RTP header extension for arbitrary ROI to pass; and
• include "a=extmap" attributes containing the arbitrary ROI URN in the SDP answer that will be sent within the SIP signalling (see the related SDP examples in Annex A.4.2e of TS 26.114).

If the MRFP does not support the Arbitrary ROI feature or the MRFC determines that the "Arbitrary ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any Arbitrary ROI related "a=extmap" attribute within the SIP signalling. If the MRFC and MRFP support the Arbitrary ROI feature then before sending an SDP offer, the MRFC shall:

1. determine based on the local policy and the Arbitrary ROI negotiation results on other call legs if, and with what configurations to offer Arbitrary ROI; and
2. if the MRFC determines to offer Arbitrary ROI:
   • at the termination towards the ROI-sending client, the MRFC shall include the "Arbitrary ROI Sent" information element when seizing resources in the MRFP to indicate to the MRFP that it shall signal RTCP "FB ROI" feedback message(s) related to arbitrary ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey arbitrary ROI information;
   • at a termination towards an ROI-receiving client, the MRFC shall include the "Arbitrary ROI Received" information element when seizing resources in the MRFP to indicate to the MRFP that it shall accept RTCP "FB ROI" feedback message(s) related to arbitrary ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey arbitrary ROI information;
   • the MRFC shall include "a=rtcp-fb" lines related to the "3gpp-roi-arbitrary" parameter in the SDP offer it sends within the SIP signalling;
   • the MRFC shall include the "extended RTP header for Sent ROI" information element for Arbitrary ROI when seizing resources in the MRFP to indicate the MRFP that it shall allow the RTP header extension for arbitrary ROI to pass; and
   • the MRFC shall include the Arbitrary ROI related "a=extmap" attribute in the SDP offer it sends within the SIP signalling.

If the MRFP does not support the Arbitrary ROI feature, the MRFC shall send the SDP offer without any Arbitrary ROI related SDP attributes within the SIP signalling. If the MRFP has been instructed to pass on the extended RTP header for arbitrary ROI as described above then:

• if the MRFP does not apply video transcoding, it shall pass any received RTP header extension for Arbitrary ROI to succeeding RTP streams; or
• if the MRFP applies video transcoding, it shall keep the arbitrary ROI information unchanged during the transcoding and copy the received RTP header extension for Arbitrary ROI to the succeeding outgoing RTP stream(s) after transcoding the associated group of packets.