[MMUSIC] ptime precision

Kevin Gross <kevin.gross@avanw.com> Tue, 17 July 2012 21:30 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D0A6311E80AD for <mmusic@ietfa.amsl.com>; Tue, 17 Jul 2012 14:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.473
X-Spam-Level: *
X-Spam-Status: No, score=1.473 tagged_above=-999 required=5 tests=[AWL=-1.345, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ebqlJL9UgCVc for <mmusic@ietfa.amsl.com>; Tue, 17 Jul 2012 14:30:19 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 2F10F11E80A4 for <mmusic@ietf.org>; Tue, 17 Jul 2012 14:30:19 -0700 (PDT)
Received: (qmail 24436 invoked by uid 0); 17 Jul 2012 21:31:07 -0000
Received: from unknown (HELO host291.hostmonster.com) ( by oproxy9.bluehost.com with SMTP; 17 Jul 2012 21:31:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:MIME-Version; bh=QKx8o8vA1fvvW5RnhaThsOVnX4sPnRuKnvwFvKdyClI=; b=cWJRpv+j2xebsSlvPL8qydSZ2NcEzRJ/WRxCOhVQz4KcziplSPg+vyGrzTKTduxs7IAvyo1FRWecCCDuqrN+fRuGrzizNSblV/P6EvXFRnXlUwp//ZwMfXAWi/7C9i33;
Received: from [] (port=64058 helo=mail-wi0-f178.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from <kevin.gross@avanw.com>) id 1SrFMJ-0008G7-5d for mmusic@ietf.org; Tue, 17 Jul 2012 15:31:07 -0600
Received: by wibhr14 with SMTP id hr14so662136wib.13 for <mmusic@ietf.org>; Tue, 17 Jul 2012 14:31:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id j5mr257150wef.38.1342560665867; Tue, 17 Jul 2012 14:31:05 -0700 (PDT)
Received: by with HTTP; Tue, 17 Jul 2012 14:31:05 -0700 (PDT)
Date: Tue, 17 Jul 2012 15:31:05 -0600
Message-ID: <CALw1_Q0CqVjAv83J_KNsmOrUS_RsBFTY3NWBV5isdhwOEKs_-Q@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: mmusic <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="e0cb4e6ffbf79416a604c50d43c4"
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth authed with kevin.gross@avanw.com}
Subject: [MMUSIC] ptime precision
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 21:30:19 -0000

I am working on a high-performance RTP application (see www.x192.org) which
will, in some cases, use packet times less than 1 millisecond to achieve
very low latencies for live sound over high-performance local-area
networks. We'd like to signal and negotiate the packet time in these

Unfortunately, the millisecond units of a=ptime are too coarse for this
application. I've read draft-garcia-mmusic-multiple-ptimes-problem which
alerted me to a=vsel in RFC 3108 which specifies packet time in units of
microseconds. Unfortunately, we're not sure that microsecond resolution is
sufficient as there are some useful packet times which are not an integer
number of microseconds. We are currently considering using this anyway and
rounding to the nearest microsecond.

But, two of us working on this shortcoming have independently come to the
conclusion that the most versatile way to express packet time is in units
of RTP clock ticks. The RTP clock time is an 32-bit integer and appears in
the header of every RTP packet. Packet time under this proposed definition
is, roughly speaking, the difference in RTP clocks on successive RTP
packets. There is no precision issue as, by this definition, the packet
time will always be an integer.

Does this seem like a good idea? Does something like this already
exist? Are there any other alternatives that I haven't uncovered?

Kevin Gross
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org