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

["Oren Peleg" <[e-mail]>]

I would like to suggest the following:

Since Timestamp is profile specific, the T.38 RTP profile draft
(currently draft-jones-avt-audio-t38-05.txt) will add a special case of
Timestamp manipulation which will be used for redundant control packet
transmission (similar to the End packet of the RFC 2833 event). At this
special case the timestamp that will be used at the redundant packets
will be the same as the timestamp of the original packet. The number of
redundant packets will be determined via SDP using a special parameter.

Oren P.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Paul E. Jones
Sent: Wednesday, July 20, 2005 7:06 PM
To: Vladimir Ulybin; 'Magnus Westerlund'
Cc: 'Colin Perkins'; [e-mail]
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

Forget RFC 2198 for a moment.  You're going to sample the audio, you
will
extract T.30 information from that audio, you will form an RTP packet
using
the time from the clock that is necessarily running.

As Packets arrive, you can do what you want with the timestamps, but
they
can certainly be used for ordering packets if you want or they can be
largely ignored.

Now, if you add RFC 2198 to the picture, you are simply re-transmitting
the
media from a previous packet in the current packet.  The timestamp was
in
the previous packet and the current packet simply has an offset to it.
When
it arrives, you can determine the order of packets.  Isn't that all you
need?

Honestly, I do not see why this is causing such a problem.  I will not
disagree that an alternative (e.g., UDPTL) might be more fitting as it
does
not have timestamps, but as Colin pointing out: it's an RTP tax.  But,
you
get benefits with that tax, including security, RTCP, RTCP-XR, etc.

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:[e-mail]]
> Sent: Wednesday, July 20, 2005 5:51 AM
> To: Magnus Westerlund
> Cc: Colin Perkins; Paul E. Jones; [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