Subject: RFC 2833 on Tones

From: "Bratakos, Maroula" <[email-masked]>
Date: Tue, 30 May 2000 17:05:41 -0700

I have a question about the last paragraph in section 2 that discusses
gateways which send signaling events via RTP.  It states: 

If a gateway cannot present a tone representation, it SHOULD send the audio
tones as regular RTP audio packets (e.g., as payload format PCMU), in
addition to the named signals. 
If the audio tones are sent along with named signals then shouldn't the
redundant method of RFC 2198 be used?

Maroula Bratakos
Nuera Communications, Inc.
[email-masked]

---

From: Dan Wing <[email-masked]>
Date: Tue, 30 May 2000 18:14:00 -0700 (PDT)

On Tue, 30 May 2000 17:05 -0700, Bratakos, Maroula wrote:

> If a gateway cannot present a tone representation, it SHOULD send the
> audio tones as regular RTP audio packets (e.g., as payload format
> PCMU), in addition to the named signals.
>

That would cause 'issues' (to put it mildly) if you're on any sort of
bandwidth allocation or near the saturation point for the access link,
such as with DSL or cable.

For example, if the admitted calls are currently consuming nearly
all of the upstream bandwidth, then doubling the bandwidth consumed
when someone touches a DTMF keypad will cause problems for the other
calls using that link.

-Dan Wing

---

From: "Rex Coldren" <[email-masked]>
Date: Wed, 31 May 2000 10:43:21 -0700

> when someone touches a DTMF keypad will cause problems for the other

Yeah, not to mention the fact that if there's policing/filtering being done on the
upstream link the transmitter is liable to get busted.

In any event, sending the DTMF events in addition to the RTP stream will not
necessarily double the bandwidth used.  And you have more than one option
for sending the DTMF (events and tonal representations).  RFC 2833 is set
up to use less bandwidth than the original encoding, in general.  When used
with RFC 2198, the number of redundant encodings also has an impact on the
total bandwidth used.

---

From: Dan Wing <[email-masked]>
Date: Wed, 31 May 2000 10:57:49 -0700 (PDT)

On Wed, 31 May 2000 10:43 -0700, Rex Coldren wrote:

> Yeah, not to mention the fact that if there's policing/filtering being
> done on the upstream link the transmitter is liable to get busted.
> 
> In any event, sending the DTMF events in addition to the RTP stream
> will not necessarily double the bandwidth used.

Agreed.

> And you have more than one option for sending the DTMF (events and
> tonal representations). 

Yes.  Actually, there are three mechanisms:

  1. audio tones
  2. events, as per RFC2833
  3. both, which is what is recommended in RFC2833

Maroula Bratakos' message about using RFC2198 to duplicate packets
concerned (3).  I'm sure there was an intent to also cover (1) but that
requires a DTMF detector, in which case you would expect an implementation
to do (3).

> RFC 2833 is set up to use less bandwidth than the original encoding,
> in general. 

Agreed.

> When used with RFC 2198, the number of redundant encodings also has an
> impact on the total bandwidth used.

I think the duplication has merit, but appropriate text is required
explaining when such RFC2198 duplication of DTMF tones isn't appropriate.

Perhaps a simple MAY is good enough, but only if we assume implementors
will understand why it's a MAY instead of SHOULD or MUST.  I haven't read
RFC2198 in awhile, but it may have text which explains some of the
drawbacks of arbitrary duplication of packets in a bandwidth-constrained
or policed network.  My quick skim of RFC2198 didn't turn up such text,
however.

-Dan Wing

---

From: "Rex Coldren" <[email-masked]>
Date: Wed, 31 May 2000 11:14:00 -0700

> or policed network.  My quick skim of RFC2198 didn't turn up such text,

You're right.  I don't think it's there.

Note that the usual situation involving the need to send DTMF tones outside of
the normal RTP payload implies that the tones inside the normal RTP payload
are of no use, or at least should not be trusted.  Indeed, in many/all cases you
would want to strip those tones out of the normal RTP payload when sending
via RFC 2833/2198 methods.  Consequently, the normal RTP payload has an
element of mutual exclusivity with the RTP payload used to carry the RFC
2833/2198 encodings.  Some benefit can be gained from this knowledge when
the access network is bandwidth limited, as in the cable and DSL cases.

RFC 2833 does not address the possibility of replacing normal RTP payloads
with RFC 2833 payloads.  This would be a useful concept in bandwidth limited
networks.  What do you think?

Rex Coldren