Re: [MMUSIC] [Technical Errata Reported] RFC3264 (7597)

[Roman Shpount <[e-mail]>]

I think the errata is wrong, and the original text is correct.

All it is saying is that for some format parameters, if the media FORMAT is
present in the answer, then FORMAT PARAMETERS with the same values must be
present in the answer.

For instance, if "a=fmtp:97 mode=20" is present for payload 97 ILBC in the
offer, like this:
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20

Then, if payload 97 is present in the answer, "a=fmtp:97 mode=20" must be
present in the answer as well, like this:
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20

These parameters are not negotiated and part of the payload definition.

Best Regards,
_____________
Roman Shpount


On Fri, Aug 11, 2023 at 5:13 PM Paul Kyzivat <[e-mail]> wrote:

> The problem reported here, and the correction, seem valid to me.
>
>         Thanks,
>         Paul
>
> On 8/11/23 10:59 AM, RFC Errata System wrote:
> > The following errata report has been submitted for RFC3264,
> > "An Offer/Answer Model with Session Description Protocol (SDP)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7597
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Hugo Tunius <[e-mail]>
> >
> > Section: 6.1
> >
> > Original Text
> > -------------
> >     The interpretation of fmtp parameters in an offer depends on the
> >     parameters.  In many cases, those parameters describe specific
> >     configurations of the media format, and should therefore be processed
> >     as the media format value itself would be.  This means that the same
> >     fmtp parameters with the same values MUST be present in the answer if
> >     the media format they describe is present in the answer.  Other fmtp
> >     parameters are more like parameters, for which it is perfectly
> >     acceptable for each agent to use different values.  In that case, the
> >     answer MAY contain fmtp parameters, and those MAY have the same
> >     values as those in the offer, or they MAY be different.  SDP
> >     extensions that define new parameters SHOULD specify the proper
> >     interpretation in offer/answer.
> >
> > Corrected Text
> > --------------
> >     The interpretation of fmtp parameters in an offer depends on the
> >     parameters.  In many cases, those parameters describe specific
> >     configurations of the media format, and should therefore be processed
> >     as the media format value itself would be.  This means that the same
> >     fmtp parameters with the same values MUST be present in the answer if
> >     the media format they describe is present in the offer.  Other fmtp
> >     parameters are more like parameters, for which it is perfectly
> >     acceptable for each agent to use different values.  In that case, the
> >     answer MAY contain fmtp parameters, and those MAY have the same
> >     values as those in the offer, or they MAY be different.  SDP
> >     extensions that define new parameters SHOULD specify the proper
> >     interpretation in offer/answer.
> >
> > Notes
> > -----
> > This indicated that the same fmtp parameters with the same values MUST
> be present in the answer if the media format they describe is present in
> the **answer**.
> >
> > I believe the second instance of **answer** should be replace with
> **offer**, otherwise the quoted text does not makes sense I think.
> >
> > 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
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC3264 (draft-ietf-mmusic-sdp-offer-answer-02)
> > --------------------------------------
> > Title               : An Offer/Answer Model with Session Description
> Protocol (SDP)
> > Publication Date    : June 2002
> > Author(s)           : J. Rosenberg, H. Schulzrinne
> > Category            : PROPOSED STANDARD
> > Source              : Multiparty Multimedia Session Control RAI
> > Area                : Real-time Applications and Infrastructure
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>