RE: [AVT] T.38 over RTP: RTP Sequence Number
"Vladimir Ulybin" <Vladimir@audiocodes.com> Tue, 19 July 2005 14:45 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutM0-0007kv-AF; Tue, 19 Jul 2005 10:45:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutLy-0007jz-9u for avt@megatron.ietf.org; Tue, 19 Jul 2005 10:45:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19800 for <avt@ietf.org>; Tue, 19 Jul 2005 10:45:47 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19] helo=aclmsg.corp.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dutpa-0001mr-Vs for avt@ietf.org; Tue, 19 Jul 2005 11:16:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
Date: Tue, 19 Jul 2005 17:45:50 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD60126EB68@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWMUiCVnmTzfjJsQhmV+LeSb9/XIgAGgaLw
From: Vladimir Ulybin <Vladimir@audiocodes.com>
To: Colin Perkins <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: quoted-printable
Cc: "Paul E. Jones" <paulej@packetizer.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
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 -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Tuesday, July 19, 2005 2:07 PM To: Vladimir Ulybin Cc: Paul E. Jones; avt@ietf.org Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number On 19 Jul 2005, at 07:40, Vladimir Ulybin wrote: > 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. 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. > 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. Correct - this is why RFC 2198 has an explicit timestamp for the redundancy offset. > 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. 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 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Colin Perkins
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Magnus Westerlund
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Colin Perkins
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Colin Perkins
- RE: [AVT] T.38 over RTP: RTP Sequence Number Paul E. Jones
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- RE: [AVT] T.38 over RTP: RTP Sequence Number Paul E. Jones
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Colin Perkins
- RE: [AVT] T.38 over RTP: RTP Sequence Number Paul E. Jones
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Colin Perkins
- RE: [AVT] T.38 over RTP: RTP Sequence Number Oren Peleg
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Colin Perkins
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Magnus Westerlund
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- RE: [AVT] T.38 over RTP: RTP Sequence Number Paul E. Jones
- RE: [AVT] T.38 over RTP: RTP Sequence Number Paul E. Jones
- RE: [AVT] T.38 over RTP: RTP Sequence Number Oren Peleg
- Re: [AVT] T.38 over RTP: RTP Sequence Number Colin Perkins
- RE: [AVT] T.38 over RTP: RTP Sequence Number Oren Peleg
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- RE: [AVT] T.38 over RTP: RTP Sequence Number Paul E. Jones
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Magnus Westerlund
- Re: [AVT] T.38 over RTP: RTP Sequence Number lazzaro
- RE: [AVT] T.38 over RTP: RTP Sequence Number Vladimir Ulybin
- Re: [AVT] T.38 over RTP: RTP Sequence Number Magnus Westerlund