RE: [AVT] T.38 over RTP: RTP Sequence Number
"Oren Peleg" <OrenP@audiocodes.com> Tue, 19 July 2005 12:24 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dur9L-0006Tu-Ed; Tue, 19 Jul 2005 08:24:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dur9K-0006Tp-Q6 for avt@megatron.ietf.org; Tue, 19 Jul 2005 08:24:38 -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 IAA08396 for <avt@ietf.org>; Tue, 19 Jul 2005 08:24:37 -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 1Durcw-0004Tq-VS for avt@ietf.org; Tue, 19 Jul 2005 08:55:15 -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 15:24:55 +0300
Message-ID: <EF8DFB1B64FF0A43AB00555B8E2717B101D7A613@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3AADKWiIAAuyJ8AAASU3nAAHppKkAATWKKAAAjY1nA=
From: Oren Peleg <OrenP@audiocodes.com>
To: Vladimir Ulybin <Vladimir@audiocodes.com>, "Paul E. Jones" <paulej@packetizer.com>, Colin Perkins <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb
Content-Transfer-Encoding: quoted-printable
Cc: 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
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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Vladimir Ulybin Sent: Tuesday, July 19, 2005 9:40 AM To: Paul E. Jones; Colin Perkins Cc: avt@ietf.org 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:paulej@packetizer.com] Sent: Monday, July 18, 2005 11:02 PM To: Vladimir Ulybin; 'Colin Perkins' Cc: avt@ietf.org 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 > -----Original Message----- > From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com] > Sent: Monday, July 18, 2005 2:38 AM > To: Paul E. Jones; Colin Perkins > Cc: avt@ietf.org > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number > > 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:paulej@packetizer.com] > Sent: Monday, July 18, 2005 6:17 AM > To: Vladimir Ulybin; 'Colin Perkins' > Cc: avt@ietf.org > 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:Vladimir@audiocodes.com] > > Sent: Sunday, July 17, 2005 2:06 AM > > To: Paul E. Jones; Colin Perkins > > Cc: avt@ietf.org > > 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:paulej@packetizer.com] > > Sent: Sunday, July 17, 2005 1:53 AM > > To: Vladimir Ulybin; 'Colin Perkins' > > Cc: avt@ietf.org > > 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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf > Of > > > Vladimir Ulybin > > > Sent: Monday, July 04, 2005 5:59 AM > > > To: Colin Perkins > > > Cc: avt@ietf.org > > > 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 > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ 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