T.2 MSMTSI video offer/answer examples
26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS
T.2.1 MSMTSI offer/answer towards an MTSI client
This offer includes sending two different simulcast streams for the main video, receiving two thumbnail videos, both sending and receiving screenshare video, and has support for BFCP to control screenshare and (possibly) main video, which are all features that can be supported by MSMTSI but that are not supported by a regular MTSI client. All audio is omitted in this example, for brevity, but could be added according to the other examples (e.g., in Clause T.3) in this annex.
Video levels are in this example aligned with the maximum size of the video stream, and the maximum receive bandwidth limit is set by the "b="-line rather than just implicitly by the video level bandwidth limit.
The main video is listed as the first video "m="-line and is also explicitly identified through "a=content:main".
One subsequent "m="-line is explicitly identified as screenshare video, using "a=content:slides".
The rest of the video "m="-lines indicate support for two additional, receive-only video thumbnails.
All video "m="-lines offer support for RTP level pause/resume, indicated through "a=rtcp-fb:* ccm pause". The "nowait" parameter is set, indicating that the MSMTSI client expects the RTP media streams to be sent point-to-point on RTP level. That can for example be either between MSMTSI clients in terminal, or between an MSMTSI client in terminal and an MSMTSI MRF. In either case, the "nowait" parameter indicates it is not expected that multiple receivers of the RTP streams are able to send RTCP back to request RTP level pause/resume.
Support for reduced-size RTCP (see clause 7.3.6 and [87]) is offered for all video "m="-lines, to save bandwidth for RTCP feedback messages listed on "a=rtcp-fb"-lines.
BFCP support is offered with client role.
Blank lines are here added in the SDP for improved readability, but are not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
Table T.1: Example SDP offer from MSMTSI towards MTSI
|
SDP offer |
|
m=video 49154 RTP/AVPF 101 102 b=AS:1060 b=RS:0 b=RR:2500 a=rtpmap:101 H264/90000 a=rtpmap:102 H264/90000 a=fmtp:101 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=fmtp:102 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240] a=imageattr:102 send [x=176,y=144] [x=224,y=176] [x=320,y=180] \ recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6] a=rid:0 send pt=101 a=rid:1 send pt=102 a=rid:2 recv pt=101 a=simulcast:send 0;1 recv 2 a=content:main a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=video 49156 RTP/AVPF 103 b=AS:800 b=RS:0 b=RR:2500 a=rtpmap:103 H264/90000 a=fmtp:103 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=imageattr:103 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] a=content:slides a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=video 49158 RTP/AVPF 104 b=AS:240 b=RS:0 b=RR:2500 a=rtpmap:104 H264/90000 a=fmtp:104 packetization-mode=0; profile-level-id=42e00c a=imageattr:104 recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6] a=recvonly a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=video 49160 RTP/AVPF 105 b=AS:240 b=RS:0 b=RR:2500 a=rtpmap:105 H264/90000 a=fmtp:105 packetization-mode=0; profile-level-id=42e00c a=imageattr:105 recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6] a=recvonly a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=application 50324 TCP/BFCP * a=floorctrl:c-only a=setup:actpass a=connection:new |
Table T.2: Example SDP answer from MTSI towards MSMTSI
|
SDP answer |
|
m=video 49154 RTP/AVPF 101 b=AS:450 b=RS:0 b=RR:2500 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=0; profile-level-id=42e00d; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; a=imageattr:101 send [x=320,y=240] recv [x=320,y=240] 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=extmap:4 urn:3gpp:video-orientation m=video 0 RTP/AVPF 103 m=video 0 RTP/AVPF 104 m=video 0 RTP/AVPF 105 m=application 0 TCP/BFCP * |
The answerer, being an MTSI client, knows of no MSMTSI features, but has correctly disabled all of them in the SDP answer, according to generic SDP offer/answer rules, keeping unsupported "m="-lines with port set to zero, leaving the session effectively identical to a regular MTSI session with a single video and mono audio.
T.2.2 MSMTSI answer from an MSMTSI MRF
This example assumes the same offer as in Table T.1, which is thus not repeated here, but the answerer is here an MSMTSI MRF, supporting all of the offered MSMTSI-specific features. All audio is omitted in this example, for brevity, but could be added according to any of the other examples in this annex.
Note that the "isFocus" tag, identifying this answer as an MRF, is included as part of SIP headers and is thus not visible in the SDP in this example.
The MSMTSI MRF accepts to receive the two offered simulcast streams for the main video. Then, the MSMTSI MRF can send video for the two supported thumbnails, and can also control both main video and screenshare video through BFCP.
It can be noted that the MSMTSI MRF needs to keep all payload type formats that it accepts to use for simulcast on the "m="-line in the answer.
The MSMTSI MRF is, by including the RTP-level "nowait" parameter on the "a=rtcp-fb:* ccm pause" line in the SDP answer, confirming that exchange of RTP level pause/resume messages will be point-to-point and no hold-off period will therefore be necessary when resuming paused streams (see [156]).
Support for reduced-size RTCP (see clause 7.3.6 and [87]) is accepted for all video "m="-lines, to save bandwidth for RTCP feedback messages listed on "a=rtcp-fb"-lines.
The "a=label" lines are added by the MSMTSI MRF to support identification of BFCP-controlled "m="-lines, relating BFCP floor identifications to "m="-lines through "a=floorid" lines under the BFCP "m="-line. In this example, both the main video and the screenshare video "m="-lines are floor controlled. The thumbnail videos are however not floor controlled, so there are no "a=label" lines for those "m="-lines.
Blank lines are here added in the SDP for improved readability, but are not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
Table T.3: Example SDP answer from MSMTSI MRF towards MSMTSI
|
SDP answer |
|
m=video 49154 RTP/AVPF 101 102 b=AS:1300 b=RS:0 b=RR:2500 a=rtpmap:101 H264/90000 a=rtpmap:102 H264/90000 a=fmtp:101 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=fmtp:102 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240] a=imageattr:102 send [x=176,y=144] [x=224,y=176] [x=320,y=180] \ recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6] a=rid:0 recv pt=101 a=rid:1 recv pt=102 a=rid:2 send pt=101 a=simulcast:recv 0;1 send 2 a=content:main a=label:m a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=video 49156 RTP/AVPF 103 b=AS:800 b=RS:0 b=RR:2500 a=rtpmap:103 H264/90000 a=fmtp:103 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=imageattr:103 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] a=content:slides a=label:s a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=video 49158 RTP/AVPF 104 b=AS:240 b=RS:0 b=RR:2500 a=rtpmap:104 H264/90000 a=fmtp:104 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:104 send [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6] a=sendonly a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=video 49160 RTP/AVPF 105 b=AS:240 b=RS:0 b=RR:2500 a=rtpmap:105 H264/90000 a=fmtp:105 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:105 send [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6] a=sendonly a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=application 50324 TCP/BFCP * a=floorctrl:s-only a=floorid:1 mstrm:m a=floorid:2 mstrm:s a=confid:23984 a=userid:48249 a=setup:active a=connection:new |
T.2.3 MSMTSI answer from an MSMTSI client in terminal
This example assumes the same offer as in clause T.2, which is thus not repeated here, but the answerer is here an MSMTSI client in terminal, supporting all of the offered MSMTSI-specific features, although not all of them are feasible to use between MSMTSI clients in terminal. All audio is omitted in this example, for brevity, but could be added according to any of the other examples in this annex.
Note that the "isFocus" tag is here not included as part of the SIP headers (compare to annex T.3). This information is used by the answering MSMTSI client to construct an appropriate SDP answer.
The answering MSMTSI client has no reason to send any thumbnail videos to another MSMTSI client in terminal, and has thus disabled them. There is no need for simulcast, meaning that the simulcast attribute and the corresponding "a=rid" attributes are removed from the SDP and simulcast will not be used. It can however act as BFCP server and can also support simultaneous main video and screen sharing, which are both kept.
Blank lines are here added in the SDP for improved readability, but are not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
Table T.4: Example SDP answer from MSMTSI towards another MSMTSI
|
SDP answer |
|
m=video 49154 RTP/AVPF 101 b=AS:1060 b=RS:0 b=RR:2500 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240] a=content:main a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=video 49156 RTP/AVPF 103 b=AS:800 b=RS:0 b=RR:2500 a=rtpmap:103 H264/90000 a=fmtp:103 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=imageattr:103 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] a=content:slides a=label:10 a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation m=video 0 RTP/AVPF 104 m=video 0 RTP/AVPF 105 m=application 50324 TCP/BFCP * a=floorctrl:s-only a=floorid:1 mstrm:10 a=confid:237 a=userid:278 a=setup:passive a=connection:new |
T.2.4 MSMTSI simulcast offer using a single payload type
This example offer is an excerpt of just the first "m=" block from the example in clause T.2.1 and effectively offers the same functionality, but does not make use of different payload types to distinguish the simulcast formats. Instead different "a=rid" constraints parameters are used. Because there is only a single format listed on the "m=" line containing the "a=simulcast" line, the "a=rid" lines contains constraints parameters (here max-width and max-height) to differentiate the simulcast formats.
SDP lines specifically interesting to this example are highlighted in bold, which would not be the case in an actual SDP.
Table T.4a: Example SDP simulcast offer from MSMTSI using a single payload type
|
SDP offer |
|
m=video 49154 RTP/AVPF 101 b=AS:1060 b=RS:0 b=RR:2500 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \ [x=176,y=144] [x=224,y=176] [x=320,y=180] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240] \ [x=176,y=144] [x=224,y=176] [x=320,y=180] a=rid:0 send pt=101 max-width=1280;max-height=720 a=rid:1 send pt=101 max-width=320;max-height=180 a=rid:2 recv pt=101 max-width=1280;max-height=720 a=simulcast:send 0;1 recv 2 a=content:main a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation |
T.2.5 MSMTSI simulcast offer using two codecs
This example offer is an excerpt of just the first "m=" block from the example in clause T.2.1 and effectively offers the same functionality, but makes use of simulcast with different video codecs, H.264 and H.265, in addition to the simulcast used for main video thumbnail in clause T.2.1.
SDP lines specifically interesting to this example are highlighted in bold, which would not be the case in an actual SDP.
Table T.4b: Example SDP simulcast offer from MSMTSI using two codecs
|
SDP offer |
|
m=video 49154 RTP/AVPF 101 102 103 104 b=AS:1960 b=RS:0 b=RR:2500 a=rtpmap:101 H265/90000 a=rtpmap:102 H264/90000 a=rtpmap:103 H265/90000 a=rtpmap:104 H264/90000 a=fmtp:101 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \ sprop-pps=RAHAcYDZIA== a=fmtp:103 profile-id=1; level-id=30; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \ sprop-pps=RAHAcYDZIA==; a=fmtp:102 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=fmtp:104 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240] a=imageattr:103 send [x=176,y=144] [x=224,y=176] [x=320,y=180] \ recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6] a=imageattr:102 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \ recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240] a=imageattr:104 send [x=176,y=144] [x=224,y=176] [x=320,y=180] \ recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6] a=rid:0 send pt=101 a=rid:1 send pt=103 a=rid:2 recv pt=101 a=rid:4 send pt=102 a=rid:5 send pt=104 a=rid:6 recv pt=102 a=simulcast:send 0;4;1;5 recv 2,6 a=content:main a=rtcp-rsize 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=rtcp-fb:* ccm pause nowait a=extmap:4 urn:3gpp:video-orientation |