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

From: Colin Perkins <[email-masked]>
Date: Sat, 2 Jul 2005 16:18:23 +0100

Vladimir,

You might review draft-ietf-avt-rtp-retransmission-11.txt, which  
discusses this issue and proposes an RTP-friendly approach to  
retransmission.

Colin

On 30 Jun 2005, at 09:31, Vladimir Ulybin wrote:
> In T.38 UDPTL protocol, every primary fax packet has a unique  
> sequence number.
>
> To immune a fax session of packet loss in the network, gateways use  
> redundancy and packet retransmissions.
>
> When a T.38 UDPTL packet is retransmitted, the sequence number is  
> unchanged.
>
> In T.38 over RTP protocol, the RTP sequence number must be used.  
> The RFC 3550 defines the sequence number as monotonically  
> incremented by one for every packet sent to the network.
>
>
> If RTP sequence number is incremented per every retransmission,  
> then the retransmission of fax packets containing T.38 DATA packets  
> in primary or redundant RTP payloads is problematic because the T. 
> 30 data may be re-modulated incorrectly.
>
> The problem exists also for retransmission of T.38 INDICATOR  
> packets: If a primary T.38 INDICATOR is lost, the retransmitted T. 
> 38 INDICATOR arrived with a gap in RTP sequence number may be  
> delayed in packet recovery module, so the start of corresponding  
> fax signal may be delayed when it should not.
>
>
> The obvious solution is to increment RTP sequence number  
> conditionally by the same way as in T.38 UDPTL:
>
> The RTP sequence number is to be incremented per every new primary  
> fax packet, but remains unchanged if RTP packet transfers a  
> retransmitted primary fax packet.
>
>
> The questions:
>
> Does this conflict with some RTP protocol?
>
> What kind of interoperability problems (excluding RTCP statistics  
> of packet loss) may exist?
>
>
> Thanks,
>
> Vladimir Ulybin
>
> AudioCodes Ltd.
>
>
>
> _______________________________________________
> 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: "Vladimir Ulybin" <[email-masked]>
Date: Mon, 4 Jul 2005 11:32:19 +0300

Thanks.

Magnus Westerlund wrote:
> The first one is to use FEC to provide the packet repetition... 
> The second is actually to use that Retransmission RTP payload format
for 
> repetitions...

But,
1. Not all gateways support FEC.
2. The RTP payload retransmission is under consideration (draft
document) and is not supported by all gateways. Also, the using it may
give additional interoperability conflicts, when one gateway supports
NACK but the other ignores it. 

Regards,
Vladimir Ulybin

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, July 04, 2005 10:21 AM
To: Vladimir Ulybin
Cc: [email-masked]
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir Ulybin wrote:
> 
> 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.

There exist at least two possible ways of performing this without 
screwing up the RTCP statistics and fulfilling your other requirements:

The first one is to use FEC to provide the packet repetition. I would 
suggest that you use RFC 2733 to provide repetition in a smarter way. 
This way one FEC packet can cover a few RTP packets. If this is done 
using RFC 2198 packetization then you don't even need to run two RTP 
sessions.

The second is actually to use that Retransmission RTP payload format for

repetitions. The payload format is really for repetitions and the spec 
provides with necessary information on bind and sync. Simple skip the 
NACK process.

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: [email-masked]

---

From: "Vladimir Ulybin" <[email-masked]>
Date: Mon, 4 Jul 2005 13:27:31 +0300

Corrected item 3:
3. Different RTP sequence numbers assigned to a fax state (or binary
data) detected (or demodulated) at ONE moment of time cannot be
considered as unique, because the one fax state will share some
different packets. There is no mutual correspondence.
Sorry,
Vladimir Ulybin

-----Original Message-----
From: Vladimir Ulybin 
Sent: Monday, July 04, 2005 12:59 PM
To: 'Colin Perkins'
Cc: [email-masked]
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

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

---

From: "Vladimir Ulybin" <[email-masked]>
Date: Sun, 17 Jul 2005 09:11:02 +0300

Sorry for type mistake:

Instead of
"Both ways present optional features which may not be supported by
gateways."

Should be
"Both ways present optional features which possibly are not supported by
gateways."

Vladimir Ulybin

-----Original Message-----
From: Vladimir Ulybin 
Sent: Sunday, July 17, 2005 9: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

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

---

From: "Oren Peleg" <[email-masked]>
Date: Tue, 19 Jul 2005 15:24:55 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Vladimir Ulybin
Sent: Tuesday, July 19, 2005 9:40 AM
To: Paul E. Jones; Colin Perkins
Cc: [email-masked]
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Paul,

1. Zero is a simplest solution. The RFC 3550 allow the same time stamp
for several consecutive packets. So, when these packets will be
transmitted as redundant one relative to the other, the time offsets per
RFC 2198 will be zero. It means that receiving gateway should handle
correctly zero time offsets in RFC 2198 headers.

2. The computation of redundant packet time offset relative to primary
packet can be applied for synchronous operation like audio or
t4-non-ECM-data having a fixed time interval between packets. But, for
asynchronous packet stream, which is typical for T.30 control and ECM
fax, such approach cannot be used.

Why I opened this issue?

Assume a T.38 module of DSP/gateway which delivers the T.38 UDPTL
packets ready for transmission to IP. To enable new feature of T.38 over
RTP, it is easy to convert T.38 UDPTL into RFC 2198 at output of
DSP/gateway. The obstacle is in time stamp offsets of redundant packets.
We all (fax engineers) know that these offsets are not required at T.38
packet receivers. But accurate transmission of those per RFC 2198
requires deep re-writing of working and verified module(s) plus
additional allocation of RedundancyLevel*NofChannels timestamps.

Regards,
Vladimir Ulybin

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

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

