A.4 SDP offers and answers for video sessions

26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS

A.4.1 Void

A.4.2 Void

A.4.2a H.264/AVC

In this example the SDP offer includes H.264/AVC.

Table A.4.2a1: Example SDP offer for H.264/AVC

SDP offer

m=video 49154 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 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=extmap:4 urn:3gpp:video-orientation

The offered codec is H.264/AVC. The packetization-mode parameter indicates single NAL unit mode. This is the default mode and it is therefore not necessary to include this parameter (see RFC 6184 [25]). The profile-level-id parameter indicates Constrained Baseline profile at level 1.2, which supports bitrates up to 384 kbps. It also indicates, by using so‑called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re‑ordered frames to be zero so that latency can be minimized. The bandwidth (including IP, UDP and RTP overhead) for video is restricted to 315 kbps.

The negotiation of AVPF features is also shown. By setting ‘trr-int’ to 5000 the MTSI client indicates that the minimum interval between two regular RTCP packets needs to be 5 seconds, [40]. The ‘nack’ and ‘nack pli’ parameters indicate that the MTSI client supports NACK (Generic NACK) and PLI (Picture Loss Indication) as defined by AVPF, [40]. The ‘ccm fir’ and ‘ccm tmmbr’ parameters indicate that the MTSI client supports the FIR (Full Intra Request) and TMMBR (Temporary Maximum Media Stream Bit Rate Request), [43]. The wildcard (‘*’) indicates that at it is possible to use these features for all RTP payload types for the video stream.

The negotiation of the video orientation header extension is made with the a=extmap attribute [95]. In this example, the local identifier (ID) is set to ‘4’. This number is only an example and other values may be used.

An example SDP answer to the offer is given below.

Table A.4.2a2: Example SDP answer

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 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=extmap:4 urn:3gpp:video-orientation

The responding MTSI client is capable of using H.264/AVC. As the offer already indicated the lowest level (level 1.2) of H.264/AVC as well as the minimum constraint set, there is no room for further negotiation of profiles and levels. However, the bandwidth could be constrained further by reducing the bandwidth in b=AS.

A.4.2b High Granularity CVO example

This example is identical to A.4.2a with the exception of higher granularity CVO being offered.

Table A.4.2b.1: Example SDP offer with High Granularity

SDP offer

m=video 49154 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 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=extmap:4 urn:3gpp:video-orientation a=extmap:5 urn:3gpp:video-orientation:6

The offer for higher granularity is indicated in the last SDP line above.

Table A.4.2b.2: Example SDP answer with High Granularity

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 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=extmap:5 urn:3gpp:video-orientation:6

The answer indicates that higher granularity has been accepted as indicated by the last SDP line above.

A.4.2c RTP Retransmission

This example is identical to A.4.2a with the exception of retransmission being offered.

Table A.4.2c.1: Example SDP offer with Retransmission

SDP offer

m=video 49154 RTP/AVP 99 100 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtpmap:100 rtx/90000 a=fmtp:100 apt=99;rtx-time=400 a=rtcp-fb:* trr-int 5000 a=rtcp-fb:99 nack a=rtcp-fb:99 nack pli a=rtcp-fb:99 ccm fir a=rtcp-fb:99 ccm tmmbr

The offer for retransmission and associated parameters are listed after the line describing the format properties of the H.264 video.

Table A.4.2c.2: Example SDP answer with Retransmission

SDP answer

m=video 49154 RTP/AVPF 99 100 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtpmap:100 rtx/90000 a=fmtp:100 apt=99;rtx-time=400 a=rtcp-fb:* trr-int 5000 a=rtcp-fb:99 nack a=rtcp-fb:99 nack pli a=rtcp-fb:99 ccm fir a=rtcp-fb:99 ccm tmmbr

The answer indicates that retransmission has been accepted as indicated.

A.4.2d RTP Forward Error Correction (FEC)

This example is identical to A.4.2a with the exception of FEC being offered.

Table A.4.2d.1: Example SDP offer with FEC

SDP offer

m=video 49154 RTP/AVP 99 100 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtpmap:100 flexfec/90000 a=rtpmap:100 repair-window:150000 a=ssrc:1234 a=ssrc:2345 a=ssrc-group:FEC-FR 1234 2345 a=rtcp-fb:* trr-int 5000 a=rtcp-fb:99 nack a=rtcp-fb:99 nack pli a=rtcp-fb:99 ccm fir a=rtcp-fb:99 ccm tmmbr

The offer for FEC and associated parameters are listed after the line describing the format properties of the H.264 video.

Table A.4.2d.2: Example SDP answer with FEC

SDP answer

m=video 49154 RTP/AVPF 99 100 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtpmap:100 flexfec/90000 a=rtpmap:100 repair-window:150000 a=ssrc:1234 a=ssrc:2345 a=ssrc-group:FEC-FR 1234 2345 a=rtcp-fb:* trr-int 5000 a=rtcp-fb:99 nack a=rtcp-fb:99 nack pli a=rtcp-fb:99 ccm fir a=rtcp-fb:99 ccm tmmbr

The answer indicates that FEC has been accepted as indicated.

A.4.2e SDP Examples with ROI

This example is identical to A.4.2a with the exception of ‘Arbitrary ROI’ and ‘Sent ROI’ being offered.

Table A.4.2e.1: Example SDP offer with ‘Arbitrary ROI’ and ‘Sent ROI’

SDP offer

m=video 49154 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 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=extmap:4 urn:3gpp:video-orientation a=rtcp-fb:* 3gpp-roi-arbitrary a=extmap:7 urn:3gpp:roi-sent

The offer for ‘Arbitrary ROI’ and ‘Sent ROI’ are indicated in the last two lines.

The use of RTCP feedback messages carrying ‘Arbitrary ROI’ is negotiated with the ‘3gpp-roi-arbitrary’ parameter. The wildcard (‘*’) indicates that it is possible to use the ROI features for all RTP payload types including video.

The use of the ‘Sent ROI’ header extension carrying arbitrary ROI information is negotiated with the a=extmap attribute [95] based on the URN ‘urn:3gpp:roi-sent’. In this example, the local identifier (ID) is set to 7, which is only an example. Other values may be used as long as a distinct ID is assigned for each extmap attribute corresponding to different URNs.

Table A.4.2e.2: Example SDP answer with ‘Arbitrary ROI’ and ‘Sent ROI’

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 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=extmap:4 urn:3gpp:video-orientation a=rtcp-fb:* 3gpp-roi-arbitrary a=extmap:7 urn:3gpp:roi-sent

The answer indicates that both ‘Arbitrary ROI’ and ‘Sent ROI’ have been accepted.

The following example is identical to A.4.2a with the exception of ‘Pre-defined ROI’ and ‘Sent ROI’ being offered.

Table A.4.2e.3: Example SDP offer with ‘Pre-defined ROI’ and ‘Sent ROI’

SDP offer

m=video 49154 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=predefined_ROI:99 [ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720, \ Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360, \ Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360, \ Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360, \ Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo] 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 a=rtcp-fb:* 3gpp-roi-predefined a=extmap:7 urn:3gpp:predefined-roi-sent

The offer for ‘Pre-defined ROI’ and ‘Sent ROI’ are indicated in the last two lines.

The offered set of pre-defined ROIs is provided by the "a=predefined_ROI" attribute. The use of RTCP feedback messages carrying ‘Pre-defined ROI’ is negotiated with the ‘3gpp-roi-predefined’ parameter. The wildcard (‘*’) indicates that it is possible to use the ROI features for all RTP payload types including video.

The use of the ‘Sent ROI’ header extension carrying pre-defined ROI information is negotiated with the a=extmap attribute [95] based on the URN ‘urn:3gpp:predefined-roi-sent’. In this example, the local identifier (ID) is set to 7, which is only an example. Other values may be used as long as a distinct ID is assigned for each extmap attribute corresponding to different URNs.

Table A.4.2e.4: Example SDP answer with ‘Pre-defined ROI’ and ‘Sent ROI’

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=predefined_ROI:99 [ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720, \ Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360, \ Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360, \ Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360, \ Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo] 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 a=rtcp-fb:* 3gpp-roi-predefined a=extmap:7 urn:3gpp:predefined-roi-sent

The answer indicates that both ‘Pre-defined ROI’ and ‘Sent ROI’ have been accepted.

The following example is identical to A.4.2a with the exception of FECC, ‘Arbitrary ROI’ and ‘Sent ROI’ being offered.

Table A.4.2e.5: Example SDP offer with FECC, ‘Arbitrary ROI’ and ‘Sent ROI’

SDP offer

m=video 49154 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 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=extmap:4 urn:3gpp:video-orientation a=rtcp-fb:* 3gpp-roi-arbitrary a=extmap:7 urn:3gpp:roi-sent m=application 50000 RTP/AVPF 99 a=rtpmap:99 h224/4800 a=sendonly

The offer for FECC is made according to the procedures specified in [139]. In this example, the MTSI client offers a sendonly channel since it is unwilling to adjust the video ROI during encoding based on PTZF commands received from the far end and it does not intend to use H.224 to learn the capabilities of the far end. At the same time, if the far end is capable of FECC, it indicates that it can take advantage of this capability and send PTZF commands to adjust video ROI for the video stream in the receive direction.

Table A.4.2e.6: Example SDP answer with FECC, ‘Arbitrary ROI’ and ‘Sent ROI’

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 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=extmap:4 urn:3gpp:video-orientation a=rtcp-fb:* 3gpp-roi-arbitrary a=extmap:7 urn:3gpp:roi-sent m=application 50000 RTP/AVPF 99 a=rtpmap:99 h224/4800 a=recvonly

