[MMUSIC] ptime precision

[Kevin Gross <[e-mail]>]

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
applications.

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
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org