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

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi Hiroshi,

Some comments on your reply

Hiroshi Tamura wrote:

[snip]

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

However RFC 3555 defines how RTP payload are registered as MIME types 
and also how to map it to SDP. This document contains the following 
paragraphs:

Section 3 of RFC 3555:


  "The representation of a MIME media type is specified in the syntax of
   the Content-Type header field in RFC 2045 [6] as follows:

      type "/" subtype  *(";" parameter)

   Parameters may be required for a particular type or subtype or they
   may be optional.  For media types which represent RTP payload
   formats, the parameters "rate", "channels", "ptime", and "maxptime"
   have general definitions (given above) that may apply across types
   and subtypes.  The format for a parameter is specified in RFC 2045 as

      attribute "=" value

   where attribute is the parameter name and the permissible values are
   specified for each parameter.  The value may need to be a quoted
   string if it contains any of the special characters listed in RFC
   2045."

And

     "o  Any payload-format-specific parameters go in the SDP "a=fmtp"
         attribute.  The set of allowed parameters is defined by the RFC
         that specifies the payload format and MUST NOT be extended by
         the MIME subtype registration without a corresponding revision
         of the payload format specification.  The format and syntax of
         these parameters may also be defined by the payload format
         specification, but it is suggested that the parameters be
         copied directly from the MIME media type string as a semicolon
         separated list of parameter=value pairs.  For payload formats
         that specify some other syntax for the fmtp parameters, the
         registration of that payload format as a MIME subtype must
         specify what the parameters are in MIME format and how to map
         them to the SDP "a=fmtp" attribute.  See Section 4.1.21 for an
         example."

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.

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

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.

So you will need to reformulate the parameters that has been defined as 
being negotiated.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com


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