[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Magnus,

I completely agree, but that it what's in T.38.  I'd be very much in favor
of shortening those, but it would require changes to T.38.  We could propose
that to the ITU.  While I'm not wanting cryptic names, those names like
"T38FaxTranscodingJBIG" are really too big.  This name was picked long ago
and nobody proposed changing it :-(

Paul

----- Original Message ----- 
From: "Magnus Westerlund" <magnus.westerlund at ericsson.com>
To: "Paul E. Jones" <paulej at packetizer.com>; <tamura at toda.ricoh.co.jp>
Cc: <avt at ietf.org>
Sent: Tuesday, May 25, 2004 10:31 AM
Subject: Re: [AVT] Re: draft-jones-avt-audio-t38-04.txt


> Hi again,
>
> I have one more comment:
>
> - There is no need to have T38 in all the parameter names, this is
> scoped by the media type itself.
>
> Cheers
>
> Magnus
>
>
> Magnus Westerlund wrote:
>
> > 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