8.3. Examples
8.3. Examples
An SDP Offer/Answer exchange wherein both parties are expected to both send and receive could look like the following. Only the media- codec-specific parts of the SDP are shown. Some lines are wrapped due to text constraints.
Offerer -> Answerer SDP message:
m=video 49170 RTP/AVP 100 99 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; packetization-mode=0; sprop-parameter-sets=<parameter sets data#0>
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=<parameter sets data#1>
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; sprop-parameter-sets=<parameter sets data#2>; sprop-interleaving-depth=45; sprop-deint-buf-req=64000; sprop-init-buf-time=102478; deint-buf-cap=128000
The above offer presents the same codec configuration in three different packetization formats. Payload type 98 represents single NALU mode, payload type 99 represents non-interleaved mode, and payload type 100 indicates the interleaved mode. In the interleaved mode case, the interleaving parameters that the offerer would use if the answer indicates support for payload type 100 are also included. In all three cases, the parameter sprop-parameter-sets conveys the initial parameter sets that are required by the answerer when receiving a stream from the offerer when this configuration is accepted. Note that the value for sprop-parameter-sets could be different for each payload type.
Answerer -> Offerer SDP message:
m=video 49170 RTP/AVP 100 99 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42A01E; packetization-mode=0; sprop-parameter-sets=<parameter sets data#3>
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=<parameter sets data#4>; max-rcmd-nalu-size=3980
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; sprop-parameter-sets=<parameter sets data#5>; sprop-interleaving-depth=60; sprop-deint-buf-req=86000; sprop-init-buf-time=156320; deint-buf-cap=128000; max-rcmd-nalu-size=3980
As the Offer/Answer negotiation covers both sending and receiving streams, an offer indicates the exact parameters for what the offerer is willing to receive, whereas the answer indicates the same for what the answerer is willing to receive. In this case, the offerer declared that it is willing to receive payload type 98. The answerer accepts this by declaring an equivalent payload type 97; that is, it has identical values for the two parameters profile-level-id and packetization-mode (since packetization-mode is equal to 0 and sprop- deint-buf-req is not present). As the offered payload type 98 is accepted, the answerer needs to store parameter sets included in sprop-parameter-sets=<parameter sets data#0> in case the offer finally decides to use this configuration. In the answer, the answerer includes the parameter sets in sprop-parameter- sets=<parameter sets data#3> that the answerer would use in the stream sent from the answerer if this configuration is finally used.
The answerer also accepts the reception of the two configurations that payload types 99 and 100 represent. Again, the answerer needs to store parameter sets included in sprop-parameter-sets=<parameter sets data#1> and sprop-parameter-sets=<parameter sets data#2> in case the offer finally decides to use either of these two configurations. The answerer provides the initial parameter sets for the answerer-to- offerer direction, i.e., the parameter sets in sprop-parameter- sets=<parameter sets data#4> and sprop-parameter-sets=<parameter sets data#5>, for payload types 99 and 100, respectively, that it will use to send the payload types. The answerer also provides the offerer with its memory limit for de-interleaving operations by providing a deint-buf-cap parameter. This is only useful if the offerer decides on making a second offer, where it can take the new value into
account. The max-rcmd-nalu-size indicates that the answerer can efficiently process NALUs up to the size of 3980 bytes. However, there is no guarantee that the network supports this size.
In the following example, the offer is accepted without level downgrading (i.e., the default level, Level 3.0, is accepted), and both sprop-parameter-sets and sprop-level-parameter-sets are present in the offer. The answerer must ignore sprop-level-parameter- sets=<parameter sets data#1> and store parameter sets in sprop- parameter-sets=<parameter sets data#0> for decoding the incoming NAL unit stream. The offerer must store the parameter sets in sprop- parameter-sets=<parameter sets data#2> in the answer for decoding the incoming NAL unit stream. Note that in this example, parameter sets in sprop-parameter-sets=<parameter sets data#2> must be associated with Level 3.0.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1; sprop-parameter-sets=<parameter sets data#0>; sprop-level-parameter-sets=<parameter sets data#1>
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1; sprop-parameter-sets=<parameter sets data#2>
In the following example, the offer (Baseline profile, Level 1.1) is accepted with level downgrading (the accepted level is Level 1b), and both sprop-parameter-sets and sprop-level-parameter-sets are present in the offer. The answerer must ignore sprop-parameter- sets=<parameter sets data#0> and all parameter sets not for the accepted level (Level 1b) in sprop-level-parameter-sets=<parameter sets data#1> and must store parameter sets for the accepted level (Level 1b) in sprop-level-parameter-sets=<parameter sets data#1> for decoding the incoming NAL unit stream. The offerer must store the parameter sets in sprop-parameter-sets=<parameter sets data#2> in the answer for decoding the incoming NAL unit stream. Note that in this example, parameter sets in sprop-parameter-sets=<parameter sets data#2> must be associated with Level 1b.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A00B; //Baseline profile, Level 1.1 packetization-mode=1; sprop-parameter-sets=<parameter sets data#0>; sprop-level-parameter-sets=<parameter sets data#1>
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42B00B; //Baseline profile, Level 1b packetization-mode=1; sprop-parameter-sets=<parameter sets data#2>; use-level-src-parameter-sets=1
In the following example, the offer (Baseline profile, Level 1.1) is accepted with level downgrading (the accepted level is Level 1b), and both sprop-parameter-sets and sprop-level-parameter-sets are present in the offer. However, the answerer is a legacy RFC 3984 implementation and does not understand sprop-level-parameter-sets; hence, it does not include use-level-src-parameter-sets (which the answerer does not understand either) in the answer. Therefore, the answerer must ignore both sprop-parameter-sets=<parameter sets data#0> and sprop-level-parameter-sets=<parameter sets data#1>, and the offerer must transport parameter sets in-band.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A00B; //Baseline profile, Level 1.1 packetization-mode=1; sprop-parameter-sets=<parameter sets data#0>; sprop-level-parameter-sets=<parameter sets data#1>
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42B00B; //Baseline profile, Level 1b packetization-mode=1
In the following example, the offer is accepted without level downgrading, and sprop-parameter-sets is present in the offer. Parameter sets in sprop-parameter-sets=<parameter sets data#0> must
be stored and used by the encoder of the offerer and the decoder of the answerer, and parameter sets in sprop-parameter-sets=<parameter sets data#1> must be used by the encoder of the answerer and the decoder of the offerer. Note that sprop-parameter-sets=<parameter sets data#0> is basically independent of sprop-parameter- sets=<parameter sets data#1>.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1; sprop-parameter-sets=<parameter sets data#0>
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1; sprop-parameter-sets=<parameter sets data#1>
In the following example, the offer is accepted without level downgrading, and neither sprop-parameter-sets nor sprop-level- parameter-sets is present in the offer, meaning that there is no out- of-band transmission of parameter sets, which then have to be transported in-band.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1
In the following example, the offer is accepted with level downgrading and sprop-parameter-sets is present in the offer. As sprop-parameter-sets=<parameter sets data#0> contains level_idc indicating Level 3.0, it therefore cannot be used, as the answerer wants Level 2.0, and must be ignored by the answerer, and in-band parameter sets must be used.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1; sprop-parameter-sets=<parameter sets data#0>
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0 packetization-mode=1
In the following example, the offer is also accepted with level downgrading, and neither sprop-parameter-sets nor sprop-level- parameter-sets is present in the offer, meaning that there is no out- of-band transmission of parameter sets, which then have to be transported in-band.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0 packetization-mode=1
In the following example, the offer is accepted with level upgrading, and neither sprop-parameter-sets nor sprop-level-parameter-sets is present in the offer or the answer, meaning that there is no out-of- band transmission of parameter sets, which then have to be transported in-band. The level to use in the offerer-to-answerer direction is Level 3.0, and the level to use in the answerer-to-
offerer direction is Level 2.0. The answerer is allowed to send at any level up to and including Level 2.0, and the offerer is allowed to send at any level up to and including Level 3.0.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0 packetization-mode=1; level-asymmetry-allowed=1
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1; level-asymmetry-allowed=1
In the following example, the offerer is a Multipoint Control Unit (MCU) in a topology like Topo-Video-switch-MCU [29], offering parameter sets received (using out-of-band transport) from three other participants (B, C, and D) and receiving parameter sets from the participant A, which is the answerer. The participants are identified by their values of canonical name (CNAME), which are mapped to different SSRC values. The same codec configuration is used by all four participants. The participant A stores and associates the parameter sets included in <parameter sets data#B>, <parameter sets data#C>, and <parameter sets data#D> to participants B, C, and D, respectively, and uses <parameter sets data#B> for decoding NAL units carried in RTP packets originating from participant B only, uses <parameter sets data#C> for decoding NAL units carried in RTP packets originating from participant C only, and uses <parameter sets data#D> for decoding NAL units carried in RTP packets originating from participant D only.
Offer SDP:
m=video 49170 RTP/AVP 98
a=ssrc:SSRC-B cname:CNAME-B
a=ssrc:SSRC-C cname:CNAME-C
a=ssrc:SSRC-D cname:CNAME-D
a=ssrc:SSRC-B fmtp:98 sprop-parameter-sets=<parameter sets data#B>
a=ssrc:SSRC-C fmtp:98 sprop-parameter-sets=<parameter sets data#C>
a=ssrc:SSRC-D fmtp:98 sprop-parameter-sets=<parameter sets data#D>
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1
Answer SDP:
m=video 49170 RTP/AVP 98
a=ssrc:SSRC-A cname:CNAME-A
a=ssrc:SSRC-A fmtp:98 sprop-parameter-sets=<parameter sets data#A>
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1