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

"Paul E. Jones" <paulej@packetizer.com> Sat, 16 July 2005 22:54 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvYY-0005S8-0c; Sat, 16 Jul 2005 18:54:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvYV-0005Rx-VU for avt@megatron.ietf.org; Sat, 16 Jul 2005 18:54:48 -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 SAA07270 for <avt@ietf.org>; Sat, 16 Jul 2005 18:54:44 -0400 (EDT)
Received: from rrcs-24-199-146-6.midsouth.biz.rr.com ([24.199.146.6] helo=berlin.arid.us ident=system) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtw1Z-0006L6-C2 for avt@ietf.org; Sat, 16 Jul 2005 19:24:52 -0400
Received: from madrid (madrid.arid.us [192.168.1.10]) by berlin.arid.us (8.12.8/8.12.8) with ESMTP id j6GMsOSA004550; Sat, 16 Jul 2005 18:54:24 -0400
Message-Id: <200507162254.j6GMsOSA004550@berlin.arid.us>
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'Vladimir Ulybin' <Vladimir@audiocodes.com>, 'Colin Perkins' <csp@csperkins.org>
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
Date: Sat, 16 Jul 2005 18:53:28 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A059D@aclmsg.corp.audiocodes.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3A=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
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

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