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

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

Paul,

At first, I do not subscribe AVT-ML.
If not circulated there, please do it instead of me.

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

> > Section 6. Offer/Answer: I think I understand how you intended this to
> > work. I think it can benefit from further review and discussion.
> >
> > The draft contains three different policies for different parameters:
> >
> > 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.
> >
> > Case A is a payload format configuration parameter. Although I don't
> > fully why it needs to be set symmetric. Please clarify why rate must be
> > the same in both direction. Or is this simple to ensure that one can
> > actually determine what PTs actually was in the offer and which are
> > actually answered?
> 
> Rate really doesn't matter.  Quite simply, I just wanted to say something
> concrete.  We could say that a device can set it to whatever it wants.  It
> will not impact T.38.
> 
> > I think that case B and C are in fact the same under Offer/Answer. A
> > declarative parameter in a recv declaration, determines what the
> > receiver accepts to receive. Thus the sender is restricted to conform to
> > them when sending. This is to my understanding the best negotiation one
> > can ever perform within offer/answer. Or does your negotiated parameters
> > actually have to have the same values on both sides?
> 
> The values could be different.  This allows the two devices to negotiate
> capabilities.  T.38 is bi-directional and the two devices need to settle on
> a common set of capabilities.  I have tried to align the text in this
> section with what T.38 says, but I agree with your statement above: it could
> benefit from review from others who are familiar with T.38 capability
> negotiation.

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.

Best regards,
--
Hiroshi Tamura

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