Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

[Christer Holmberg <[e-mail]>]

Hi,



>A new version of I-D, draft-ietf-payload-rtp-jpegxs-14.txt has been submitted and posted to the IETF repository.

>

>We have addressed your comments and remarks as good as possible.

>

>We made the following changes to address all three questions:

>

>-> (Q1) We have moved Section 7.2 to become a separate main section (now section 8).

>-> (Q2) We removed the sentence.

>-> (Q2 and Q3) We reworked both subsections and tried to clarify better what was intended to be expressed.

>

>As such, the intent of the SDP Offer/Answer negotiation is that a receiver can offer a certain set of parameters (and values) that it wants to receive. The answerer (or sender in this case)

>can either honor this offer exactly (i.e. everything in the offer can be matched inside the payload) or drop the offered SDP media description. As an example, when the receiver wants

>4:2:0 content, it can signal this in the offer by specifying the "sampling" parameter with a value of "YCbCr-4:2:0". The sender is not allowed to answer with another sampling format (to counter offer).

>

>On the other hand, if the offerer does not specify a specific optional parameter (meaning it does not care about this specific feature), the answerer is allowed to clarify in the answer such optional parameter.

>For example, an offer is made without specifying the frame rate, the answer is allowed to add the "exactframerate" option with a value that matches the payload. This is true for any unspecified optional parameter in the offer.



Unfortunately I don't think what you explain above is very clear in the text.



Consider the following.



The offerer sends an offer. The offerer specifies the characteristics that the offerer wants to receive. Similarly, the answer specifies the characteristics that the answerer wants to receive - the answerer does NOT specify what it is going to send. which I think the text is currently describing.



So, I think you need to describe that the offerer indicates what it wants to receive.



Then, you need to specify that, if the answerer accepts the offered parameters, it sends an answer, in which it indicates what it wants to receive. It is fine to say that the answerer must indicate the same characteristics as the offerer, if that is required.




"The receiver SHALL ignore any unrecognized parameter or invalid parameter value."

First, In my opinion invalid parameters values shall trigger an error.

Second, what is an unrecognized parameter?


Also, the text does not say what restrictions (if any) there are when it comes to modify the stream during a session. Is it allowed to modify any/all characteristics?


Regards,

Christer



From: avt <[e-mail]<mailto:[e-mail]>> On Behalf Of Christer Holmberg
Sent: Monday 17 May 2021 16:24
To: IETF AVTCore WG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Murray S. Kucherawy <[e-mail]<mailto:[e-mail]>>; mmusic <[e-mail]<mailto:[e-mail]>>
Subject: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

I have performed the SDP directorate review of draft-ietf-payload-rtp-jpegxs-13.

Regards,

Christer

----

Q.1

I suggest converting section 7.2 to a separate main section, and change the name to "SDP Offer/Answer Considerations". I don't think we need to consider other SDP usage than Offer/Answer.


Q.2. Regarding section 7.2.1.:


    "A Session Description Protocol (SDP) [RFC8866] media description SHALL be created for each RTP stream."

This sentence is not needed.


     "The information carried in the media type specification of
      Section 7.1 has a specific mapping to the SDP fields, used to
      describe RTP sessions.  This information is redundant with the
      information found in the payload data (namely, in the JPEG XS header
      segment) and SHALL be consistent with it."

In SDP offer/answer, you typically indicate what you are willing to RECEIVE. In this case it seems like you indicate what you are going to SEND. Is there a reason for that? I guess that impacts Section 7.2.3 too.


Q.3. Regarding Section 7.2.3.:

     "All parameters must be supported by both sides,"

In Section 7.2.1 you say that the receiver shall ignore unrecognized parameters. I ASSUME that you mean that the all the parameter defined in Section 7.2.1.

      "i.e. the answerer SHALL either maintain all parameters or remove the media format (payload
       type) completely if one or more of the parameter values are not
       supported."

I don't understand what this mean. According to Section 7.2.1, some of the parameters are OPTIONAL. Is the answerer only allowed to reply with parameters that were present in the offer?