A.2 TP Session Setup with CLUE-Controlled Audio Support

26.2233GPPMedia handling and interactionRelease 18Telepresence using the IP Multimedia Subsystem (IMS)TS

The following example is similar to the example in clause A.1, but demonstrates CLUE-controlled audio support channel – the assumption here is that TP UE1 has three microphones and three speakers and TP UE2 has two microphones and two speakers. No video communication is assumed in this example.

Table A.2.1: Example SDP offer for Establishment of CLUE Data Channel

SDP offer

a=group CLUE 3 m=audio 49150 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=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=sendonly a=mid:4 m=audio 49154 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=sendonly a=mid:5 m=audio 49156 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=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

The SDP offer from TP UE1 in Table A.2.1 contains the basic audio stream (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).

For the basic media streams, the offer contains the AMR narrowband, AMR-WB wideband and EVS codecs, with the former two included for the purposes of interworking with MTSI clients.

Since the TP UE intends to negotiate multiple streams for audio, 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 audio 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).

Table A.2.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=audio 49154 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=recvonly a=mid:10 m=audio 49156 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=recvonly a=mid:11 m=audio 0 RTP/AVP 96 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.2.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 lines, accepting the use of the EVS codec.

With the successful initial SDP offer-answer, TP UEs negotiate the CLUE channel via the exchange of CLUE ADVERTISEMENT and CLUE CONFIGURE messages. TP UE1 advertises three static Captures representing its three microphones. It also includes switched Captures suitable for two- and one-speaker 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 microphones. It also includes a single composed Capture for single-speaker systems, in which it will composite the two microphone views into a single audio 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’ audio streams are now offered as part of the CLUE-controlled group in the SDP offer example below.

Table A.2.3: Example SDP offer for Negotiating CLUE-controlled Media

SDP offer

a=group CLUE 3 4 5 6 m=audio 49150 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=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:3 m=audio 49152 RTP/AVP 96 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=ptime:20 a=maxptime:240 a=sendonly a=mid:4 a=label:enc1 m=audio 49154 RTP/AVP 96 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=ptime:20 a=maxptime:240 a=sendonly a=mid:5 a=label:enc2 m=audio 49156 RTP/AVP 96 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=ptime:20 a=maxptime:240 a=sendonly a=mid:6 a=label:enc3

The second SDP offer in Table A.2.3 from TP UE1 maintains the "sendrecv" audio and includes three additional "sendonly" m-lines representing the three CLUE-controlled encodings for audio. 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.

TP UE2 now has all the information it needs to decide which streams to configure. As such it now sends its CLUE CONFIGURE message. This requests the pair of switched Captures, 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.2.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=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:100 m=audio 49154 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=recvonly a=mid:11 m=audio 49156 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=recvonly a=mid:12 m=audio 0 RTP/AVP 96

TP UE2 now sends its SDP answer, shown in Table A.2.4. Alongside the original audio 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.2.5.

Table A.2.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=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:100 m=audio 49154 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=recvonly a=mid:11 m=audio 49156 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=recvonly a=mid:12 m=audio 0 RTP/AVP 96 m=audio 49158 RTP/AVP 96 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=ptime:20 a=maxptime:240 a=sendonly a=mid:13 a=label:foo m=audio 49160 RTP/AVP 96 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=ptime:20 a=maxptime:240 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.2.6.

Table A.2.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=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE"; ordered=true a=mid:3 m=audio 49154 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=sendonly a=mid:4 a=label:enc1 m=audio 49156 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=sendonly a=mid:5 a=label:enc2 m=audio 0 RTP/AVP 96 m=audio 49158 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=recvonly a=mid:7 m=audio 49160 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=recvonly a=mid:8

Both sides of the call are now sending multiple audio 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.