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

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

Paul E. Jones wrote:
> Magnus,
>
>
> > I can't find anywhere that you define the RTP TS field. The timestamp
> > must also be defined by a RTP payload format. If you do not use it for
> > any purpose, then you should at least define it as being the timestamp
> > at the time of the sending so that the RTCP jitter measurements work.
>
>
> I suppose that it was felt that it did not need explanation.  The
> timestamp
> field will be adjusted according to the clockrate specified in SDP.  I
> cannot say why it was left out, but it is something that should be
> documented in T.38.

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:

      The timestamp reflects the sampling instant of the first octet in
      the RTP data packet.  The sampling instant MUST be derived from a
      clock that increments monotonically and linearly in time to allow
      synchronization and jitter calculations (see Section 6.4.1).  The
      resolution of the clock MUST be sufficient for the desired
      synchronization accuracy and for measuring packet arrival jitter
      (one tick per video frame is typically not sufficient).  The clock
      frequency is dependent on the format of data carried as payload
      and is specified statically in the profile or payload format
      specification that defines the format, or MAY be specified
      dynamically for payload formats defined through non-RTP means.  If
      RTP packets are generated periodically, the nominal sampling
      instant as determined from the sampling clock is to be used, not a
      reading of the system clock.  As an example, for fixed-rate audio
      the timestamp clock would likely increment by one for each
      sampling period.  If an audio application reads blocks covering
      160 sampling periods from the input device, the timestamp would be
      increased by 160 for each such block, regardless of whether the
      block is transmitted in a packet or dropped as silent.

So if you could try to write out a definition for the RTP TS.


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


Cheers

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