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

From: "Vladimir Ulybin" <[email-masked]>
Date: Mon, 18 Jul 2005 09:38:21 +0300

Paul,

The term "basic configuration" for RFC 3550 plus redundancy per RFC 2198
should be replaced on "typical configuration". I assumed the same as
you, that most gateways support this.

As for the time stamps for redundant fax packets, the theory case given
is not relevant for T.38.
1. The ITU-T T.38 itself does not uses any time stamps both for
redundant and primary packets. T.38 gateways transmitting fax signals
should care about compatibility with T.30 but not with time stamps
received from a remote gateway. The only important things are the
content of fax packets and the real-time of receiving.
2. We say about new feature of T.38 over RTP which is to be added to
existing (==working) T.38 UDPTL.

My suggestion is to reserve (zero) time stamps for redundant packets
when sending T.38 over RTP.

Regards,
Vladimir Ulybin

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Monday, July 18, 2005 6:17 AM
To: Vladimir Ulybin; 'Colin Perkins'
Cc: [email-masked]
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

T.38 (2004) addresses the transport of T.38 over RTP and does not say
that
RFC 2198 is the basic configuration.  Both RFC 2198 and RFC 2733 are
suggested as possible choices for protecting the media stream.

While T.38 data may not have the same kind of timing as, say, an audio
codec, the fact that it is placed into a media stream means it needs a
clock.  The draft I wrote suggests the use of an 8000hz clock or one
that
matches the primary audio codec.  In any case, the timing information
would
be meaningful.  In theory, one would not play out packets so quickly
that a
redundant piece of information received one or two packets later would
be
too old to be useful.

In any case, you are certainly free to use RFC 2198 or RFC 2733.  Most
people I've talked to prefer RFC 2198, simply because of the
computational
complexity introduced by RFC 2733.  With that said, I've certainly not
talked to every GW maker in the world ;-)

Paul

> -----Original Message-----
> From: Vladimir Ulybin [mailto:[email-masked]]
> Sent: Sunday, July 17, 2005 2:06 AM
> To: Paul E. Jones; Colin Perkins
> Cc: [email-masked]
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Paul,
> 
> Finally, for resending of T.38 packets over RTP, Colin suggested us to
> use FEC per RFC 2733 or new retransmission protocol. Both ways present
> optional features which may not be supported by gateways.
> 
> Basic configuration for T.38 over RTP is a basic RFC 3550 plus
> redundancy per RFC 2198.
> 
> This configuration has limited capabilities vs. T.38 UDPTL to improve
> reliability of fax transport, if gateways do not resend (==duplicate)
> fax packets, refer to explanation that I done in previous e-mails.
> 
> The other open issue for T.38 over RTP is the time stamps for
redundant
> fax packets. The T.38 implementations are not dependant on time
stamps.
> So, the time offset fields required per RFC 2198 for redundant fax
> payloads are absolutely usefulness. There is no problem to ignore
these
> fields on receiving, but transmitting accurate offsets requires
> additional resources in gateways.
> 
> Regards,
> Vladimir Ulybin
> 
> -----Original Message-----
> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Sunday, July 17, 2005 1:53 AM
> To: Vladimir Ulybin; 'Colin Perkins'
> Cc: [email-masked]
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Vladimir,
> 
> I apologize that I missed much of this discussion while I was
traveling.
> 
> The bottom line on this, though, is that T.38 over RTP should use
> whatever
> mechanisms are defined in the IETF for redundancy or FEC.  This might
> include RFC 2198, RFC 2733, or other tools that come along.  It's also
> expected that this will be the means by which security is provided for
> fax
> (SRTP).
> 
> Is there a problem you see that is specific to fax?  Timing is
certainly
> an
> issue, but the delay should be no worse than UDPTL.  However, if there
> is a
> flaw somewhere, we should fix it sooner than later.
> 
> Paul
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> > Vladimir Ulybin
> > Sent: Monday, July 04, 2005 5:59 AM
> > To: Colin Perkins
> > Cc: [email-masked]
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > On my suggestion from 3 Jul 2005, at 15:44:
> > >> I think we may use for RTP sequence number the same rules of
> > >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every
new
> > >> primary IFP packet and do not increment SN if a fax packet is
> > >> repeated.
> >
> > Colin Perkins wrote:
> > > Not if you wish to be compatible with RTP: RTP requires the
sequence
> > > numbers to be unique.
> >
> > 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550
as
> a
> > basic RTP protocol to be used for encapsulation.
> > 2. The RFC 3550 does not define the packet repetition, also does not
> use
> > SHOULD or MUST for sequence number advances (in contrast to RFC
> 2833bis
> > were the MUST is used).
> > 3. Different RTP sequence numbers assigned to the same fax signal
> state
> > or the same binary data cannot be considered as unique.
> > 4. I try to find a more reliable transport for T.38 over RTP. The
> blind
> > assignment of new sequence numbers for ALL packets is full
compatible
> > with RFC 3550, but highly reduces the reliability of fax relay,
> because
> > gateways may not repeat fax packets.
> > 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> > only problem of packet repetition with the same SN is a distorted
RTCP
> > statistics. In absence of other ways this violation is better than
to
> > loose connection during fax relay.
> >
> > Regards,
> > Vladimir Ulybin
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/avt

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Jul 2005 12:27:51 +0100

> when sending T.38 over RTP.

Which will break any conformant RTP implementation...  The timestamps  
may well be redundant for this particular media format, but they are  
trivial to calculate and required by RTP.

We well understand that, in many cases, it's possible to develop a  
more optimised format for a particular media type or application  
scenario. The value of the RTP standard comes not because it's always  
the optimal solution, but because it's an acceptable solution which  
everyone can implement, to gain economies of scale and increased  
interoperability across a range of problem domains. Adjustments of  
the type you suggest are often locally beneficial, but frequently  
harmful to overall interoperability and implementation complexity.

Colin

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 18 Jul 2005 16:02:27 -0400

Vladimir,

Why use 0? Why not use the relevant offset from the clock time used in the
primary payload, as is done for audio?  Consistency is as important as many
other things.

Paul

> Sent: Monday, July 18, 2005 2:38 AM