Magnus,
Currently following attributes have been registered with IANA for att-field (media-level)
for use with image/t38.
T38FaxVersion [ITU-T Rec. T.38 Annex D]
T38maxBitRate [ITU-T Rec. T.38 Annex D]
T38FaxFillBitRemoval [ITU-T Rec. T.38 Annex D]
T38FaxTranscodingMMR [ITU-T Rec. T.38 Annex D]
T38FaxTranscodingJBIG [ITU-T Rec. T.38 Annex D]
T38FaxRateManagement [ITU-T Rec. T.38 Annex D]
T38FaxMaxBuffer [ITU-T Rec. T.38 Annex D]
T38FaxMaxDatagram [ITU-T Rec. T.38 Annex D]
T38FaxUdpEC [ITU-T Rec. T.38 Annex D]
Why not simply reuse them for audio/t38 too instead of registering new ones ? It will simplify handling of SDP for those that currently support image/t38.
Regards,
Satish Mundra
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com]
> Sent: Tuesday, May 25, 2004 10:31 AM
> To: Paul E. Jones; tamura at toda.ricoh.co.jp
> Cc: avt at ietf.org
> 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
>
_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt