Subject: Re: [AVT] RFC 2833/RFC 4733 and timestamps

From: "Mark Brown" <[email-masked]>
Date: Wed, 4 Jul 2007 11:06:42 +0100

On 6/28/07, Randell Jesup <[email-masked]> wrote:
>
> Ok, thanks.  My preference would be to send both, but that's me.  Sounds
> like "not sending both" is likely to be better tested.  Do they round
> start/end times to packet boundaries?

Usually to at least 10ms boundaries - I'd say 10ms was more common than a
full audio frame.

>In practice it seems much more reliable to transmit with no overlap. The
> >case that tends to break is that where the RTP stream is converted into
> >audio and DTMF detection is then performed on the result. This is
> especially
> >problematic if there is a possibility that there may be DTMF encoded as
> >audio outside the RFC 2833/4733 frames. It also helps DTMF detectors to
> >leave some time after the event before restarting audio.
>
> Ick.  My guess is the above is more focused on RFC 2833 generated from
> audio data (such as an ATA attached to a POTS phone), as opposed to a pure
> digital SIP phone, which knows exactly when DMTF events are generated.

Even without gatewaying some devices choose to inject DTMF into the audio
stream when doing simultaneous RFC2833 and audio.

This also implies that start times would get delayed by up to one audio
> frame time, and durations might be rounded (up I assume) to a multiple of
> frame time.  So a 40ms tone might become a 60ms tone (with a 30ms
> packetization).  If you don't delay, but round start down and end up (to
> avoid overlaps with audio packets) you could end up with a 40ms tone
> becoming a 90ms tone.  It could also eat a lot into inter-tone gaps.

IME the tone lengths are usually accurate to at least 10ms which is
generally good enough.

When you say "more reliable", do you mean when DTMF is generated by
> detection in an audio stream (ATA+POTS example), or that "it's less likely
> to blow up or confuse someone receiving it"?  In my case, there's no POTS
> phone or detection to be done.

The issues are receiver side rather than transmission side. In a gatewaying
situation like the ATA+POTS one the transmitter doesn't care that much about
what it sends so long as the result at the remote end is what it expects.
It's something like an ATA+POTS (or even ISDN for that matter) receiver that
will have trouble with mixed audio and DTMF.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt