Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184 (4714)

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Jun 2016 16:04:24 +0200

Hi,

This errata should be handled by the PAYLOAD WG. Please send any 
feedback to them rather than AVTCORE WG.

Cheers

Magnus

Den 2016-06-17 kl. 13:18, skrev RFC Errata System:
> The following errata report has been submitted for RFC6184,
> "RTP Payload Format for H.264 Video".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6184&eid=4714
>
> --------------------------------------
> Type: Technical
> Reported by: IÃ±aki Baz Castillo <[email-masked]>
>
> Section: 8.2.2
>
> Original Text
> -------------
> To simplify the handling and matching of these configurations, the
> same RTP payload type number used in the offer SHOULD also be used
> in the answer, as specified in [8]
>
> [8] points to RFC 3264 "An Offer/Answer Model with the Session
> Description Protocol (SDP)"
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> The above statement is wrong. RFC 3264 does not mandate the same payload
> type in both the offer and the answer. In fact, RFC 3264 section 5.1 states:
>
>    For sendonly RTP streams, the payload type
>    numbers indicate the value of the payload type field in RTP packets
>    the offerer is planning to send for that codec.  For sendrecv RTP
>    streams, the payload type numbers indicate the value of the payload
>    type field the offerer expects to receive, and would prefer to send.
>
>    However, for sendonly and sendrecv streams, the answer might indicate
>    different payload type numbers for the same codecs, in which case,
>    the offerer MUST send with the payload type numbers from the answer.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6184 (draft-ietf-avt-rtp-rfc3984bis-12)
> --------------------------------------
> Title               : RTP Payload Format for H.264 Video
> Publication Date    : May 2011
> Author(s)           : Y.-K. Wang, R. Even, T. Kristensen, R. Jesup
> Category            : PROPOSED STANDARD
> Source              : Audio/Video Transport
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jun 2016 22:15:49 +0200

2016-06-19 15:47 GMT+02:00 Mo Zanaty (mzanaty) <[email-masked]>:
> Matching H.264 payloads based on configuration parameters is often error prone and can lead to interop issues. Using the same payload type number in the answer for the same configuration offered does simplify things and avoids some interop issues. There are cases where this is not possible and asymmetric payload type numbers are necessary. So the original text with SHOULD strength seems appropriate.

same RTP payload type number used in the offer SHOULD also be used
in the answer, as specified in RFC 3364.

But that is not true. RFC 3264 does not say that "the same RTP payload
type number used in the offer SHOULD also be used in the answer".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 21 Jun 2016 00:45:24 +0300

Hi,
>From RFC3264 section 6.1
"In the case of RTP, if a particular codec was referenced with a
   specific payload type number in the offer, that same payload type
   number SHOULD be used for that codec in the answer."

> -----Original Message-----
> From: payload [mailto:[email-masked]] On Behalf Of I?aki Baz
> Castillo
> Sent: Monday, June 20, 2016 11:16 PM
> To: [email-masked]
> Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC6184
> (4714)
> 
> > Matching H.264 payloads based on configuration parameters is often error
> prone and can lead to interop issues. Using the same payload type number in
> the answer for the same configuration offered does simplify things and
> avoids some interop issues. There are cases where this is not possible and
> asymmetric payload type numbers are necessary. So the original text with
> SHOULD strength seems appropriate.
> 
> same RTP payload type number used in the offer SHOULD also be used in the
> answer, as specified in RFC 3364.
> 
> But that is not true. RFC 3264 does not say that "the same RTP payload type
> number used in the offer SHOULD also be used in the answer".
> 
> 
> --
> Iñaki Baz Castillo
> <[email-masked]>
> 
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jun 2016 23:55:50 +0200

>    number SHOULD be used for that codec in the answer."

Definitely I missed that. However life would be easier with a MUST in there.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Jun 2016 09:56:34 +0200

> Definitely I missed that. However life would be easier with a MUST in there.

