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

From: "Vladimir Ulybin" <[email-masked]>
Date: Tue, 19 Jul 2005 17:45:50 +0300

Colin,

I think that the use of timestamps together with sequence numbers for
building T.38 packet recovery buffer is not a good way. For T.38
INDICATOR packets it is acceptable but for DATA packets this way may
cause a lot of problems for packet recovery during data transfer.

It is much easy and reliable to use RTP sequence number as the only base
for ordering T.38 packets arrived over RTP. In this case, timestamps of
redundant payloads may be ignored without any problems.

Let consider an option to update the "draft-jones-avt-audio-t38-05.txt"
or write a new draft for T.38 over RTP.

I think the problems opened in our discussions 
- repetition of T.38 packets and 
- excessive complexity of T.38 over RTP caused by timestamps
(non-required by T.38)
are general for different vendors.

Regards,
Vladimir Ulybin

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2005 2:07 PM
To: Vladimir Ulybin
Cc: Paul E. Jones; [email-masked]
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

On 19 Jul 2005, at 07:40, Vladimir Ulybin wrote:
> 1. Zero is a simplest solution. The RFC 3550 allow the same time stamp
> for several consecutive packets. So, when these packets will be
> transmitted as redundant one relative to the other, the time  
> offsets per
> RFC 2198 will be zero. It means that receiving gateway should handle
> correctly zero time offsets in RFC 2198 headers.

No, since it will treat the data as being a redundant copy of the  
packet in which it is sent. If you use an offset of zero, there's no  
way to correctly place the data at the right time instant in the  
playout buffer.

> 2. The computation of redundant packet time offset relative to primary
> packet can be applied for synchronous operation like audio or
> t4-non-ECM-data having a fixed time interval between packets. But, for
> asynchronous packet stream, which is typical for T.30 control and ECM
> fax, such approach cannot be used.

Correct - this is why RFC 2198 has an explicit timestamp for the  
redundancy offset.

> Why I opened this issue?
>
> Assume a T.38 module of DSP/gateway which delivers the T.38 UDPTL
> packets ready for transmission to IP. To enable new feature of T.38  
> over
> RTP, it is easy to convert T.38 UDPTL into RFC 2198 at output of
> DSP/gateway. The obstacle is in time stamp offsets of redundant  
> packets.
> We all (fax engineers) know that these offsets are not required at  
> T.38
> packet receivers. But accurate transmission of those per RFC 2198
> requires deep re-writing of working and verified module(s) plus
> additional allocation of RedundancyLevel*NofChannels timestamps.

Correct - this is required for robust operation over an unreliable  
packet network that may disrupt media timing.

There are two cases:

1) There is a constant mapping from sequence number to timestamp. In  
this case, you can trivially calculate the timestamp and need no  
extra storage. The media timing can be reconstructed using either the  
sequence number or timestamp, and transporting both is essentially a  
waste of bandwidth for this application. In this case, you treat the  
extra bits on the wire as an "RTP tax" needed for interoperability,  
but don't need to store the extra data in the gateway.

2) There is not a constant mapping from sequence number to timestamp.  
This case requires you to store the extra timestamps for inclusion in  
RFC 2198 redundancy headers, however that extra information is  
required by the receiver to manage a playout buffer, since a playout  
buffer managed by sequence number only is not sufficient to  
reconstruct media timing.

Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Jul 2005 16:01:27 +0100

Vladimir,

Use of timestamps to reconstruct media timing is an essential feature  
of RTP. We will not standardise an RTP payload format which does not  
use them, since that would be incompatible with the rest of RTP, and  
would break the playout model used by RTP applications.  RTP is a  
general purpose transport protocol for real-time traffic -- it is not  
appropriate to optimise it for this niche application, at the expense  
incompatibility with other use cases.

If you do not wish to use timestamps in your application, I suggest  
you use T.38 over UDPTL instead of over RTP. When implementing T.38  
over RTP, using timestamps is mandatory (as with all other RTP  
payload formats).

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jul 2005 09:48:42 +0200

Hi,

I think a lot of the problems you are having is based on the fact you 
are using RFC 2198 for something it wasn't designed for. It was designed 
and works as intended for audio payloads that relies on a single data 
block (ADU) per timestamp. The formats that fulfill this can for 
synchronization and detecting duplicates rely solely on timestamp. It 
uses the RTP timestamp primarily to detect when discontinuous 
transmissions occur. RFC 2198 doesn't have full sequence number recovery 
due to the fact that it wasn't needed for all the audio payloads one was 
considering to use. Also the solution RFC 2198 employs aren't suitable 
at all when the payloads become larger than half of the MTU.

If you want sequence number recovery, less hassle with timestamps and 
so: Use RFC 2733 FEC resolves these issue. Or rather the updated version 
as RFC 2733 has some issues. Unfortunately we haven't finished this 
update yet, but we are getting close.

> or write a new draft for T.38 over RTP.

This is an ITU defined RTP payload format. I agree that it has issues 
and some of them could have been avoided if ITU had involved AVT in the 
loop earlier when it was under proposal. However it is ITU that has 
change control of it.

> - repetition of T.38 packets and 

If you are using RTP you have certain rules to follow. These involve the 
fact that packets can't be repeated using the same RTP sequence number. 
This requires solution like the RTP Retransmission format or the use of 
2733 FEC.

> - excessive complexity of T.38 over RTP caused by timestamps

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.

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: [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 20 Jul 2005 11:57:43 -0400

Magnus, Vladimir,

> Then as I said, stop using RFC 2198 and your timestamp issues mostly

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