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

["Vladimir Ulybin" <[e-mail]>]

Hi,

You are right. The play out concept of RFC 2198 is problematic for fax
relay. Because, T.38 gateways do not play the buffers, but transmit
according to T.30 standard. Generally, the fax rates may be different at
two sides of communication, for example, 2400bps at calling fax side and
14400bps at answer fax side. Also T.30 control signals may have no
synchronization between gateways, but should be synchronized with near
fax machine.

The problem of timestamps is not only our (AudioCodes) problem but is
general for different vendors.

The packet buffer of a gateway receiving T.38 packets has no any time
mapping. The sequence number is the only ID of T.38 packet. Combining
sequence numbers with timestamps in packet recovery module is highly
problematic for interoperability (and from my point of view is wrong for
fax transfer).

Unfortunately, typical gateways do not support a complex protocol RFC
2733. So, we cannot use it as a basic for our implementation.

Thanks,
Vladimir Ulybin


-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]] 
Sent: Wednesday, July 20, 2005 10:49 AM
To: Vladimir Ulybin
Cc: Colin Perkins; Paul E. Jones; [e-mail]
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

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.

Vladimir Ulybin wrote:
> Let consider an option to update the
"draft-jones-avt-audio-t38-05.txt"
> 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.

> 
> I think the problems opened in our discussions 
> - 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
> (non-required by T.38)

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 [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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