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

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

Paul,

First of all, the RFC 3550 allows groups of consecutive packets with the
same timestamp: "Several consecutive RTP packets will have equal
timestamps if they are (logically) generated at once". So, T.38 gateway
should be able to receive correctly such sequences.

Second, simple examples of the case when some T.38 packets may have the
same timestamp:
1. The command "hdlc-fcs-OK-sig-end" may be sent as a single packet or
as two consecutive packets "hdlc-fcs-OK" and "hdlc-sig-end" generated at
once. 
2. The command "hdlc-fcs-OK" followed by "hdlc-data" may be sent as one
complex primary packet or as two consecutive packets generated at once.

And I may give more examples.

I agree with you, that current standards do not make "preference for RFC
2198, RFC 2733, or any other mode". 

It is our local preference of RFC 2198 for T.38-over-RTP, because it is
similar to T.38 UDPTL with secondary fax packets. The problem is in
strict confinements by timestamps which are not used in fax relay, do
not give any gain in reliability, and require so many changes that cause
us not to use RFC 2198 as is for fax.

The "draft-smundra-avt-rtp-red-non-audio-00.txt", by Satish Mundra,
solves all these problems, because it assigns a highest priority to
sequence numbers similarly to T.38 UDPTL and applies sequence number
offsets in RFC 2198 instead of timestamp offsets. This extension of RFC
2198 is simply convertible into T.38 UDPTL and back.

Our questions:
1. Can we use "draft-smundra-avt-rtp-red-non-audio-00.txt"? 
2. Is it possible to include this extension in RFC 2198 or generate new
RFC 2198bis taking into account this draft?

Thanks,
Vladimir Ulybin

-----Original Message-----
From: Paul E. Jones [mailto:[e-mail]] 
Sent: Sunday, July 24, 2005 6:42 PM
To: Vladimir Ulybin; 'Magnus Westerlund'
Cc: 'Colin Perkins'; 'Mundra, Satish'; [e-mail]
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

I must still be missing the point.  If a piece of T.38 information is
placed
into any RTP packet, there is a timestamp.  I don't see why two RTP
packets
would have the same timestamp.  Bits of fax information is relatively
small.
Packets may be received and ordered by those timestamps, as far as I can
see.

Now, if you add RFC 2198 to the picture, it is simply re-sending the
previously transmitted pieces of information.  I don't see how this can
be
confusing, though I certainly agree that the timestamps are probably not
so
important for T.38.

In any case, I'm not arguing against Satish's draft.  It may be a
preferred
mode and, if so, then hopefully it will be progressed further and we
could
certainly have that as an option.  The T.38 spec does not suggest a
preference for RFC 2198, RFC 2733, or any other mode.  They're listed as
options, because they're available options.  If another option is made
available, that could certainly be added, too.

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:[e-mail]]
> Sent: Sunday, July 24, 2005 2:32 AM
> To: Paul E. Jones; Magnus Westerlund
> Cc: Colin Perkins; Mundra, Satish; [e-mail]
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Hi, and sorry for delay.
> 
> Paul,
> 
> The problem is that timestamps cannot help to recover lost T.38
packets,
> and do not have a principle meaning for fax transfer, but as I see
from
> discussion may cause many conflicts of different vendors of gateways
in
> a field of how transmit and to use the timestamps.
> 
> What you wrote about timestamps is right while everything is O.K.
> (behavior is close to audio, no packet loss) or the same vendor
gateways
> communicate T.38 over RTP.
> 
> The following examples show possible conflicts and disadvantages of
> applying timestamps.
> 
> Example 1:
> A T.38 gateway periodically transmits groups of consecutive packets
> having the same timestamp. There may be some reasons of such
> transmission; one is the case when a datagram size of receiving
gateway
> is smaller than working frame size of transmitting gateway; the other
is
> the case when transmitting gateway does not concatenate small fax
> packets into complex packets, so some events are possible at one
moment
> of time, etc.
> Applying timestamps for this case at the stage of receiving from IP
will
> cause an overwriting of one packet by the next packet with zero time
> offset, and as a result the failure of fax transfer even the packet
loss
> is absent.
> 
> Example 2:
> A gateway may receive a correct packet sequence (no violations in
> sequence number) but incorrect timestamp offsets. As well the gateway
> may receive wrong packet sequence but a correct timestamp sequence.
> What is the guarantee that a receiving gateway will handle normally
all
> packets in the first case and enter packet recovery in the second
case?
> If timestamps are mandatory for consideration, then there is no such a
> guarantee.
> 
> We may avoid all conflicts and improve reliability of fax transfer if
> declare that the RTP sequence number is the main ID that is useful for
> T.38 over RTP.
> 
> The concept suggested by Satish satisfies requirements of T.38 fax
> transfer over RTP much better than the regular RFC 2198. It is more
> reliable, better for interoperability, and does not require a too high
> tax for transition from T.38 UDPTL to T.38 over RTP.
> 
> Regards,
> Vladimir Ulybin
> 
> 
> -----Original Message-----
> From: Paul E. Jones [mailto:[e-mail]]
> 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