The media configuration requirements for MTSI clients in terminals specified in clause 6 of TS 26.114, also apply for TP UEs. To enable devices to participate in an IMS-based telepresence call, selecting the sources they wish to view, receiving those media sources and displaying them in an optimal fashion, CLUE involves two principal and inter-related protocol negotiations. SDP, conveyed via SIP, is used to negotiate the specific media capabilities that can be delivered to specific addresses on the TP UE. Meanwhile, a CLUE protocol (RFC 8847), transported via a CLUE data channel (RFC 8850), is used to negotiate the Capture Sources available, their attributes and any constraints in their use, along with which Captures the far end provides a TP UE wishes to receive. The CLUE protocol messages follow the XML format and comply with the XML schema in (RFC 8846). The CLUE data channel (RFC 8850) is a bidirectional SCTP over DTLS channel used for the transport of CLUE messages. This channel shall be established before CLUE protocol messages can be exchanged and CLUE-controlled media can be sent. Beyond negotiating the CLUE channel, SDP is also used to negotiate the details of supported media streams and the maximum capability of each of those streams. As the CLUE Framework (RFC 8845) defines a manner in which the Media Provider expresses their maximum encoding capabilities, SDP is also used to express the encoding limits for each potential Encoding. Backwards-compatibility with MTSI is an important consideration and it is vital that a CLUE-capable TP UE contacting a terminal that does not support CLUE is able to fall back to a fully functional non-CLUE call governed by the requirements on MTSI in TS 26.114. CLUE support shall be offered in the first SDP offer, as follows. At the beginning of a CLUE-based telepresence session over IMS, the support for CLUE shall be negotiated via the SDP between two TP UEs. The CLUE extension shall be indicated using an SDP session-level 'group' attribute. Each SDP media "m" line that is included in this group, using SDP media-level "mid" attributes, is CLUE-controlled, by a CLUE data channel also included in this CLUE group. A CLUE group should include the "mid" of the "m" line for one (and only one) CLUE data channel. For interoperability with non-CLUE devices, a CLUE-capable device sending an initial SDP offer shall not include any "m" line for CLUE-controlled media beyond the "m" line for the CLUE data channel (this is unless the remote terminal's CLUE support was already indicated at the SIP level using the "sip.clue" media feature tag), and includes at least one non-CLUE-controlled media "m" line. For audio and video, the first SDP offer shall also contain the basic (i.e. non-CLUE-controlled) media streams with the set of mandatory codecs for TP UEs, i.e. namely EVS-SWB and H.264/AVC CHP Level 3.1. For each of the offered basic (i.e. non-CLUE-controlled) media streams indicated in an 'm=' line, one mandatory codec of the same media type that is specified in TS 26.114 shall also be included toward ensuring interworking with MTSI terminals. The preference in the codec order should favour the mandatory codecs for TP UEs, i.e. namely EVS-SWB and H.264/AVC CHP Level 3.1. If the TP UE intends to negotiate multiple streams for audio and/or video, the first SDP offer from the TP UE should contain all of them in the basic (i.e., non-CLUE controlled) stream offered with the multi-stream capabilities for MSMTSI clients as specified in Annex S of TS 26.114 and demonstrated by the SDP examples in Annex T of TS 26.114 towards realizing more efficient group audio/video communications and avoiding transcoding as far as possible in multiparty calls. If the CLUE negotiation is successful however, the subsequent SDP offers shall be made such that for each media type the additional streams other than the basic stream shall be offered as CLUE-controlled streams and MSMTSI client capabilities shall no longer be offered. If the CLUE negotiation is successful and the remote terminal is also a CLUE-capable TP UE, then the subsequent offers for all media streams, including basic streams and CLUE-controlled media, shall contain the mandatory codecs for TP UEs, namely EVS-SWB and H.264/AVC CHP Level 3.1, and shall contain at least one RTP payload type of the corresponding codec for each media line. Accordingly, the SDP answers from TP UEs shall also accept these codecs and contain the corresponding RTP payload types, and also shall conform to the requirements established in Tables 6.3a and 6.3b of TS 26.114. A TP UE receiving an SDP offer from an MTSI UE or a non-3GPP access client that does not support CLUE capabilities shall fall back to operate as an MTSI client and answer the SDP offer as per the requirements established in TS 26.114. If the received SDP offer does not support CLUE, but contains multi-stream capabilities for MSMTSI clients as specified in Annex S of TS 26.114 and demonstrated by the SDP examples in Annex T of TS 26.114, then the TP UE shall accept such an offer and fall back to operate as an MSMTSI client. TP UEs may be involved in media sessions where CLUE could be enabled or disabled during an ongoing call. If, in an ongoing non-CLUE call, an SDP offer/answer exchange completes with both sides having included a data channel "m" line in their SDP and with the "mid" for that channel in corresponding CLUE groups then the call is now CLUE-enabled; negotiation of the data channel and subsequently the CLUE protocol begin. If, in an ongoing CLUE-enabled call, an SDP offer-answer negotiation completes in a fashion in which either the CLUE data channel was not successfully negotiated or one side did not include the data channel in a matching CLUE group then CLUE for this channel is disabled. In the event that this occurs, CLUE is no longer enabled and sending of all CLUE-controlled media associated with the corresponding CLUE group shall stop. A TP UE offering a media session should generate an SDP offer according to the examples in Annex A.