I don't disagree that it would be easier. However, that is not what 
RFC3264 says, so the only way of changing RFC3264. Which, is quite some 
work.

So, is the conclusion that this errata also can be rejected?

I think so, I also didn't find the text in 6.1, but I have to say that I 
didn't look widely. With that text, there are no actual error in the text.

Cheers

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Tue, 21 Jun 2016 12:05:02 +0300

Hi,
>From section 5.1 of RFC3264

" Different payload type numbers may be needed in each direction
      because of interoperability concerns with H.323."

I assume this is one reason for the SHOULD

Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, June 21, 2016 10:57 AM
> To: Iñaki Baz Castillo; Roni Even
> Cc: [email-masked]
> I think so, I also didn't find the text in 6.1, but I have to say that I didn't look
> widely. With that text, there are no actual error in the text.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Jun 2016 15:48:45 +0200

Hi,

I actually wrote a longer email yesterday that failed to be sent.

I think the text written in the RFC is unchanged from RFC 3984 and as it 
is part of the O/A specification, thus I most likely wrote it. Therefore 
I would like to provide my view of how it should be interpreted.

Yes, I am pretty certain that it is to reference the should you pointed 
to. But that was not the only reason as you can se below. I do claim 
that intention was to avoid violating RFC 3264, but provide stricter 
limitations within the RFC 3264 rules to address the identification issue.

As quoted from RFC3264 it says:

What I want to stress here is "the answer might", which is equivalent to 
say. The Answer MAY use different PT numbers.

Due to the matching issues with the three different important 
parameters, it is a benefit to not change the values. Therefore we 
wanted to strongly recommend the usage of symmetric PT values and echoed 
the SHOULD. However, SHOULD clearly allows for using different values in 
the answer, following RFC3264. And to avoid issues I will note this 
payload format does add a restriction of not re-using the numbers from 
the offer:

       To simplify the handling and matching of these configurations, the
       same RTP payload type number used in the offer SHOULD also be used
       in the answer, as specified in [8].  An answer MUST NOT contain a
       payload type number used in the offer unless the configuration is
       the same as in the offer.

So that is the motivation.

But my point with the previous email was really to say that I think we 
can conclude that the Errata can be rejected.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2016 15:51:17 +0200

2016-06-21 15:48 GMT+02:00 Magnus Westerlund <[email-masked]>:
> Due to the matching issues with the three different important parameters, it
> is a benefit to not change the values. Therefore we wanted to strongly
> recommend the usage of symmetric PT values and echoed the SHOULD. However,
> SHOULD clearly allows for using different values in the answer, following
> RFC3264. And to avoid issues I will note this payload format does add a
> restriction of not re-using the numbers from the offer:
>
> But my point with the previous email was really to say that I think we can
> conclude that the Errata can be rejected.
>
> Cheers

Thanks a lot, Magnus. Very valuable rationale.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Jun 2016 13:31:05 -0500

I rejected the errata report.

Thanks!

Ben.

On 21 Jun 2016, at 8:48, Magnus Westerlund wrote:

> I think the text written in the RFC is unchanged from RFC 3984 and as 
> it is part of the O/A specification, thus I most likely wrote it. 
> Therefore I would like to provide my view of how it should be 
> interpreted.
>
> Yes, I am pretty certain that it is to reference the should you 
> pointed to. But that was not the only reason as you can se below. I do 
> claim that intention was to avoid violating RFC 3264, but provide 
> stricter limitations within the RFC 3264 rules to address the 
> identification issue.
>
> What I want to stress here is "the answer might", which is equivalent 
> to say. The Answer MAY use different PT numbers.
>
> wanted to strongly recommend the usage of symmetric PT values and 
> echoed the SHOULD. However, SHOULD clearly allows for using different 
> values in the answer, following RFC3264. And to avoid issues I will 
> note this payload format does add a restriction of not re-using the 
> numbers from the offer:
>