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

[Christer Holmberg <[e-mail]>]

Hi,

 

I agree with Roman.

 

Also, the suggested new text is confusing:

 

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

 

You never have to add fmtp parameters to an answer just because a media format is present in the offer. It is only if you accept the media format in the answer that you might have to include fmtp parameters, for the accepted media format, in the answer. And, sometimes those fmtp parameters must have the same values, as indicated in the original text.

 

Regards,

 

Christer

 

From: mmusic <[e-mail]> On Behalf Of Roman Shpount
Sent: Saturday, 12 August 2023 1.31
To: Paul Kyzivat <[e-mail]>
Cc: [e-mail]
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (7597)

 

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] <mailto:[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] <mailto:[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] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/mmusic