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

["Paul E. Jones" <paulej at packetizer.com>]

Magnus,

> Section 4. Rate definition:
> "rate: The RTP timestamp clock rate, which is equal to the sampling
>        rate.  If the T.38 stream is associated with other audio streams
>        in an RTP session, the chosen rate SHOULD match that of the other
>        streams. Otherwise, a rate of 8000 Hz SHOULD be used."
>
> How is the sampling rate defined for fax? It seems a bit strange. Is
> this the octet rate of the transport channel? Please clarify this.

It is strange as defined. What I would prefer is that devices would just use
the same value they use for audio codecs, which is typically 8000.  Since
the usage of this MIME type will be with TDM circuits, it is probably
reasonable to just set it to 8000, though I'd prefer it to match the voice
codec-- perhaps the voice codec rate is 16000.  I'm open to suggestions.

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

> Section 6.
> "T38FaxRateManagement is declarative and the answer must contain the
>     same value." I think the "must" is a "MUST".

OK.  I changed that.

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

> Section 7.
> "  The security considerations discussed in the RTP and SRTP
>     specification and any applicable RTP profile (for example, [11]) are
>     applicable to T.38.  Regarding SRTP configuration, fax payloads
>     SHOULD NOT use an HMAC-SHA1 authentication tag that is shorter than
>     80 bits."
>
> First, SRTP is a RTP profile. So the beginning of the sentence is
> therefore strange. Secondly, I think one should have reference to RTP
> here. Some rewording may be needed to better express what you want.

OK.  I'll remove "and SRTP" and [11] will now point to SRTP.  It was pointed
out that [3] and [11] are the same for some reason.  I'll fix that and also
move SRTP from normative to informative, as I think that's most appropriate.

Paul


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