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

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 May 2021 14:24:17 +0000

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?

---

From: Tim Bruylants <[email-masked]>
Date: Mon, 24 May 2021 09:30:13 +0000

Dear Christer,

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.

We hope this addresses all concerns regarding SDP.

Best regards,
Tim Bruylants.

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

Hi,

Regards,

Christer

----

Q.1

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 May 2021 21:02:18 +0000

Hi,

>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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Christer Holmberg
Sent: Monday 17 May 2021 16:24
To: IETF AVTCore WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>>; mmusic <[email-masked]<mailto:[email-masked]>>
Subject: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

----

Q.1

---

From: Thomas Richter <[email-masked]>
Date: Tue, 25 May 2021 09:36:49 +0200

Hi Christer, hi Tim,

> 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.

Sorry to sound confused, but maybe you could explain a bit better. To my 
understanding, it is the offerer that describes what it offers to send, 
and not the other way around? Maybe I misunderstand something very 
fundamental? Sorry to ask these elementary questions, but this is 
important for the text.

> “The receiver SHALL ignore any unrecognized parameter or invalid 
> parameter value.”
> 

I wonder why we need to specify this, i.e. what a receive does about 
parameters it does not recognize? Essentially, this is a problem of 
"foreward compatibility". Wouldn't it be a matter of implementation 
whether the receiver accepts an offer (note well, the receiver), and 
attempts to decode a stream on a "best effort" basis, keeping in mind 
that the stream itself includes additional means to identify required 
capabilities necessary for a successful decode.

If that is not an option, we would/could need means to identify the type 
of parameters in a foreward compatible way. I.e., conventions by which 
we would identify in the future parameters a receiver can safely ignore 
and attempt to decode, and parameters a receiver cannot safely ignore.

However, I believe this is getting a bit out of hands...

> 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?

My understanding is that you cannot modify characteristics during a 
session. If you need to modify, you need to setup a new session and 
cancel the current one. For JPEG XS stream decoders, one cannot expect 
that an instanciated decoder can decode from modified parameters in 
mid-stream level. That is, if you start decoding in full-HD, and then 
stream parameters become 8K, the decoder will have to abort.

Thanks for helping and clarifying,

Greetings,
	Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2021 16:38:10 +0000

Hi,

>> characteristics that the answerer wants to receive - the answerer does 
> Sorry to sound confused, but maybe you could explain a bit better. To my understanding, it is the offerer that describes what it offers to send, and not the other way around? 
> Maybe I misunderstand something very fundamental? Sorry to ask these elementary questions, but this is important for the text.

In SDP Offer/Answer, the default is to indicate what you are willing to RECEIVE :)

Typically your receiving capabilities also implicitly indicate what you are able to send. For example, if I am indicating that I am willing to receive codec X it normally means that I am also able to send codec X.

 But, there are cases where that is not true, especially when it comes to video codes where you typically have more parameters associated with the codec, and one needs to explicitly indicate sending capabilities. 

---

> I wonder why we need to specify this, i.e. what a receive does about parameters it does not recognize? Essentially, this is a problem of "foreward compatibility". Wouldn't it
> be a matter of implementation whether the receiver accepts an offer (note well, the receiver), and attempts to decode a stream on a "best effort" basis, keeping in mind that
> the stream itself includes additional means to identify required capabilities necessary for a successful decode.
>
> If that is not an option, we would/could need means to identify the type of parameters in a foreward compatible way. I.e., conventions by which we would identify in the future
> parameters a receiver can safely ignore and attempt to decode, and parameters a receiver cannot safely ignore.

I think it is fine to say that unrecognized parameters shall be ignored. It is then up to future specifications to worry about backward compatibility, rather than this specification worrying about forward compatibility.

>> 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?
>
> My understanding is that you cannot modify characteristics during a session. If you need to modify, you need to setup a new session and cancel the current one. For JPEG XS stream decoders,
> one cannot expect that an instanciated decoder can decode from modified parameters in mid-stream level. That is, if you start decoding in full-HD, and then stream parameters become 8K, the
> decoder will have to abort.

These kind of things need to be specified. I don't think it needs to be forbidden to try to modify something, because there could be text that strongly recommends against doing it.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2021 16:42:37 +0000

This is a structure that is typically used for SDP offer/answer procedures:

X.  SDP Offer/Answer Procedures
     X.1.  Generic SDP Considerations
	<Here you can describe things which apply to both offers and answers>
     X.2.  Generating the Initial SDP Offer
	<Here you describe how the initial SDP offer for the session is generated>
     X.3.  Generating the SDP Answer
	<Here you describe how the answerer generates the SDP answer, including whether parameters/parameter values need to be a subset of the parameters/parameter values in the offer etc>
     X.4.  Offerer Processing of the SDP Answer
     7.5.  Modifying the Session
	<Here you describe constraints related to modification of the session, including whether there are certain parameters/parameter values that you cannot modify etc>

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <[email-masked]>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

>> 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.
>

---

> "foreward compatibility". Wouldn't it be a matter of implementation whether the receiver accepts an offer (note well, the receiver), and attempts to decode a stream on a "best effort" basis, keeping in mind that the stream itself includes additional means to identify required capabilities necessary for a successful decode.
>
> If that is not an option, we would/could need means to identify the 
> type of parameters in a foreward compatible way. I.e., conventions by which we would identify in the future parameters a receiver can safely ignore and attempt to decode, and parameters a receiver cannot safely ignore.

> cancel the current one. For JPEG XS stream decoders, one cannot expect that an instanciated decoder can decode from modified parameters in mid-stream level. That is, if you start decoding in full-HD, and then stream parameters become 8K, the decoder will have to abort.

Regards,

Christer

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Tim Bruylants <[email-masked]>
Date: Fri, 28 May 2021 06:49:24 +0000

Hi Christer,

I'm a little bit stuck in how to resolve and address your comments. On one hand I understand that we want the text to be clear, but on the other hand we do not want to repeat SDP specifics too much. SDP is just one way to negotiate a session, and in the case of XS it is not the most commonly used one. XS is not really intended for the classical video-call case, but rather to stream high-quality video content in a professional environment. It can be used for video conferencing, but better suited codecs exist for that use-case.

However, what is important to lay out correctly is the mapping of the media parameters into the a=fmtp field of SDP, because this is actually used by many other protocols (so, just the media description part of SDP is used).

Originally, we based our draft text on RFC 8450 (VC-2 HQ RTP Payload). In that respect, what is written there kind of fits exactly what we want with XS. Given that this is a published RFC, we are puzzeled a bit as to why our draft would need to elaborate so extensively on SDP. For sure, we'd like to allow SDP offer/answer negotiation with XS. But this is very simple: each side tells the other side what it supports, and that's it. In XS the parameters are declarative, meaning (at least that's what we want to express) that each parameter is represents an exact value and is not "inclusive" into a range of lesser values. In other words, the other side cannot expect that a "lesser" value of a parameter can work.

Your proposed structure is just to elaborate and out of scope. As such, I would ask you to consider the example of RFC 8450 (where the use-case and purpose matches that of our draft). For example: Why do we need to state anything specific on "Modifying the Session"? Isn't this layed out by SDP on how to modify a session? There's nothing specific to be put in our draft (we do not want to prevent, not suggest this functionality).

I hope you can understand our difficulty with your remarks and comments. Our proposal as such is to keep the text about SDP very short and simple. The RTP Payload draft can be used with SDP, but it's certainly not the only way.

I will be preparing an updated draft which tries to be very minimal on the SDP specifics. Unless anything is technically wrong, I really hope you can agree to it and move forward with the publication process.

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <[email-masked]>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 May 2021 08:39:03 +0000

Hi,

First, regarding RFC 8450, that specification was probably never reviewed by the SDP directorate, so I can't really comment on that. But, I see that the RFC e.g., says nothing about whether the SDP indicates sending or receiving capabilities.

Second, nobody mandates you to use SDP, and most part of the spec is protocol independent. But, the "SDP Offer/Answer" section describes the SDP offer/answer procedures, *IF* you choose to use that mechanism for negotiating the session.

Third, I don't think you need very much text. The important thing is to say what is placed in offers and answers, whether there are constraints when generating the answer, and whether there are constraints when it comes to modifying the session. And, you do NOT  need to specify HOW to modify a session, but whether there are payload-specific constraints when doing.

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]> 
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <[email-masked]>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

---

From: Tim Bruylants <[email-masked]>
Date: Fri, 28 May 2021 10:20:52 +0000

Hi Christer,

Thanks for the quick response, we really appreciate your time.

>> First, regarding RFC 8450, that specification was probably never reviewed by the SDP directorate, so I can't really comment on that. But, I see that the RFC e.g., says nothing about whether the SD…

Ok, I understand that RFC 8450 might not be entirely clear or well written on the SDP part.

>> Second, nobody mandates you to use SDP, and most part of the spec is protocol independent. But, the "SDP Offer/Answer" section describes the SDP offer/answer procedures, *IF* you choose to use tha…

Ok. That I understand. In our case, SDP as the session protocol is not critical, but still a nice to have. Do you agree? Or do you recommend we remove the SDP offer/answer section?

What we do need to say is how to map parameters into an SDP-compliant format description, for the same reasons as RFC 8450 and many other video payload RFC's (VP8, VP9, H.264/AVC, H.265/HEVC, etc). This allows using many other session negotiation protocols that rely on the SDP description.

>> Third ....

I believe what is very important to explain is that all of our parameters are declarative, meaning that they describe exact bitstream properties, and not receiver capabilities. The SDP parameters can be used to communicate between sender/receiver what they wish to exchange before sending actual payload, but none of these parameters or values are "downgradable" or "inclusive capability sets". XS does not have such concepts, as it is a low-complexity codec, intended primarily to replace uncompressed video streams.

Somehow, this raises the following:

X.1 Generic SDP Considerations
  I believe here we explain that parameters are declarative and represent bitstream/payload values/settings. So both sides can use these to indicate what the payload will look like.

X.2.  Generating the Initial SDP Offer
  Not much to say here. As I understand an SDP session can be initiated from either receiver or sender sides? So, they just send a valid media description of the content they want to exchange. If either side cannot handle certain payload settings, then it should reject the offer (or answer). An offerer just sends what it wants to receive or send.

X.3.  Generating the SDP Answer
  I don't think there is anything special to mention here? The answerer takes the declarative parameters and either accepts or rejects the session. It should NOT modify the offer in any way.

X.4.  Offerer Processing of the SDP Answer
  I don't think there is anything special to mention here? If the answer accepted the offer, then the stream can start.

X.5.  Modifying the Session
  Modifying the session is possible, but this is very implementation specific. Basically, modifying a session is very similar to creation of a new session. Both sides should agree on the payload they will exchange.

I'm sorry to drag this out, but I think that having this conversation by email is more efficient than posting drafts 😊 I appreciate your feedback.

Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]> 
Sent: Friday 28 May 2021 10:39
To: Tim Bruylants <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]>
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

---

From: Tim Bruylants <[email-masked]>
Date: Mon, 31 May 2021 07:07:26 +0000

Hi Christer,

Before I upload a new draft to address the SDP, I would like you to revise the following text.

As you stated, when describing the SDP offer/answer model, the draft needs to address the 5 following topics:

Our question: Is this sufficiently described in RFC3264 and is it ok to refer to that RFC with some extra clarifications? RFC3264 seems to be what we intend "if" sdp offer/answer is used. This would result in the following text:

//--- SNIPPET
8.2.  Usage with SDP Offer/Answer Model

   When JPEG XS is offered over RTP using SDP in an offer/answer model
   [RFC3264] for negotiation for unicast usage, the following
   limitations and rules apply:

      The "a=fmtp" attribute SHALL be present specifying the required
      parameter "transmode" and MAY specify any of the
      optional parameters, as described in Section 7.1.

      All payload parameters are declarative, meaning that they describe
      properties of the payload.

      A receiver of the SDP is required to support all parameters and
      values of the parameters provided; otherwise, the receiver SHALL
      reject the session.  It falls on the creator of the session to use
      values that are expected to be supported by the receiving
      application.
//--- SNIPPET

Feedback would be very welcome.

Kind regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Tim Bruylants
Sent: Friday 28 May 2021 12:21
To: Christer Holmberg <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Friday 28 May 2021 10:39
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Vvsa7uFA5z0DWnBSoNEnva_4ij5rbcQGOwLp_i-3z7w&s=aueJioTltY05kxfB21RFOvSQsz8lulToyXQzbctJCvc&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]>
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=
_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Vvsa7uFA5z0DWnBSoNEnva_4ij5rbcQGOwLp_i-3z7w&s=oiL2pdl7h_6LVY-4E88hVVI1NoDWs6jBOLb1rWrA_nI&e=

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 May 2021 14:10:25 +0000

Hi Tim,

>X.4.  Offerer Processing of the SDP Answer X.5.  Modifying the Session
>

A couple of comments:

Q1:

"All payload parameters are declarative, meaning that they describe properties of the payload."

I don't think you need to say that.

Based on our earlier discussions, I think what you need to point out is that the fmtp attribute is used to indicate SENDING capabilities.

----

Q2:

"A receiver of the SDP is required to support all parameters and
values of the parameters provided; otherwise, the receiver SHALL
reject the session.  It falls on the creator of the session to use
values that are expected to be supported by the receiving
application."

Instead of "receiver", I would say answerer.

Instead of "creator", I would say offerer.

Also, assuming the answerer/receiver accepts the offer, there is no text on what it includes in the answer. Does the answerer also include an fmtp attribute? If so, what values does it include?

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Tim Bruylants
Sent: Friday 28 May 2021 12:21
To: Christer Holmberg <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Friday 28 May 2021 10:39
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Vvsa7uFA5z0DWnBSoNEnva_4ij5rbcQGOwLp_i-3z7w&s=aueJioTltY05kxfB21RFOvSQsz8lulToyXQzbctJCvc&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]>
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

---

From: Tim Bruylants <[email-masked]>
Date: Mon, 31 May 2021 14:42:14 +0000

Hi Christer,

1) You are correct that the parameters are describing what the sender will be using in the payload (strictly speaking these are not capabilities, but rather strict payload settings that will be honored). The receiver should be able to handle such settings (as described by these parameters).
I will adjust that part to reflect what you propose.

2) I will indeed replace creator/receiver by offeror/answerer respectively. As for the answerer: on accepting the connection with the offered parameters, there is not much to send back w.r.t. parameters. But for easy of recognizing the negotiated stream, we believe the answerer should use the same fmtp (as given in the offer) in its answer.

So, updated text would become:

//--- SNIPPET

      The "a=fmtp" attribute SHALL be present specifying the required
      parameter "transmode" and MAY specify any of the optional
      parameters, as described in Section 7.1.

      All parameters in the "a=fmtp" attribute indicate sending
      capabilities (i.e. properties of the payload).

      An answerer of the SDP is required to support all parameters and
      values of the parameters provided by the offeror; otherwise, the
      answerer SHALL reject the session.  It falls on the offeror of the
      session to use values that are expected to be supported by the
      answering application.  If the answerer accepts the session, it
      SHALL reply with the exact same parameters in the "a=fmtp"
      attribute as it was offered.
//--- SNIPPET

If you believe this is ok, I will post an updated draft to the datatracker.

Best regards,
Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]> 
Sent: Monday 31 May 2021 16:10
To: Tim Bruylants <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Tim,

A couple of comments:

Q1:

----

Q2:

