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

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

Magnus,

> It is not clear what you mean with adjusted. The RTP timestamp does need
> to be specified by the RTP payload format. From RFC 3550, section 5.1:
>
<snip>
>
> So if you could try to write out a definition for the RTP TS.

I believe this and other issues related to parameters and the offer/answer
model needs to go back into the T.38 spec.  The other fields, as you pointed
out, are defined there.  This draft is intended only to serve as the basis
for registering the MIME type for audio/t38.

I would even be favorable to removing the description of all of the
parameters and, again, just referencing the appropriate section(s) in T.38.
I feel like we're trying to solve two problems here, but the real work needs
to be done in T.38.

> > OK.  How is this?
> >    rate: The RTP timestamp clock rate, which SHOULD be 8000Hz by
> >    default. The clock frequency MAY be set to any value, but SHOULD
> >    be set to the same value as for any audio packets in the same RTP
> >    stream in order to avoid RTP timestamp rate switching.
> >
>
> I think it looks basically okay. I think the ", which SHOULD be 8kHz by
> default." is a bit strange. There are two different cases of default
> values.
> A. The recommendation on a clock rate that is used. I think the first
> sentence is okay, if you remove the "by default"
> B. The value that is used if the "rate" parameter is not specified.
> However as you have the "rate" parameter in the Required part.
> So I think a good paragraph would be:
>
>      rate: The RTP timestamp clock rate, is RECOMMENDED to 8000Hz. The
>      clock frequency MAY be set to any value, but SHOULD
>      be set to the same value as for any audio packets in the same RTP
>      stream in order to avoid RTP timestamp rate switching.

OK.. very good.  I've made the suggest change.

Now, what do we do about parameters, offer/answer, and the TS issue?  Is it
a requirement that we include all of these optional parameters?  Rate would
need to be documented here, as I do not believe it is documented in T.38.
However, the T.38-specific attributes that would appear on the a= line are
documented in T.38.  It became clear to me as I was working on this that
T.38 needed more description of how these parameters should be used.  I
would prefer to not try to solve that problem in two places and just raise
this as an issue to the ITU to fix.

Paul


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