Questions about SDP format-specific parameters

[garethsb]

RFC 6184 only

This section applies to a Sender with RTP transport directly associated with an H.264 Flow through the Sender's flow_id attribute.

Strictly speaking, I think this whole section applies only when using the RFC 6184 payload mapping... which is already accounted for in the parent section "RTP transport based on RFC 6184".

https://github.com/AMWA-TV/bcp-006-02/blob/400435c00a99f516d3f5147eb5248ed80b5ab42a/docs/NMOS%20With%20H.264.md?plain=1#L175

Declarative Session Descriptions

The SDP file at the manifest_href MUST comply with the requirements of RFC 6184 in the Usage in Declarative Session Descriptions mode of operation.

I think this is a worthwhile clarification/limitation.

The SDP Offer/Answer Model described in RFC 6184 is not supported. The fmtp source attribute as specified in Section 6.3 of [RFC 5576][RFC-5576] is not supported.

I think these are implied by the former statement, i.e. because Declarative Session Descriptions means use-level-src-parameter-sets is 0. Can we indicate that "i.e."?

https://github.com/AMWA-TV/bcp-006-02/blob/400435c00a99f516d3f5147eb5248ed80b5ab42a/docs/NMOS%20With%20H.264.md?plain=1#L179

IS-04/SDP same info

Additionally, the SDP transport file needs to convey, so far as the defined format-specific parameters allow, the same information about the stream as conveyed by the Source, Flow and Sender attributes defined by this specification and IS-04, unless such information is conveyed through in-band parameter sets.

Is it "unless such information is conveyed through in-band parameter sets" or "unless the Sender is operating in dynamic mode"?

https://github.com/AMWA-TV/bcp-006-02/blob/400435c00a99f516d3f5147eb5248ed80b5ab42a/docs/NMOS%20With%20H.264.md?plain=1#L181

sprop-parameter-sets

• The sprop-parameter-sets MUST always be included if the Sender parameter_sets_transport_mode attribute is out_of_band and SHOULD be included if the attribute is in_and_out_of_band.

Why only SHOULD in the latter case?

https://github.com/AMWA-TV/bcp-006-02/blob/400435c00a99f516d3f5147eb5248ed80b5ab42a/docs/NMOS%20With%20H.264.md?plain=1#L190

[alabou]

I think this whole section applies only when using the RFC 6184 payload mapping... The first paragraphs of the Senders section allows introducing the distinction of Flow directly or indirectly associated with a Sender. Note that there are Senders for other transports that are not RFC 6184 payload mapping (ex. NDI without a mux) So having a section for each kind of transport is required.

Can we indicate that "i.e."? Declarative Session Descriptions means use-level-src-parameter-sets is ignored. I think we should be very specific and indicate that it is not supported and hence should not be in the SDP transport file.

Is it "unless such information is conveyed through in-band parameter sets" or "unless the Sender is operating in dynamic mode"? It is "unless such information is conveyed through in-band parameter sets" because we refer to the mechanism used to convey the information. The SDP transport file conveys the information through out_of_band parameter sets. If the information is conveyed in_band then there is no need to convey it out_of_band.

"Why only SHOULD in the latter case?" Because the Sender may choose to send only in-band even if it declares in_and_out_of_band.

[garethsb]

I think this whole section applies only when using the RFC 6184 payload mapping... The first paragraphs

This comment is about that specific sub section, a fifth level heading under the fourth level heading for RFC 6184. This section is all about the SDP parameters defined by RFC 6184. Even other RTP payload mappings would not necessarily use any of these parameters. So I don't understand your response at all.

Can we indicate that "i.e."? Declarative Session Descriptions means use-level-src-parameter-sets is ignored.

Exactly my point. Let's make it clear that's why.

"Why only SHOULD in the latter case?" Because the Sender may choose to send only in-band even if it declares in_and_out_of_band.

That seems wrong to me, if in_and_out_of_band I expect there MUST be out of band parameter sets.

I'll come back to the third point.

[alabou]

"That seems wrong to me, if in_and_out_of_band I expect there MUST be out of band parameter sets."

The Sender may select one or the other or both methods for passing parameter sets when using in_and_out_of_band. If the Sender at some point in time decides to send them in band there is no need to send them out of band. Later the Sender may decide after going inactive that it sends them out of band, then it will use the SDP parameters. This is why I use a SHOULD, it is optional. The mode in_and_out_of_band does not mean at all time using both paths ...

[alabou]

"Why only SHOULD in the latter case?"

Changing the normative text to the following if it makes it easier to understand (removing the SHOULD about in_and_out_of_band but not adding it to the MUST).

"The sprop-parameter-sets MUST always be included if the Sender parameter_sets_transport_mode attribute is out_of_band."

Possibly adding a note indicating that in_and_out_of_band means that both the in-band and out-of-band paths can be used either simultaneously or alternatively.

[alabou]

"I think this whole section applies only when using the RFC 6184 payload mapping... "

I was looking at the wrong sentence, I agree that at the beginning of the section about SDP I should remove the sentences "This section applies to a Sender with RTP transport directly associated with an H.264 Flow through the Sender's flow_id attribute. Informative note: When an H.264 Flow is not directly associated with a Sender but with another Flow through the Flow's parents attribute, it does not have to provide format-specific attributes in the form of an SDP transport file. A Sender has such requirement only for the Flow directly associated with it."

[alabou]

"Can we indicate that "i.e.""

New text:

"The SDP file at the manifest_href MUST comply with the requirements of RFC 6184 Section 8.2.3 Usage in Declarative Session Descriptions mode of operation. The SDP Offer/Answer Model described in RFC 6184 is not supported. The fmtp source attribute as specified in Section 6.3 of RFC 5576 is not supported, i.e. use-level-src-parameter-sets parameter is not present or equal 0."

[garethsb]

"The SDP file at the manifest_href MUST comply with the requirements of RFC 6184 Section 8.2.3 Usage in Declarative Session Descriptions mode of operation. The SDP Offer/Answer Model described in RFC 6184 is not supported. The fmtp source attribute as specified in Section 6.3 of RFC 5576 is not supported, i.e. use-level-src-parameter-sets parameter is not present or equal 0."

Yes, I like that. (I've just added the RFC 6184 section number to your text.)

[garethsb]

Possibly adding a note indicating that in_and_out_of_band means that both the in-band and out-of-band paths can be used either simultaneously or alternatively.

OK... I had understood that this mode would always have out-of-band parameter sets, and might provide in-band ones. I probably need to think a bit more about the use cases for in-band only, out-of-band only and in-and/or-out-of-band.

[garethsb]

Other answers to my questions are making sense to me, now, I think... Thanks, Alain!

[alabou]

Here is the note about in_and_out_of_band

"Informative note: The in-and-out-of-band mode implies that the Sender can optionally use the in-band path, the out-band path or both paths to transmit parameter sets. There is no requirement to use both paths simultaneously."

[alabou]

resolved by PR #20