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

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

Hi Paul,

Sorry for the late comments.

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.

Section 4. Has anybody with better knowledge of T.38 looked at the 
optional parameters? As I haven't looked at the T.38 amendment I don't 
have full understanding of the purpose of the parameters.


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

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

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?

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?


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.

Cheers

Magnus


Paul E. Jones wrote:

> Folks,
>
> Are there any other comments on this draft?  I'd very much like to bring
> it
> to a close in order to register the MIME type.
>
> Thanks,
> Paul


--

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