"A receiver of the SDP is required to support all parameters and values of the parameters provided; otherwise, the receiver SHALL reject the session.  It falls on the creator of the session to use values that are expected to be supported by the receiving application."

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Tim Bruylants
Sent: Friday 28 May 2021 12:21
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=PvIKnoy2IRMR_ZyjQGDfXoFAuZZJVu2LEa37CHGliG0&s=gL_91hww2CtfhSCaQrbJTubUO1KecjNtFF_w9WORD5g&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Friday 28 May 2021 10:39
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Vvsa7uFA5z0DWnBSoNEnva_4ij5rbcQGOwLp_i-3z7w&s=aueJioTltY05kxfB21RFOvSQsz8lulToyXQzbctJCvc&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]>
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 May 2021 14:53:14 +0000

Hi Tim,

>1) You are correct that the parameters are describing what the sender will be using in the payload (strictly speaking these are not capabilities, but rather strict payload settings that will be honored). 

Fair enough. Perhaps "sending properties"?

>The receiver should be able to handle such settings (as described by these parameters).
>2) I will indeed replace creator/receiver by offeror/answerer respectively. As for the answerer: on accepting the connection with the offered parameters, there is not much to send back w.r.t. parameters. 
>But for easy of recognizing the negotiated stream, we believe the answerer should use the same fmtp (as given in the offer) in its answer.

Does that also include the actual payload type number value?

>So, updated text would become:

It looks ok, but I suggest to change:

"offeror of the session" -> "offerer"

"answering application" -> "answerer"

...because that is the terminology we use to identity the entities when talking about offer and answer.

Also, I guess you should say "SHALL reply with the exact same parameter VALUES in the...".

Regards,

Christer

//--- SNIPPET

Best regards,
Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Monday 31 May 2021 16:10
To: Tim Bruylants <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Tim,

A couple of comments:

Q1:

----

Q2:

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Tim Bruylants
Sent: Friday 28 May 2021 12:21
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=PvIKnoy2IRMR_ZyjQGDfXoFAuZZJVu2LEa37CHGliG0&s=gL_91hww2CtfhSCaQrbJTubUO1KecjNtFF_w9WORD5g&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Friday 28 May 2021 10:39
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Vvsa7uFA5z0DWnBSoNEnva_4ij5rbcQGOwLp_i-3z7w&s=aueJioTltY05kxfB21RFOvSQsz8lulToyXQzbctJCvc&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]>
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

---

From: Tim Bruylants <[email-masked]>
Date: Mon, 31 May 2021 16:16:33 +0000

Hi Christer,

1) I believe "... sending capabilities (i.e. properties of the payload)..." is correct.

2a) I'm not 100% sure that I understand what you mean by this. Normally I would assume that the same payload type is to be used in an answer (to simplify things). Allthough in RFC3264 this is a SHOULD and not a MUST. So, I added a sentence to also recommend this.

2b) I made the suggested changes (offerer/answerer). It is good to follow common terminology. I also agree about the VALUES (I was in doubt when writing that sentence about this, so it's good that you mention this).

//--- SNIPPET

      An answerer of the SDP is required to support all parameters and
      values of the parameters provided by the offerer; otherwise, the
      answerer SHALL reject the session.  It falls on the offerer to use
      values that are expected to be supported by the answerer.  If the
      answerer accepts the session, it SHALL reply with the exact same
      parameters values in the "a=fmtp" attribute as it was offered.

      The same RTP payload type number used in the offer SHOULD be
      used in the answer, as specified in [RFC3264].
//--- SNIPPET

Best regards,
Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]> 
Sent: Monday 31 May 2021 16:53
To: Tim Bruylants <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Tim,

Regards,

Christer

//--- SNIPPET

Best regards,
Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Monday 31 May 2021 16:10
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Rd7pE4WEooBpksYDJTrap3ir89kSXxdINLNPVYwj-s0&s=VCs6MHc80KmsyJ0a-rSU4WyyiHeMQi2f5iFiQyW-B9Y&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Tim,

A couple of comments:

Q1:

----

Q2:

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Tim Bruylants
Sent: Friday 28 May 2021 12:21
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=PvIKnoy2IRMR_ZyjQGDfXoFAuZZJVu2LEa37CHGliG0&s=gL_91hww2CtfhSCaQrbJTubUO1KecjNtFF_w9WORD5g&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Friday 28 May 2021 10:39
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Vvsa7uFA5z0DWnBSoNEnva_4ij5rbcQGOwLp_i-3z7w&s=aueJioTltY05kxfB21RFOvSQsz8lulToyXQzbctJCvc&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]>
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 May 2021 16:21:23 +0000

