A.1 TP Session Setup with CLUE-Controlled Video Support
26.2233GPPMedia handling and interactionRelease 18Telepresence using the IP Multimedia Subsystem (IMS)TS
The following example demonstrates the SDP offer for negotiation of a CLUE data channel – the assumption here is that TP UE1 has three cameras and three screens and TP UE2 has two cameras and two screens.
Table A.1.1: Example SDP offer for Establishment of CLUE Data Channel
|
SDP offer |
|
a=group CLUE 3 m=audio 49152 RTP/AVP 96 97 98 99 100 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:89 b=RS:0 b=RR:4000 a=rtpmap:96 EVS/16000/1 a=fmtp:96 br=13.2-64; bw=swb; max-red=220 a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-change-capability=2; max-red=220 a=rtpmap:100 AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1 a=ptime:20 a=maxptime:240 a=sendrecv a=mid:1 m=video 49154 RTP/AVP 99 100 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendrecv a=mid:2 m=video 49156 RTP/AVP 99 100 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:4 m=video 49158 RTP/AVP 99 100 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:5 m=video 49160 RTP/AVP 99 100 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:6 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:3 |
In the above SDP example and remaining SDP examples below, boldface font is used to highlight the key lines demonstrating the described SDP offer answer procedures in the context of TP sessions controlled by CLUE.
The SDP offer from TP UE1 in Table A.1.1 contains basic media streams (non-CLUE controlled) and an establishment request for a DTLS/SCTP association used to realize a CLUE data channel. A CLUE group is included and the data channel is shown in group (3). Since the TP UE intends to negotiate multiple streams for video, the SDP offer contains all of them in the basic (i.e., non-CLUE controlled) stream offered with the multi-stream capabilities for MSMTSI clients, as outlined in clause 6, as this helps to fall back to MSMTSI in case the remote client is not a TP UE and CLUE negotiation is not successful. Moreover, it should be observed that the multiple streams for video other than the basic streams offered for MSMTSI clients are labelled as ‘sendonly’ and are also not part of the CLUE group. Only the offered CLUE data channel is included in the CLUE group (identified by a=mid:3).
The initial SDP offer message negotiates the port and transport information for setting up the DTLS/SCTP association, via a separate SDP "m=" line with a UDP/DTLS/SCTP or TCP/DTLS/SCTP proto value, together with an SDP "sctp-port" attribute, and an SDP "dcmap" attribute to indicate "CLUE" as the application protocol running over the data channel. The procedures for establishment of the DTLS/SCTP association via SDP can be found in [13] and [8].
For the basic media streams, the offer contains the AMR narrowband and AMR-WB wideband codecs for audio and H.264/AVC Constrained Baseline Profile Level 1.2 (in addition to the mandatory codecs for TP UEs, namely EVS-SWB and H.264/AVC CHP Level 3.1).
Table A.1.2: Example SDP answer for Establishment of CLUE Data Channel
|
SDP answer |
|
a=group CLUE 100 m=audio 49152 RTP/AVPF 96 a=acfg:1 t=1 b=AS:89 b=RS:0 b=RR:4000 a=rtpmap:96 EVS/16000/1 a=fmtp:96 br=13.2-64; bw=swb; max-red=220 a=ptime:20 a=maxptime:240 a=sendrecv a=mid:9 m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendrecv a=mid:10 m=video 49156 RTP/AVPF 99 a=acfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=recvonly a=mid:11 m=video 49158 RTP/AVPF 99 a=acfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=recvonly a=mid:12 m=video 0 RTP/AVP 99 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:100 |
The answer from TP UE2 in Table A.1.2 indicates that the CLUE data channel is accepted. Now CLUE and configure messages can be exchanged in order to negotiate on the capture and rendering capabilities for the telepresence session. Moreover, TP UE2 wishes to receive initial media, and so includes corresponding non-CLUE-controlled audio and video lines.
With the successful initial SDP offer-answer, TP UEs negotiate the CLUE channel via the exchange of CLUE ADVERTISEMENT and CLUE CONFIGURE messages. As described in clause 6, the CLUE protocol messages follow the XML format in [10] and various CLUE message examples can also be found in [11]. TP UE1 advertises three static Captures representing its three cameras. It also includes switched Captures suitable for two- and one-screen systems. TP UE1 also includes an Encoding Group with three Encoding IDs: "enc1", "enc2" and "enc3", which will appear in the subsequent SDP offer TP UE1 intends to send. TP UE2 also sends its CLUE ADVERTISEMENT message, where it advertises two static Captures representing its two cameras. It also includes a single composed Capture for single-screen systems, in which it will composite the two camera views into a single video stream. TP UE2 also includes a single Encoding Group with two Encoding IDs: "foo" and "bar".
Following the exchange of these CLUE messages, further SDP offer-answer negotiations can occur that include CLUE-controlled encodings. Every "m" line representing a CLUE Encoding contains a "label" attribute as defined in [48] to identify the Encoding by the sender in CLUE Advertisement messages and by the receiver in CLUE Configure messages, e.g. "enc1", "enc2", "enc3" for TP UE1 and "foo" and "bar" for TP UE2.
It should be noted that, since the CLUE negotiation was successful, the subsequent SDP offers are made such that for each media type the additional streams other than the basic stream are offered as CLUE-controlled streams and MSMTSI client capabilities are no longer to be offered. As a result, several of the earlier accepted ‘sendonly’ video streams are now offered as part of the CLUE-controlled group in the SDP offer example below.
Table A.1.3: Example SDP offer for Negotiating CLUE-controlled Media
|
SDP offer |
|
a=group CLUE 3 4 5 6 m=audio 49152 RTP/AVPF 96 b=AS:89 b=RS:0 b=RR:4000 a=rtpmap:96 EVS/16000/1 a=fmtp:96 br=13.2-64; bw=swb; max-red=220 a=ptime:20 a=maxptime:240 a=sendrecv a=mid:1 m=video 49154 RTP/AVPF 99 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendrecv a=mid:2 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:3 m=video 49156 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:4 a=label:enc1 m=video 49158 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:5 a=label:enc2 m=video 49160 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:6 a=label:enc3 |
The second SDP offer in Table A.1.3 from TP UE1 maintains the "sendrecv" audio, video and includes three additional "sendonly" m-lines representing the three CLUE-controlled encodings for video. Each of these m-lines contains a "label" corresponding to one of the encoding IDs from the CLUE advertisement from TP UE1. Each also has its "mid" added to the grouping attribute to show that they are controlled by the CLUE channel.
Since it is now clear that the remote endpoint is a CLUE-capable TP UE, the offer for the basic streams contains the mandatory audio and video codecs for TP UEs, namely the EVS codec as well as the H.264/AVC Constrained High Profile Level 3.1.
TP UE2 now has all the information he needs to decide which streams to configure. As such he now sends its CLUE CONFIGURE message. This requests the pair of switched Captures that represent TP UE1’s scene, and it configures them with encoder ids "enc1" and "enc2".
TP UE1 receives the CLUE CONFIGURE from TP UE2 and sends a CLUE RESPONSE message to acknowledge its receptions.
Table A.1.4: Example SDP answer for Negotiating CLUE-controlled Media
|
SDP answer |
|
a=group CLUE 11 12 100 m=audio 49152 RTP/AVPF 96 b=AS:89 b=RS:0 b=RR:4000 a=rtpmap:96 EVS/16000/1 a=fmtp:96 br=13.2-64; bw=swb; max-red=220 a=ptime:20 a=maxptime:240 a=sendrecv a=mid:9 m=video 49154 RTP/AVPF 99 b=AS:1060 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendrecv a=mid:10 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:100 m=video 49156 RTP/AVPF 99 a=acfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=recvonly a=mid:11 m=video 49158 RTP/AVPF 99 a=acfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=recvonly a=mid:12 m=video 0 RTP/AVP 99 |
TP UE2 now sends its SDP answer, shown in Table 4. Alongside the original audio, video and CLUE m-lines, it includes two active "recvonly" m-lines and a zeroed m-line for the third, indicating that only two of the offered CLUE-controlled encodings are accepted. It adds their "mid" values to the grouping attribute to show they are controlled by the CLUE channel.
The constraints of offer/answer meant that TP UE2 could not include its encoder information as new m-lines in the SDP answer. As such TP UE2 now generates a third SDP offer. Along with all the accepted streams from the second offer-answer exchange, TP UE2 also includes two new "sendonly" streams. Each stream has a "label" corresponding to the Encoding IDs in the CLUE ADVERTISEMENT message from TP UE2. It also adds their "mid" values to the grouping attribute to show they are controlled by the CLUE channel. The resulting SDP offer is shown in Table A.1.5.
Table A.1.5: Example SDP offer for Negotiating CLUE-controlled Media
|
SDP offer |
|
a=group CLUE 11 12 13 14 100 m=audio 49152 RTP/AVPF 96 b=AS:89 b=RS:0 b=RR:4000 a=rtpmap:96 EVS/16000/1 a=fmtp:96 br=13.2-64; bw=swb; max-red=220 a=ptime:20 a=maxptime:240 a=sendrecv a=mid:9 m=video 49154 RTP/AVPF 99 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendrecv a=mid:10 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:100 m=video 49156 RTP/AVPF 99 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=recvonly a=mid:11 m=video 49158 RTP/AVPF 99 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=recvonly a=mid:12 m=video 0 RTP/AVP 99 m=video 49160 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:13 a=label:foo m=video 49162 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:14 a=label:bar |
Having received this TP UE1 now has all the information it needs to send a new CLUE CONFIGURE message. It requests the two static Captures from TP UE2, to be sent on Encodings "foo" and "bar". TP UE2 receives the CLUE CONFIGURE message from TP UE1 and sends a CLUE RESPONSE message to acknowledge its receptions.
TP UE1 now sends an SDP answer matching two "recvonly" m-lines to TP UE2’s new "sendonly" lines. It includes their "mid" values in the grouping attribute to show they are controlled by the CLUE channel. This is shown in Table A.1.6.
Table A.1.6: Example SDP answer for Negotiating CLUE-controlled Media
|
SDP answer |
|
a=group CLUE 3 4 5 6 7 8 m=audio 49152 RTP/AVPF 96 b=AS:89 b=RS:0 b=RR:4000 a=rtpmap:96 EVS/16000/1 a=fmtp:96 br=13.2-64; bw=swb; max-red=220 a=ptime:20 a=maxptime:240 a=sendrecv a=mid:1 m=video 49154 RTP/AVPF 99 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendrecv a=mid:2 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:3 m=video 49156 RTP/AVPF 99 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:4 a=label:enc1 m=video 49158 RTP/AVPF 99 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=sendonly a=mid:5 a=label:enc2 m=video 0 RTP/AVPF 99 m=video 49160 RTP/AVPF 99 a=acfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=recvonly a=mid:7 m=video 49162 RTP/AVPF 99 a=acfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=640c1f; \ sprop-parameter-sets=Z2QMH5WgFAFugH9Q,aM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=recvonly a=mid:8 |
Both sides of the call are now sending multiple video streams with their sources defined via CLUE negotiation. As the call progresses either side can send new CLUE Advertisement or Configure message or new SDP negotiation to add, remove or change what they have available or want to receive.