> From: Vladimir Ulybin [mailto:[email-masked]]
> Sent: Monday, July 18, 2005 2:38 AM
> To: Paul E. Jones; Colin Perkins
> Cc: [email-masked]
> 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
> 
> Sent: Monday, July 18, 2005 6:17 AM
> 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
> 
> 
> > From: Vladimir Ulybin [mailto:[email-masked]]
> > Sent: Sunday, July 17, 2005 2:06 AM
> > To: Paul E. Jones; Colin Perkins
> > Cc: [email-masked]
> > > 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550
> as
> > a
> > > 2. The RFC 3550 does not define the packet repetition, also does
not
> > use

---

From: "Vladimir Ulybin" <[email-masked]>
Date: Wed, 20 Jul 2005 10:07:31 +0300

Colin,

Unfortunately, T.38 over UDPTL has no secure capability. This is why we
need T.38 over RTP.

The discussion was very useful for understanding possible
interoperability problems of T.38 over RTP and correcting the
implementation concept.

Thank you very much!

Vladimir Ulybin

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2005 6:01 PM
To: Vladimir Ulybin
Cc: Paul E. Jones; [email-masked]
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

Use of timestamps to reconstruct media timing is an essential feature  
of RTP. We will not standardise an RTP payload format which does not  
use them, since that would be incompatible with the rest of RTP, and  
would break the playout model used by RTP applications.  RTP is a  
general purpose transport protocol for real-time traffic -- it is not  
appropriate to optimise it for this niche application, at the expense  
incompatibility with other use cases.

If you do not wish to use timestamps in your application, I suggest  
you use T.38 over UDPTL instead of over RTP. When implementing T.38  
over RTP, using timestamps is mandatory (as with all other RTP  
payload formats).

Colin

On 19 Jul 2005, at 15:45, Vladimir Ulybin wrote:
> Colin,
>
> I think that the use of timestamps together with sequence numbers for
> building T.38 packet recovery buffer is not a good way. For T.38
> INDICATOR packets it is acceptable but for DATA packets this way may
> cause a lot of problems for packet recovery during data transfer.
>
> It is much easy and reliable to use RTP sequence number as the only  
> base
> for ordering T.38 packets arrived over RTP. In this case,  
> timestamps of
> redundant payloads may be ignored without any problems.
>
> Let consider an option to update the "draft-jones-avt-audio- 
> t38-05.txt"
> or write a new draft for T.38 over RTP.
>
> I think the problems opened in our discussions
> - repetition of T.38 packets and
> - excessive complexity of T.38 over RTP caused by timestamps
> (non-required by T.38)
> are general for different vendors.
>
> Regards,
> Vladimir Ulybin
>
>
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, July 19, 2005 2:07 PM
> To: Vladimir Ulybin
> Cc: Paul E. Jones; [email-masked]
> On 19 Jul 2005, at 07:40, Vladimir Ulybin wrote:
>
> No, since it will treat the data as being a redundant copy of the
> packet in which it is sent. If you use an offset of zero, there's no
> way to correctly place the data at the right time instant in the
> playout buffer.
>
>
> Correct - this is why RFC 2198 has an explicit timestamp for the
> redundancy offset.
>
>
>> Why I opened this issue?
>>
> Correct - this is required for robust operation over an unreliable
> packet network that may disrupt media timing.
>
> There are two cases:
>
> 1) There is a constant mapping from sequence number to timestamp. In
> this case, you can trivially calculate the timestamp and need no
> extra storage. The media timing can be reconstructed using either the
> sequence number or timestamp, and transporting both is essentially a
> waste of bandwidth for this application. In this case, you treat the
> extra bits on the wire as an "RTP tax" needed for interoperability,
> but don't need to store the extra data in the gateway.
>
> 2) There is not a constant mapping from sequence number to timestamp.
> This case requires you to store the extra timestamps for inclusion in
> RFC 2198 redundancy headers, however that extra information is
> required by the receiver to manage a playout buffer, since a playout
> buffer managed by sequence number only is not sufficient to
> reconstruct media timing.
>
> Colin
>

---

From: "Oren Peleg" <[email-masked]>
Date: Thu, 21 Jul 2005 01:03:01 +0300

Also 2833, but still redundancy was managed within the profile. The T.38
draft may be extended to use a special mode of the RFC 2198, same as
done at 2833.

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2005 10:20 PM
To: Oren Peleg
Cc: Paul E. Jones; Vladimir Ulybin; Magnus Westerlund; [email-masked]
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

> redundant packets will be determined via SDP using a special  

This is incompatible with all other uses of RFC 2198, and contrary to  
the RTP timing model.

Colin

---

From: "Vladimir Ulybin" <[email-masked]>
Date: Sun, 24 Jul 2005 08:57:42 +0300

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:[email-masked]] 
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   

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vladimir Ulybin
> Sent: Wednesday, July 20, 2005 5:51 AM
> To: Magnus Westerlund
> Cc: Paul E. Jones; Colin Perkins; [email-masked]
> 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
> 
> 
> Sent: Wednesday, July 20, 2005 10:49 AM
> To: Vladimir Ulybin
> Cc: Colin Perkins; Paul E. Jones; [email-masked]
> 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"
> 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.
> 
> > 
> 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.
> 
> 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
>

---

From: lazzaro <[email-masked]>
Date: Mon, 25 Jul 2005 08:53:43 -0700

Magnus Westerlund <magnus.westerlund at ericsson.com> writes:
> However please remember that you must stay within the ground rules  
> of RTP. For example defining the marker bit strangely may not be  
> the wisest. At least not as long as it is within an audio RTP session.

Indeed -- the unusual use of the marker bit in
mpeg4-generic led to the only bit-level incompatibility
between native RTP MIDI and mpeg4-generic
encapsulated RTP MIDI ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---