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

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

Satish,

Sorry for response delay. 

>From my point of view, the "draft-smundra-avt-rtp-red-non-audio-00.txt"
may be considered as a basic concept of redundancy transmission for
T.38-over-RTP. For T.38 applications, the timestamps "lose their
significance and sequence numbers as alone are of interest".

What is the status of this draft?

I have two main comments:

1. According to T.38, the marker bits of RFC 3550 are not used for T.38
over RTP. So, I suggest to declare the 'M' bit field in RFC 2198 as
optional for non-T.38 applications and reserved (==zero) for T.38.

2. The parameter 'level' is not enough for fax transfer. Usually, T.30
control packets (T.30 INDICATORs and T.30 control channel DATA) are
transmitted at one level (for example, 3), while TCF/image DATA packets
are transferred at the same or lower level (for example, 1). So, I
suggest one more parameter 'levelT30' for T.30 control packets. If
'levelT30' is not specified, the parameter 'level' is applied both for
T.30 control and TCF/image packets.

Some minor comments to the text declaring the need of new interpretation
of RFC 2198 for non-audio applications may be added if you are ready to
develop new version of the draft. 

Regards,
Vladimir Ulybin

-----Original Message-----
From: Mundra, Satish [mailto:[e-mail]] 
Sent: Wednesday, July 20, 2005 5:33 PM
To: Vladimir Ulybin
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Hi Vladimir,

I had submitted a draft(see attached) some time back addressing the need
for modified(simplified) redundancy mechanism 
for non-audio data based on RTP sequence number alone.  

There was not much interest/support from workgroup so this draft
expired.

RFC4103 adopted 2198 for use in text conversations by specifying some
additional rules for transmitter and receiver to overcome 
some of the issues that you identify when one makes use of
audio-redundancy mechanism for non-audio data. 



Regards,

Satish   

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Vladimir Ulybin
> Sent: Wednesday, July 20, 2005 5:51 AM
> To: Magnus Westerlund
> Cc: Paul E. Jones; Colin Perkins; [e-mail]
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> 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
> 

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