Subject: Re: inband dtmf

From: [email-masked]
Date: Tue, 26 Oct 1999 10:11:32 -0400

Thank you for asking.
The latest version does seem to be an improvement.  I especially like the
end or 'E' bit.

I still have some concerns and questions though, to wit:

Paragraph 2 of section 3.1 (Intro to RTP Payload Format for Named Telephone
Events):
states that "DTMF digits ... SHOULD use the same sequence number and
time-stamp base as the regular audio channel".
It strikes me that a receiver might use VERY different strategies for
processing these events depending on whether the sequence number is
the same as the regular audio or not.  This basic fact would need to
somehow be negotiated by out of band means.  I think this is too much
wiggle
room and would argue for MUST instead of SHOULD.   Alternatively, some
discussion of how SDP or other techniques could be used to negotiate
or declare this should be inserted.
If, for example, one is not taking advantage of redundancy then detecting a
missing DTMF packet which is isolated or in the beginning of a sequence
is impossible if the same sequence number as the regular audio channel is
not used because you don't know when to expect it (of course you know when
the next one arrives with the sequence number bumped up by two but that is
too late).  If this concern is correct, then I think it merits at the very
least a cautionary statement
in the document.
There are also some issues related to compound packets and jitter buffers
raised by having a different sequence of sequence numbers/timestamps.
One might need to maintain two parallel buffers.

In section 3.5 on the 'E' bit is the sentence:
"A sender MAY set the end bit only when retransmitting the last packet for
a tone. This avoids having to wait to detect whether the tone has indeed
ended."
The second sentence seems to suggest that the authors meant to say MUST
instead of MAY, and that the emphasis is on last and not retransmit.  The
sentence
is sort of ambiguous.
In any case, it seems to me most useful to set the E bit for each of the
transmissions and retransmissions of the last packet for a tone.  This
affords maximum protection for detecting the end in the event of packet
loss. Avoiding the wait would best be acheived by setting the end bit on
the first transmission of the last packet, not the retransmission (If I'm
following this correctly.)
(There is also some kind of typo in the first sentence of the 2nd paragraph
for the 'E' bit where it says: "Receiver implementations MAY use at
different ....")

In the example in section 3.8, I believe the E bit has been left out and
two R bits are still shown.
Translating between milliseconds and timestamp units is helpful, it would
be more helpful still to point out things like 4800 = 11200 - 6400  right
in the
timestamp offset field for the second digit.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Oct 1999 15:04:07 -0400

[email-masked] wrote:

> room and would argue for MUST instead of SHOULD.   

Given that nobody has indicated a valid reason why one should use a
different timestamp base (and that switching encoders, say, between
G.711 and G.723.1 wouldn't change the sequence number either), I'd agree
that requiring this simplifies life. Changed, unless I hear a
counter-argument.

> a tone. This avoids having to wait to detect whether the tone has indeed

I've reworded the sentence to

"A sender {\MAY} delay setting the end bit until retransmitting the last
packet for a tone, rather than on its first transmission.  This avoids
having to wait to detect whether the tone has indeed ended."

> following this correctly.)

Yes, from a receiver perspective. But a sender wouldn't necessarily know
whether the tone has ended when it sends the packet, as it would have to
look into the future for that. It is rather unlikely that the tone will
end just after the packet interval, but it could conceivably happen. The
problem would not exist if tones were truly continuous, but since the
detector has to "bridge" short gaps, it can't decide whether the short
gap at the end of the interval is indeed just a spike and should be
ignored or the end of the tone was reached. In ASCII art:

       | transmission point
xxxxx  |   xxxx              - tone with small gap
xxxxx  |                       end of tone     

> two R bits are still shown.

Forgot to correct the example; fixed.

> timestamp offset field for the second digit.

I added the calculation in the figure.

Thanks for your comments.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs