[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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