Re: [AVT] Re: draft-jones-avt-audio-t38-04.txt

[Hiroshi Tamura <tamura at toda.ricoh.co.jp>]

Magnus,

Thanks for your explanation.

> >>>Section 5. "The parameters are provided as a semi-colon
> >>>    separated list of "parameter" or "parameter=value" pairs using the
> >>>    "a=fmtp" parameter defined in SDP [2]; the "parameter" form is used
> >>>    for boolean values, where presence equals "true" and absence "false"."
> >>>
> >>>I would recommend that parameter=value form is always used. This is in
> >>>line with the syntax defined in RFC 2045. Thus the Boolean operators
> >>>should be defined like "parameter=true" or "parameter=1".
> >>
> >>Presence or absence was what was written in T.38 Amendment 2.  The text
> >>states:
> >>    Those parameters are supplied in a semi-colon separated list
> >>    of "parameter" or "parameter=value" pairs using the "a=fmtp"
> >>    parameter defined in SDP; the "parameter" form is used for
> >>    boolean values, where presence equals "true" and absence "false".
> >>
> >>I have no strong preference either way, but I don't see the connection to
> >>MIME in this case.  Where does it say in SDP that MIME syntax should be
> >>applied to an a= line?  (I've seen people do this before, but I have not
> >>seen the text that suggests this as preferred or correct.)
> > 
> > 
> > Changing T.38 description would cause an interoperability issue.
> > 
> > The main purpose of this document (draft-jones-avt-audio-t38-04.txt) is
> > the registaration of MIME sub-type.
> > 
> > If there are things that should be changed or modified in T.38,
> > please submit proposals and discuss them in ITU-T SG16.
> > 
> 
> The problem is that the text on the syntax for the a=fmtp line is not 
> super clear. The a=fmtp line follows the a="attribute" syntax of SDP 
> which allows any bytestring to be include.

<snip>

> This indicates to me that we shall follow the syntax for parameters 
> defined in RFC 2045 in the MIME registration itself. And that it in the 
> "a=fmtp" line should be represented as semicolon separated list of 
> "parameter=value"'s. However it is allowed but not recommend for a media 
> type to define its own mapping.
> 
> So you are in fact not in syntax violation with the proposed mapping. 
> However it is not the recommended way. It may cause some extra 
> implementation effort.

I understand what you are saying.

At first, I want to say,
although I am familiar with T.38 to some extent, I am not the editor of
T.38 amd2, which has just been recommended. 
Also, I am not the man who proposed to introduce SIP/SDP call-setup in T.38.

When SIP/SDP call-setup was included in T.38 in Nov 2000, T.38 Annex D.2.3
already had the following sentences:
"The RFC 2327 Session Description Protocol (SDP) provides mechanisms for
 describing sessions for SIP. However, new attributes (section 6 of SDP) are
 required to support ITU-T Rec. T.38. Specifically, the following options are
 registered with IANA as valid att-field and att-value values per the procedure
 noted in Appendix B of SDP (RFC 2327). Note that options without values are
 boolean - their presence indicates that they are valid for the session."

They still exist. I believe the editor of T.38 amd2 made the texts that
Paul quoted, considering the above.

I would like to say general things from the standard point of view.
We already have products in our market. The change in Annex D.2.3 could cause
interoperability issues.

However, regarding T.38 amd2, it is very new.
If we could deal with this issue very soon, it might not cause a new one.
In order to do that, you need to propose a corrigendum to ITU-T.

> >>>A. Declarative parameters where the answers is not allowed to change it
> >>>in the answer.
> >>>
> >>>B. parameters that are negotiated.
> >>>
> >>>C. Declarative parameters that are allowed to be set independently.

<snip>

> > I think the orignal texts here are enough. Also, I have to say,
> > unfortunately, T.38 does not describe the negotiation mechanism of
> > the parameters. I believe something should be done in T.38.
> > 
> > One more thing, regarding case B.
> > For example, support of MMR and JBIG is not mandatory in G3 fax (T.30).
> > These negotiation parameters are exchanged in DIS/DCS, i.e., T.30 phase.
> > The phase goes after SIP call-setup. The ending G3 fax does not support MMR,
> > although Gateways support it. In this case, the gateways may transform data
> > to MMR.
> > 
> 
> To my understanding of the Offer/Answer model, you will have to change 
> all parameters that you need to have mutual agreement between both 
> peers, to be defined as A. The only negotiation you can do in regards to 
> them is to offer multiple combinations of the parameters in different 
> payload types, and listed in decreasing order of preference. Thus 
> allowing the answerer to remove all combinations that it can't support.

Some negotiated parameters written in the I-D do not offer multiple choices.
I am sorry I do not understand the Offer/Answer model completely.
Some of them may not be applied to the model. Is it true?

Best regards,
--
Hiroshi Tamura

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt