RE: [AVT] T.38 over RTP: RTP Sequence Number

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

Magnus, Vladimir,

> As Colin says RTP timestamps must be set in RTP. However one can make
> them simple to only indicate time of transmission. This would be simpler
> if people hadn't insisted on making it go over the same RTP session as
> audio. FAX isn't audio and it shouldn't be handled the same way as audio
> packets. Thus it should go in its own RTP session where it can be given
> somewhat different treatment. Yes, audio/t38 should in fact be image/t38
> or possibly application/t38.
> 
> Then as I said, stop using RFC 2198 and your timestamp issues mostly
> goes away.

One of the reasons for wanting to use audio/t38 stems from the fact that GWs
are transporting audio signals over IP, transitioning to fax, and then back
to audio mode again.  While fax isn't strictly audio, it arrives in the
audio path, just as DTMF and other audio signals do.  As such, there was the
desire to introduce audio/t38: it provides a pretty seamless means of
transitioning audio and fax.  The alternative is fairly messy signaling
exchanges and/or the allocation of additional UDP ports, just in case one
side initiates a fax transfer.  Lastly, transporting T.38 over RTP in this
way allows us to secure fax using SRTP with no more effort than the
underlying audio stream.

During the discussions held in regard to transporting T.38 over RTP, time
stamps were never regarded as something difficult to deal with.  The DSPs
are constantly sampling the circuit and there is an associated clock running
somewhere.  The fact that the timestamp does not have the same level of
importance for T.38 as they do for audio was not considered a reason to
change that running clock, the logic used to queue packets according to said
clock, or the protocols used to transmit the T.38 over RTP.

While T.38 is an application, it is also audio: one can hear the nasty
screechy noises.  The payload is just the representation of that audio and
there is a running clock associated with it.  Granted, the clock is "looser"
in many respects, but back in 1998 when the ITU decided to use UDPTL, many
argued that it should have used RTP instead.  Now the addition has been made
and (quite likely) a migration toward RTP for the benefits of security.  As
we do this, I would very much like to keep it consistent with RTP and look
at it no differently than an alternative representation of the audio, as we
do for information encoded with RFC 2833.

Paul



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