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