The answer indicates that FECC, ‘Arbitrary ROI’ and ‘Sent ROI’ are all accepted. On FECC, the MTSI client answers with a recvonly confirming that it supports the FECC protocol and would be willing to adjust the video ROI during encoding based on PTZF commands received from the far end. As such, FECC can only be used for video in one direction.

The following example is identical to A.4.2a with the exception of FECC, ‘Pre-defined ROI’ and ‘Sent ROI’ being offered.

Table A.4.2e.7: Example SDP offer with FECC, ‘Pre-defined ROI’ and ‘Sent ROI’

SDP offer

m=video 49154 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=predefined_ROI:99 [ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720, \ Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360, \ Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360, \ Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360, \ Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo] 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 a=rtcp-fb:* 3gpp-roi-predefined a=extmap:7 urn:3gpp:predefined-roi-sent m=application 50000 RTP/AVPF 99 a=rtpmap:99 h224/4800 a=sendrecv

In this example, the MTSI client offers a sendrecv channel for FECC since it is willing to adjust the video ROI during encoding based on PTZF commands received from the far end and it intends to use H.224 to learn the capabilities of the far end.

Table A.4.2e.8: Example SDP answer with FECC, ‘Pre-defined ROI’ and ‘Sent ROI’

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=predefined_ROI:99 [ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720, \ Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360, \ Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360, \ Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360, \ Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo] 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 a=rtcp-fb:* 3gpp-roi-predefined a=extmap:7 urn:3gpp:predefined-roi-sent m=application 50000 RTP/AVPF 99 a=rtpmap:99 h224/4800 a=sendonly

The answer indicates that FECC, ‘Pre-defined ROI’ and ‘Sent ROI’ are all accepted. For FECC, the MTSI client answers with a sendonly since it is unwilling to adjust the video ROI during encoding based on PTZF commands received from the far end and it does not intend to use H.224 to learn the capabilities of the far end. At the same time, since the far end is capable of FECC, it indicates that it can take advantage of this capability and send PTZF commands to adjust video ROI for the video stream in the receive direction. As such, FECC can only be used for video in one direction.

A.4.3 Void

A.4.4 Void

A.4.4a H.264/AVC with "imageattr" attribute

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute.

Table A.4.10a: Example SDP offer for H.264/AVC with image size negotiation

SDP offer

a=tcap:1 RTP/AVPF m=video 49154 RTP/AVP 99 a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:99 send [x=176,y=144] [x=224,y=176] [x=272,y=224] [x=320,y=240] recv [x=176,y=144] [x=224,y=176] [x=272,y=224,q=0.6] [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

The offered codec is H.264/AVC. The packetization-mode parameter indicates single NAL unit mode. This is the default mode and it is therefore not necessary to include this parameter (see RFC 6184 [25]). The profile-level-id parameter indicates Baseline profile at level 1.2, which supports bitrates up to 384 kbps. It also indicates, by using so‑called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The bandwidth (including IP, UDP and RTP overhead) for video is 315 kbps. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re‑ordered frames to be zero so that latency can be minimized. sprop-parameter-sets is constructed assuming the offered conditions and image size of 320×240, which is the largest of all offered sizes for send direction. The offering MTSI client offers four image sizes for both send and receive directions but prefers 272×224 for receive direction, which might fit the available space on its display better than the other image sizes.

Since the support of a particular codec level does not imply that the video encoder has to produce a bitstream up to the maximum capability of the level, it may be useful for an MTSI client to indicate the image sizes it can encode video at for each codec it supports, using the "imageattr" SDP attribute [76]. Then on the receiving side, the MTSI client can indicate which of these image sizes it prefers to receive. This reduces the loss of quality from rescaling the decoded image to fit the available space on the receiver’s display.

An example SDP answer to the offer is given below.

Table A.4.10b: Example SDP answer

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:99 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

The responding MTSI client is capable of using H.264/AVC. The responding MTSI client agreed to use a bandwidth of 315 kbps and to use the Baseline profile at level 1.2. From the four image sizes offered, the responding MTSI client included 320×240 for both send and receive directions. Although the offering MTSI client preferred 272×224 for receive direction, the responding MTSI client might not be able to offer 272×224 or not allow encoding and decoding of video of different image sizes simultaneously. The responding MTSI client sent new sprop-parameter-sets for the video decoder of the offering MTSI client, which was constructed assuming the agreed conditions and image size of 320×240.

Table A.4.11: Example SDP answer

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:107 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0;profile-level-id=42e00b; \ sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa a=imageattr:99 send [x=272,y=224] recv [x=320,y=240,q=0.6] [x=272,y=224] 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

In this alternative answer, the responding MTSI client has restricted the video bandwidth to 107 kbps and restricted the H.264/AVC level to 1.1 which supports bitrates up to 192 kbps. The restricted H.264/AVC level should be high enough to enable the image sizes for both send and receive directions. From the four image sizes offered, the responding MTSI client included 272×224 for send direction, which was preferred by the offering MTSI client. For the receive direction, the responding MTSI client included 320×240 as preferred and 272×224 as fallback because the responding MTSI client was unsure whether the offering MTSI client can encode and decode video of different image sizes simultaneously at the conditions. The responding MTSI client sent new sprop-parameter-sets for the video decoder of the offering MTSI client, which was constructed assuming the restricted conditions. Though not required in response to the SDP answer indicating more than one image size in the receive direction, the offering MTSI client may chose to send a second offer as shown in Table A.4.12 to confirm that it is able to encode and decode at different image sizes.

Table A.4.12: Example Second SDP offer

Second SDP Offer

m=video 49154 RTP/AVPF 99 b=AS:107 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0;profile-level-id=42e00b; \ sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa a=imageattr:99 send [x=320,y=240] recv [x=272,y=224] 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

Since now the offering MTSI client knows that the responding MTSI client supports and prefers to use AVPF, AVPF is offered without SDPCapNeg and AVP.

A.4.4a.1 H.264/AVC with "imageattr" attribute – different image sizes in SDP offer and answer

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute.

Table A.4.12ad: Example SDP offer for H.264/AVC with image size negotiation

SDP offer

a=tcap:1 RTP/AVPF m=video 49154 RTP/AVP 99 a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:99 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

The offer in Table A.4.12ad is identical to that in Table A.4.10a except that the MTSI client offers an image size of 320×240 for both directions.

An example SDP answer to the offer is given below.

Table A.4.12ae: Example SDP answer

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:107 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0;profile-level-id=42e00b; \ sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa a=imageattr:99 send [x=272,y=224] recv [x=272,y=224] 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

In this case, the offering MTSI client should proceed with the session setup without issuing another SDP offer to perform image size negotiation.

A.4.4a.2 H.264/AVC with "imageattr" attribute – different payload type numbers in offer and answer

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute.

Table A.4.12af: Example SDP offer for H.264/AVC with image size negotiation

SDP offer

a=tcap:1 RTP/AVPF m=video 49154 RTP/AVP 99 a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:99 send [x=320,y=240] recv [x=272,y=224] 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

The offer in Table A.4.12af is identical to that in Table A.4.10a except that the MTSI client offers image sizes of 320×240 for the send direction and 272×224 for the receive direction.

An example SDP answer to the offer is given below.

Table A.4.12ag: Example SDP answer

SDP answer

m=video 49154 RTP/AVPF 101 a=acfg:1 t=1 b=AS:107 b=RS:0 b=RR:2500 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=0;profile-level-id=42e00b; \ sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa a=imageattr:101 send [x=272,y=224] 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

In this case, the responding MTSI client’s answer matches the image sizes in the offer. However, payload type number 99 is not available (e.g., already used for other media) and payload type number 101 is included instead for video media. After the session is established, the offering MTSI client sends the video with payload type number 101 with image size 320×240 towards the responding MTSI client. Similarly, the answering MTSI client sends the video with payload type number 99 with image size 272×224 towards the offering MTSI client.

A.4.4b H.264/AVC with "imageattr" attribute with multiple rtpmaps

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute with multiple rtpmaps for different image sizes.

Table A.4.12ac: Example SDP offer for H.264/AVC with image size negotiation and multiple rtpmaps

SDP offer

a=tcap:1 RTP/AVPF m=video 49154 RTP/AVP 99 100 a=pcfg:1 t=1 b=AS:900 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KAHpWgKA9oB/U=,aM46gA== a=imageattr:99 send [x=640,y=480] recv [x=640,y=480] a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:100 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

The offered codec is H.264/AVC. The packetization-mode parameter indicates single NAL unit mode. Two image sizes for send and receive directions are offered. The profile-level-id parameter of the first rtpmap indicates Constrained Baseline profile at level 2.2, which supports bitrates up to 4000 kbps. It also indicates, by using so‑called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The bandwidth (including IP, UDP and RTP overhead) for video is 900 kbps. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re‑ordered frames to be zero so that latency can be minimized. sprop-parameter-sets is constructed assuming the offered conditions and image size of 640×480. The profile-level-id parameter of the second rtpmap indicates Constrained Baseline profile at level 1.2, which supports bitrates up to 384kbps. It also indicates, by using so‑called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re‑ordered frames to be zero so that latency can be minimized. sprop-parameter-sets is constructed assuming the offered conditions and image size of 320×240.

An example SDP answer to the offer is given below.

Table A.4.12b: Example SDP answer

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=imageattr:99 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

The responding MTSI client is capable of using H.264/AVC. The responding MTSI client agreed to use a bandwidth of 315 kbps and to use the Constrained Baseline profile at level 1.2. The responding MTSI client included 320×240 for both send and receive directions. Therefore, the final negotiated level is 1.2. The offering MTSI is expecting receiving H.264 RTP packets of resolution 320×240 with payload type number either 99 or 100, while the answering MTSI is expecting receving H.264 RTP packets of resolution 320×240 with payload type number 99.

A.4.5 H.264 with asymmetric video streams

As described in Clause 5.2.2 (Note 5), when a certain level of H.264 (AVC) is offered using the ‘profile-level-id’ parameter then the video codec is capable of receiving a bitstream up to the offered level and the bandwidth offered with b=AS. This however does not necessarily mean that the H.264 video codec will produce a bitstream up to the offere level when sending video. An MTSI client in terminal can use this method to set up asymmetric video streams. One drawback with using this method is that there is no information in the SDP that resource reservation functions in the network, e.g. RAN bearer allocation, could use to allocate transmission resources asymmetrically for the different directions.

A better method to allocate asymmetric video for H.264 (AVC) is to use the ‘level-asymmetry-allowed’ and the ‘max-recv-level’ parameters defined in the H.264 payload format, [25]. The ‘profile-level-id’ parameter then defines the default level while the ‘max-recv-level’ parameter defines the maximum level for the receiving direction. With this method, there is codec-specific information in the SDP that could be used by resource reservation functions to allocate for example radio bearers in a more optimal way.

The SDP example below shows how a session with asymmetric video can be setup using these SDP parameters. The SDP offer sets the default level to 1.2 (max 384 kbps). The maximum receive level is set to 3.1 (max 14 Mbps) but is limited to 2 Mbps using the b=AS bandwidth modifier. The answerer also declares asymmetric video but using lower levels and bitrates. The default level is set to 1.1 (max 192 kbps) and receiving direction is limited to level 1.2 (max 384 kbps)

Table A.4.13: Example SDP offer and answer for asymmetric video with H.264/AVC

SDP offer

m=video 49154 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:2000 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00d; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; level-asymmetry-allowed=1; \ max-recv-level=e01f a=imageattr:99 send [x=320,y=240] [x=640,y=480] recv [x=320,y=240] [x=640,y=480] [x=1280,y=720] 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

SDP answer

m=video 49156 RTP/AVP 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:416 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00b; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; level-asymmetry-allowed=1; \ max-recv-level=e00c a=imageattr:99 send [x=640,y=480] recv [x=640,y=480] 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

A resource reservation function that only uses the bandwidth information in the b=AS bandwidth modifiers will probably allocate 416 kbps in both directions. This means that an overallocation will occur but this does not present any other problems. The offering MTSI client offers two and three image sizes for both send and receive directions. A larger size, 1280×720, is offered only for the receive direction, which has a higher level.

With the ‘provile-level-id’, ‘level-asymmetry-allowed’ and the ‘max-recv-level’ in the SDP, a codec-aware resource allocation function can take advantage of this information and allocate transmission resources more efficiently, e.g. to allocate 192 kbps from the answerer to the offerer and 384 kbps from the offerer to the answerer. From the image sizes offered, the responding MTSI client included 640×480 for both send and receive directions.

A.4.6 H.264/AVC with "imageattr" attribute for non-CVO operation

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute allowing for orientation compensation in case of non-CVO operation (see clause 6.2.3.3 and clause 7.4.5).

Table A.4.14: Example SDP offer for H.264/AVC with image size negotiation

SDP offer

a=tcap:1 RTP/AVPF m=video 49154 RTP/AVP 99 a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=Z0LADJWgUH6Af1A=,aM46gA==,Z0LADEVoPCmgH9Q=,aEjjqA== a=imageattr:99 send [x=320,y=240] [x=240,y=320] recv [x=320,y=240] [x=240,y=320] 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

The offered codec is H.264/AVC. The packetization-mode parameter indicates single NAL unit mode. This is the default mode and it is therefore not necessary to include this parameter (see RFC 6184 [25]). The profile-level-id parameter indicates Constrained Baseline profile at level 1.2, which supports bitrates up to 384 kbps. It also indicates, by using so‑called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The bandwidth (including IP, UDP and RTP overhead) for video is 315 kbps. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re‑ordered frames to be zero so that latency can be minimized. sprop-parameter-sets is constructed assuming the offered conditions and image size of 320×240 and 240×320, and contains separate sequence and picture parameter sets with separate ID for both of the supported image resolutions in the send direction. In this example there are two Sequence Parameter Sets (SPS), numbered 0 and 1. SPS 0 has resolution 320×240. SPS 1 has resolution 240×320. There are two Picture Parameter Sets (PPS), numbered 0 and 1. PPS 0 refers to SPS 0. PPS 1 refers to SPS 1. There are four comma-separated and Base64 encoded NAL units as value for sprop-parameter-sets. The order in the example is SPS0,PPS0,SPS1,PPS1.

While the offering MTSI client indicates support for CVO operation, it also offers a couple of image sizes following the format [x,y] and [y,x] for both send and receive directions which allows for signalling of image rotation by a change of resolution in the bitstream in case the receiving MTSI client does not support CVO operation.

An example SDP answer to the offer is given below.

Table A.4.15: Example SDP answer

SDP answer

m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=Z0LADJWgUH6Af1A=,aM46gA==,Z0LADEVoPCmgH9Q=,aEjjqA== a=imageattr:99 send [x=320,y=240] [x=240,y=320] recv [x=320,y=240] [x=240,y=320] 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

The responding MTSI client is capable of using H.264/AVC. The responding MTSI client agreed to use a bandwidth of 315 kbps and to use the Constrained Baseline profile at level 1.2. The responding MTSI client did not agree CVO operation (removed the extmap attribute) but agreed both offered images sizes 320×240 for both send and receive directions allowing for image rotation compensation in non-CVO operation. The responding MTSI client sent new sprop-parameter-sets for the video encoder of the offering MTSI client, which was constructed assuming the agreed conditions and image sizes.

A.4.7 H.264 (AVC) and H.265 (HEVC)

A.4.7.1 MTSI client with 848×480 resolution 5 inch display

This example SDP offer is for an MTSI client with a 5 inch display that supports 848×480 video and a frame rate of 25 fps. The MTSI client supports H.264 (AVC) Constrained Baseline Profile (CBP) level 3.1. The MTSI client also supports H.265 (HEVC) Main Profile, Main tier level 3.1. When encoding video with H.264 (AVC), the required bandwidth is 690 kbps, including 36 kbps IPv6/UDP/RTP overhead (3 RTP packets per frame), but when H.265 (HEVC) is used, the required bandwidth is only 540 kbps, including 36 kbps overhead (3 RTP packets per frame).

Since the SDP offer includes both codecs, then the b=AS bandwidth must be set to the higher of the bandwidths for those codecs.

Table A.4.16: Example SDP offer for H.264 (AVC) and H.265 (HEVC)

SDP offer

m=video 49154 RTP/AVP 98 97 100 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:690 b=RS:0 b=RR:5000 a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KAHpWgNQ9oB/U=,aM46gA== a=imageattr:100 send [x=848,y=480] recv [x=848,y=480] a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=imageattr:99 send [x=320,y=240] recv [x=320,y=240] a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \ sprop-pps=RAHAcYDZIA== a=imageattr:98 send [x=848,y=480] recv [x=848,y=480] a=rtpmap:97 H265/90000 a=fmtp:97 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \ sprop-pps=RAHAcYDZIA== a=imageattr:97 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

The SDP offer includes the image sizes that are supported in sending and receiving directions. It is recommended to provide codec parameter sets for each image size in the SDP offer.

Table A.4.17 shows an example SDP answer where the answerer receives the SDP offer described in Table A.4.16 and accepts using the H.265 (HEVC) codec. The answerer chooses to use the H.265 (HEVC) codec for increased quality and therefore sets the bandwidth to the same value as in the SDP offer.

Table A.4.17: Example SDP answer when H.265 (HEVC) is used to increase the quality

SDP answer

m=video 49156 RTP/AVPF 98 a=acfg:1 t=1 b=AS:690 b=RS:0 b=RR:5000 a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \ sprop-pps=RAHAcYDZIA== a=imageattr:98 send [x=848,y=480] recv [x=848,y=480] 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

The SDP offer in Table A.4.16 and the SDP answer in Table A.4.17 mean that symmetric bandwidths are requested with 690 kbps in both directions.

Table A.4.18 shows another example SDP answer where the answerer receives the SDP offer described in Table A.4.16 and accepts using the H.265 (HEVC) codec. In this case, the answerer chooses to use the H.265 (HEVC) codec to save bandwidth and therefore sets the bit-rate to 540 kbps.

Table A.4.18: Example SDP answer when H.265 (HEVC) is used to reduce the bit-rate

SDP answer

m=video 49156 RTP/AVPF 98 a=acfg:1 t=1 b=AS:540 b=RS:0 b=RR:5000 a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \ sprop-pps=RAHAcYDZIA== a=imageattr:98 send [x=848,y=480] recv [x=848,y=480] 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

The SDP offer in Table A.4.16 and the SDP answer in Table A.4.18 mean that asymmetric bandwidths are requested. The offerer requested to receive 690 kbps while the answerer requested to receive 540 kbps. This discrepency however can be solved by sending a new SDP offer with only the selected codec.

A.4.7.2 MTSI client with 1280×720 resolution 5 inch display

This example SDP offer is for an MTSI client with a 5 inch display that supports 1280×720 video and a frame rate of 25 fps. The MTSI client supports H.264 (AVC) Constrained Baseline Profile (CBP) level 3.1 and H.265 (HEVC) Main Profile, Main tier level 3.1. When encoding video with H.264 (AVC), the required bandwidth is 950 kbps, including 48 kbps IPv6/UDP/RTP overhead (4 RTP packets per frame), but when H.265 (HEVC) is used, the encoder uses only 640 kbps, including 36 kbps overhead (3 RTP packets per frame).

The answerer is also an MTSI client that supports H.264 (AVC) and H.265 (HEVC) in the same way as the offerer.

Table A.4.19: Example SDP offer for H.264 (AVC) and H.265 (HEVC) and example SDP answer for H.265 (HEVC)

SDP offer

m=video 49154 RTP/AVP 98 97 100 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:950 b=RS:0 b=RR:5000 a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KAH5WgFAFugH9Q,aM46gA== a=imageattr:100 send [x=1280,y=720] recv [x=1280,y=720] a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KAHpWgKA9oB/U=,aM46gA== a=imageattr:99 send [x=640,y=480] recv [x=640,y=480] a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \ sprop-pps=RAHAcYDZIA== a=imageattr:98 send [x=1280,y=720] recv [x=1280,y=720] a=rtpmap:97 H265/90000 a=fmtp:97 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAUCAeFlLktIvQB3CAQQ; \ sprop-pps=RAHAcYDZIA== a=imageattr:97 send [x=640,y=480] recv [x=640,y=480] 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

SDP answer

m=video 49156 RTP/AVPF 98 a=acfg:1 t=1 b=AS:500 b=RS:0 b=RR:5000 a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \ sprop-pps=RAHAcYDZIA== a=imageattr:98 send [x=1280,y=720] recv [x=1280,y=720] 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

The SDP offer includes the image sizes that are supported in sending and receiving directions.

The answerer could also have chosen to use H.265 (HEVC) to improve the quality, similar to what is discussed for Table A.4.17. In this case, the answerer would set the bandwidth to the same value as in the SDP offer.

Another possibility is that the answerer wants to use H.265 (HEVC) partly to increase the quality and partly to reduce the bit-rate. In this case the answerer would select a bit-rate that is in-between the bit-rate in the SDP offer and the bit-rate in the SDP answer as shown in Table A.4.19.

A.4.7.3 MTSI client with 848×480 resolution 10 inch display

This example SDP offer is for an MTSI client with 10 inch display that supports 848×480 video and a frame rate of 25 fps. The MTSI client supports H.264 (AVC) Constrained Baseline Profile (CBP) level 3.1 and H.265 (HEVC) Main Profile, Main tier level 3.1. When encoding video with H.264 (AVC), the required bandwidth is 900 kbps, including 48 kbps IPv6/UDP/RTP overhead (4 RTP packets per frame), but when H.265 (HEVC) is used, the encoder uses only 690 kbps, including 36 kbps of overhead (3 RTP packets per frame).

The answerer is also an MTSI client that supports H.264 (AVC) and H.265 (HEVC) in the same way as the offerer. The answerer chooses to use the H.265 (HEVC) codec to save bandwidth and therefore sets the bit-rate to 690 kbps.

Table A.4.20: Example SDP offer for H.264 (AVC) and H.265 (HEVC) and example SDP answer for H.265 (HEVC)

SDP offer

m=video 49154 RTP/AVP 98 97 100 99 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 b=AS:900 b=RS:0 b=RR:5000 a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KAHpWgNQ9oB/U=,aM46gA== a=imageattr:100 send [x=848,y=480] recv [x=848,y=480] a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA== a=imageattr:99 send [x=320,y=240] recv [x=320,y=240] a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \ sprop-pps=RAHAcYDZIA== a=imageattr:98 send [x=848,y=480] recv [x=848,y=480] a=rtpmap:97 H265/90000 a=fmtp:97 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \ sprop-pps=RAHAcYDZIA== a=imageattr:97 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

SDP answer

m=video 49156 RTP/AVPF 98 a=acfg:1 t=1 b=AS:690 b=RS:0 b=RR:5000 a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \ sprop-pps=RAHAcYDZIA== a=imageattr:100 send [x=848,y=480] recv [x=848,y=480] 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

The SDP offer includes the image sizes that are supported in sending and receiving directions.

Similar to the previous examples, the answerer could also have chosen to use H.265 (HEVC) to improve the quality or to use the codec partly to improve the quality and partly to reduce the bit-rate.

A.4.7.4 MTSI client with 1280×720 resolution 10 inch display

This example SDP offer is for an MTSI client with a 10 inch display that supports 1280×720 video and a frame rate of 25 fps. The MTSI client supports H.264 (AVC) Constrained Baseline Profile (CBP) level 3.1 and H.265 (HEVC) Main Profile, Main tier level 3.1. When encoding video with H.264 (AVC), the required bandwidth is 1060 kbps, including 60 kbps IPv6/UDP/RTP overhead (5 RTP packets per frame), but when H.265 (HEVC) is used, the required bandwidth is only 800 kbps, including 48 kbps overhead (4 RTP packets per frame).

The answerer is also an MTSI client that supports H.264 (AVC) and H.265 (HEVC) in the same way as the offerer. The answerer chooses to use the H.265 (HEVC) codec to save bandwidth and therefore sets the bit-rate to 800 kbps.

Table A.4.21: Example SDP offer for H.264 (AVC) and H.265 (HEVC) and example SDP answer for H.265 (HEVC)

SDP offer

m=video 49154 RTP/AVP 98 97 100 99 a=tcap:1 RTP/AVPF a=pcfg: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=42e01f; \ sprop-parameter-sets=Z0KAH5WgFAFugH9Q,aM46gA== a=imageattr:100 send [x=1280,y=720] recv [x=1280,y=720] a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets=Z0KAHpWgKA9oB/U=,aM46gA== a=imageattr:99 send [x=640,y=480] recv [x=640,y=480] a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \ sprop-pps=RAHAcYDZIA== a=imageattr:98 send [x=1280,y=720] recv [x=1280,y=720] a=rtpmap:97 H265/90000 a=fmtp:97 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAUCAeFlLktIvQB3CAQQ; \ sprop-pps=RAHAcYDZIA== a=imageattr:97 send [x=640,y=480] recv [x=640,y=480] 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

SDP answer

m=video 49156 RTP/AVPF 100 a=acfg:1 t=1 b=AS:800 b=RS:0 b=RR:5000 a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=93; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \ sprop-pps=RAHAcYDZIA== a=imageattr:98 send [x=1280,y=720] recv [x=1280,y=720] 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

The SDP offer includes the image sizes that are supported in sending and receiving directions.

Similar to the previous examples, the answerer could also have chosen to use H.265 (HEVC) to improve the quality or to use the codec partly to improve the quality and partly to reduce the bit-rate.

A.4.8 H.264 (AVC) and H.265 (HEVC) with asymmetric video streams

This example SDP offer shows how an asymmetric video session can be set up. The SDP offer is based on the example SDP offer shown in Annex A.4.7.4 (10 inch display, 1280×720 resolution) with modifications to allow for setting up an asymmetric session where the receive level is higher than the default level. The following video encoding and decoding capabilities apply:

– For H.264 (AVC):

– The Constrained Baseline Profile (CBP) is used.

– The default level is 1.2, max 384 kbps, as shown with ‘profile-level-id=42e00c’. This is then used for the maximum level in the sending direction if H.264 (AVC) is accepted by the answerer.

– The maximum level in the receiving direction is 3.1, as shown with‘max-recv-level=e01f’.

– Asymmetric session is allowed as shown with ‘level-asymmetry-allowed=1’.

– The maximum bitrate in the receiving direction is limited to 1060 kbps with ‘b=AS:1060’.

– For H.265 (HEVC):

– The Main Profile is used.

– The default level is 1.0, max128 kbps, as shown with ‘level-id=30’. This is then used for the maximum level in the sending direction if H.265 (HEVC) is accepted by the answerer.

– The maximum level in the receiving direction is 3.1, as shown with ‘max-recv-level-id=93’.

– Asymmetric session is allowed as shown by including the ‘max-recv-level-id’ parameter.

– The offerer would like to receive max 800 kbps if H.265 (HEVC) is accepted but there is no possibility to indicate this in the SDP offer.

Table A.4.22: Example SDP offer and answer for asymmetric video with H.264 (AVC) and H.265 (HEVC)

SDP offer

m=video 49154 RTP/AVP 98 97 100 99 a=tcap:1 RTP/AVPF a=pcfg: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=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; \ level-asymmetry-allowed=1; max-recv-level=e01f a=imageattr:100 send [x=320,y=240] recv [x=1280,y=720] [x=320,y=240] a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; \ level-asymmetry-allowed=1; max-recv-level=e01f a=imageattr:99 send [x=320,y=240] recv [x=640,y=480] [x=320,y=240] a=rtpmap:98 H265/90000 a=fmtp:98 profile-id=1; level-id=30; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \ sprop-pps=RAHAcYDZIA==; \ max-recv-level-id=93 a=imageattr:98 send [x=320,y=240] recv [x=1280,y=720] [x=320,y=240] a=rtpmap:97 H265/90000 a=fmtp:97 profile-id=1; level-id=30; \ sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \ sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \ sprop-pps=RAHAcYDZIA==; \ max-recv-level-id=90 a=imageattr:97 send [x=320,y=240] recv [x=640,y=480] [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

The SDP offer includes the image sizes that are supported in sending and receiving directions. Different resolutions are offered by including two RTP payload types for H.264 (AVC) and H.265 (HEVC), respectively.

For PT=98, the MTSI client in terminal specifies max-recv-level-id=93 since this is needed for 1280×720 resolution. But for PT=97, it specifies max-recv-level-id=90 since this is sufficient for 640×480 resolution.