Hi,

>2a) I'm not 100% sure that I understand what you mean by this. Normally I would assume that the same payload type is to be used in an answer (to simplify things). Allthough in RFC3264 this is a SHOU…

Sorry for being unclear. I meant the numeric number value that is assigned to the payload. I see that you have covered that now :)

>2b) I made the suggested changes (offerer/answerer). It is good to follow common terminology. I also agree about the VALUES (I was in doubt when writing that sentence about this, so it's good that y…

The text looks ok now.

Thanks!

Regards,

Christer

//--- SNIPPET

Best regards,
Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Monday 31 May 2021 16:53
To: Tim Bruylants <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Tim,

Regards,

Christer

//--- SNIPPET

Best regards,
Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Monday 31 May 2021 16:10
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Rd7pE4WEooBpksYDJTrap3ir89kSXxdINLNPVYwj-s0&s=VCs6MHc80KmsyJ0a-rSU4WyyiHeMQi2f5iFiQyW-B9Y&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Tim,

A couple of comments:

Q1:

----

Q2:

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Tim Bruylants
Sent: Friday 28 May 2021 12:21
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=PvIKnoy2IRMR_ZyjQGDfXoFAuZZJVu2LEa37CHGliG0&s=gL_91hww2CtfhSCaQrbJTubUO1KecjNtFF_w9WORD5g&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Friday 28 May 2021 10:39
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Vvsa7uFA5z0DWnBSoNEnva_4ij5rbcQGOwLp_i-3z7w&s=aueJioTltY05kxfB21RFOvSQsz8lulToyXQzbctJCvc&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]>
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer

---

From: Tim Bruylants <[email-masked]>
Date: Mon, 31 May 2021 17:05:30 +0000

Ok, super.

Many thanks for your effort and time. I will post the updated draft text today.

Best regards,
Tim

-----Original Message-----
From: Christer Holmberg <[email-masked]> 
Sent: Monday 31 May 2021 18:21
To: Tim Bruylants <[email-masked]>; Thomas Richter <[email-masked]>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

The text looks ok now.

Thanks!

Regards,

Christer

//--- SNIPPET

Best regards,
Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Monday 31 May 2021 16:53
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=tZqhssbSLZEt6ic8JhLpYdfu5QsaeAWiQJL0XQsT6PU&s=PBLOXYk4lL8g5gGRzKae1NDCYZNTxysSKExLTMTUcTI&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Tim,

Regards,

Christer

//--- SNIPPET

Best regards,
Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Monday 31 May 2021 16:10
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Rd7pE4WEooBpksYDJTrap3ir89kSXxdINLNPVYwj-s0&s=VCs6MHc80KmsyJ0a-rSU4WyyiHeMQi2f5iFiQyW-B9Y&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Tim,

A couple of comments:

Q1:

----

Q2:

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Tim Bruylants
Sent: Friday 28 May 2021 12:21
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=PvIKnoy2IRMR_ZyjQGDfXoFAuZZJVu2LEa37CHGliG0&s=gL_91hww2CtfhSCaQrbJTubUO1KecjNtFF_w9WORD5g&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Tim.

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Sent: Friday 28 May 2021 10:39
To: Tim Bruylants <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=Vvsa7uFA5z0DWnBSoNEnva_4ij5rbcQGOwLp_i-3z7w&s=aueJioTltY05kxfB21RFOvSQsz8lulToyXQzbctJCvc&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <[email-masked]>
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <[email-masked]>; Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Cc: Jean-Baptiste Lorent <[email-masked]>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

Best regards,
Tim.

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=gfB4PF-vVBW-HVxcSxCx07LChQ1CSepYN3JnuvPZvhg&s=Wg08i3213bCyP0Yb8Hj5ihpBWj-dlrVnKDdjggOJbqA&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; [email-masked]
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

---

Regards,

Christer