A.3 Interworking between TP UE and MTSI UE
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 the case of interworking between TP UE and MTSI UE.
Table A.3.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:34 b=RS:0 b=RR:4000 a=rtpmap:96 EVS/16000/1 a=fmtp:96 br=13.2-24.4; 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 100 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=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtpmap:100 H264/90000 a=fmtp:100 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=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 |
The SDP offer from TP UE in Table A.3.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).
For the basic video stream, the offer contains H.264/AVC Constrained Baseline Profile Level 1.2 (in addition to the mandatory video codec for TP UEs, namely H.264/AVC CHP Level 3.1) for the purposes of interworking with MTSI clients.
For the basic audio stream, the offer contains the mandatory EVS-SWB codec with bit rate range [13.2 to 24.4 kbps] for TP session media establishment and AMR/AMR-WB in bandwidth efficient and octet-aligned formats for enabling transcoder-free interworking with potential legacy MTSI client that does not support EVS-SWB in the TP session.
Table A.3.2: Example SDP answer for Establishment of CLUE Data Channel
SDP answer |
m=audio 49152 RTP/AVPF 96 a=acfg:1 t=1 b=AS:30 b=RS:0 b=RR:4000 a=rtpmap:96 EVS/16000/1 a=fmtp:96 br=13.2; bw=swb; max-red=220 a=ptime:20 a=maxptime:240 a=sendrecv m=video 49154 RTP/AVPF 100 a=acfg:1 t=1 b=AS:1060 b=RS:0 b=RR:5000 a=rtpmap:100 H264/90000 a=fmtp:100 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 m=video 0 RTP/AVP 99 m=video 0 RTP/AVP 99 m=video 0 RTP/AVP 99 m=application 0 UDP/DTLS/SCTP webrtc-datachannel |
The answer from MTSI UE shown in Table A.3.2. Since the MTSI UE is not CLUE capable, it does not recognize the CLUE semantic for grouping attribute nor does it support the CLUE data channel. Accordingly, the SDP answer indicates that the CLUE data channel is not accepted. Moreover, since the MTSI UE does not support multi-stream capabilities in MSMTSI clients, the additionally offered ‘sendonly’ video streams are also not accepted.
In the meantime, the MTSI UE accepts the offered basic audio and video streams that are based on RTP payloads that it supports, in this case based on EVS-SWB and H.264/AVC CHP Level 3.1. Consequently, the TP UE can fall back to the non-CLUE operation governed by MTSI client capabilities and exchange the basic media streams with the MTSI UE.
Annex B (informative):
Change history
Change history |
||||||||
---|---|---|---|---|---|---|---|---|
Date |
TSG # |
SA Doc. |
CR |
Rev |
Cat |
Subject/Comment |
Old |
New |
12-2015 |
SA#70 |
SP-150646 |
Presented to TSG SA#70 (for approval) |
1.0.0 |
||||
12-2015 |
SA#70 |
Approved at TSG SA#70 |
1.0.0 |
13.0.0 |
Change history |
|||||||
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
2016-06 |
SA#72 |
SP-160259 |
0001 |
1 |
F |
RFC 7798: RTP Payload Format for HEVC for Telepresence |
13.1.0 |
2016-06 |
SA#72 |
SP-160268 |
0002 |
1 |
B |
Introduction of Multi-Stream MTSI (MS-MTSI) Client Capability for TP UEs |
14.0.0 |
2016-09 |
SA#73 |
SP-160598 |
0005 |
1 |
B |
HEVC Screen Content Coding Extension support for IMS-based telepresence |
14.1.0 |
2016-09 |
SA#73 |
SP-160598 |
0006 |
1 |
C |
SDP Examples for MMCMH Support |
14.1.0 |
2016-09 |
SA#73 |
SP-160598 |
0007 |
– |
C |
Requirements and Recommendations based on MTSI |
14.1.0 |
2016-09 |
SA#73 |
SP-160598 |
0008 |
1 |
C |
CLUE Usage in IMS-based Telepresence |
14.1.0 |
2017-06 |
SA#76 |
SP-170322 |
0009 |
1 |
F |
Update to Screen Content Coding Reference |
14.2.0 |
2018-06 |
SA#80 |
SP-180280 |
0010 |
1 |
F |
Reference Correction |
15.0.0 |
2018-06 |
SA#80 |
SP-180278 |
0011 |
– |
B |
Video Codec Requirements for 5G Devices |
15.0.0 |
2019-03 |
SA#83 |
SP-190036 |
0012 |
– |
B |
Addition of reference to Alt_FX_EVS implementation |
16.0.0 |
2020-03 |
SA#87-e |
SP-200033 |
0013 |
1 |
F |
Alignment with MTSI on IMS Data Channel Support |
16.1.0 |
2020-09 |
SA#88-e |
SP-200660 |
0014 |
– |
D |
Update of references |
16.2.0 |
2021-04 |
SA#91-e |
SP-210036 |
0015 |
2 |
A |
Updates on IETF References |
16.3.0 |
2021-06 |
SA#92-e |
SP-210536 |
0022 |
A |
IETF Reference Update |
16.4.0 |
|
2022-04 |
– |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |
2022-06 |
SA#96 |
SP-220599 |
0023 |
ITT4RT feature |
17.1.0 |
||
2022-09 |
SA#97-e |
SP-220764 |
0024 |
2 |
F |
Protocol Stack for Telepresence UE |
18.0.0 |