Subject: Re: Optional DTMF support in RFC 2833

From: "Rex Coldren" <[email-masked]>
Date: Tue, 05 Sep 2000 14:21:48 -0700

Flemming,
   Thanks for the heads-up.  The implementation note conflicts with what
is stated in RFC 2833, by the way.  RFC 2833 says the following:

   Since all implementations MUST be able to receive events 0 through
   15, listing these events in the a=fmtp line is OPTIONAL.

   I guess I'm wondering why the implementation notes say that the 0 thru
15 numbers MUST be declared when the RFC says declaring them is
optional.  Also, for my information, do the implementation notes override
the contents of the RFC?

Regards,
Rex Coldren

Flemming Andreasen wrote:

> Folks
>
> Just wanted to draw all RFC 2833 interested parties to the following
> implementation note (http://www.cs.columbia.edu/~hgs/rtp/payload.html):
>
> "Implementations can support events 0 through 15 (DTMF) by simply
> ignoring the packets, but MUST declare all event numbers that are
> meaningful to it in the fmtp parameter, including 0 through 15."
>
> Thanks
>
>         Flemming
>
> --
> Flemming Andreasen
> Cisco Systems

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2000 20:27:16 -0400

Flemming Andreasen wrote:
> Rex Coldren wrote:
> > is stated in RFC 2833, by the way.
> 
> I guess that depends on how you interpret the words.
> 
> > RFC 2833 says the following:
> >
> > optional.
> I should probably let Henning answer, but the idea is to not require all RFC
> 2833 implementations to implement DTMF support. The reason is, that RFC 2833
> is a general and very useful mechanism, and requiring all use of it to
> include support for DTMF is overly restrictive. The note provides a way out
> of that and I believe will be included in RFC 2833 when it progresses to
> Draft Standard.

It is also backward compatible for now, in that declaring support is
currently redundant. 

Practically speaking, with DTMF, support is also a rather vague term.
Support could mean anything short of core dumping. If the other side
silently swallows type 0-15, is that support? Presumably, this would
only occur in real systems if DTMF doesn't make sense. Maybe it would be
helpful is somebody could provide examples of RFC 2833 systems that
would have no use for DTMF. If you're building a system that logically
should support DTMF, but doesn't, having the protocol police chase after
you is probably not your major concern.

> 
> > Also, for my information, do the implementation notes override
> > the contents of the RFC?
> 
> They clarify them at least.

No, they obviously don't override the RFC. However, RFC 2026 says

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

Thus, implementors can't completely rely on every word staying the same.
The implementation note is meant to tell implementors "indicate DTMF
support now explicitly as it will prevent problems later". 

A typical way of resolving this would be to ask around, at Draft time,
whether any known implementation is having problems with that change.

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

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 05 Sep 2000 18:27:51 -0400

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Rex Coldren" <[email-masked]>
Date: Tue, 05 Sep 2000 19:37:34 -0700

Flemming, Henning,

I agree with both of you.  DTMF support should not be required.  Realistically,
there will likely be zero implementations that will implement all of the possible
combinations of events and tones.  So how do we deal with trying to push RFC
2833 toward Draft Standard when none of the implementations support the full
set of capabilities?  Do the IETF rules for deprecating options require that all of
the interoperable implementations support option sets that are a union or an
intersection of working options of the common group (forgive my ignorance of
the rules; RFC 2026 didn't help me much here)?  I am hoping that a simple
intersecting set is the answer.  Otherwise RFC 2833 will disintegrate.  Thoughts?
.
Cheers,
Rex Coldren

---

From: "Rex Coldren" <[email-masked]>
Date: Tue, 05 Sep 2000 19:56:56 -0700

Ooops.  I meant that I hope the union of options is what is required.  Sorry
for the slip...

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 06 Sep 2000 12:58:32 -0400

> intersecting set is the answer.  Otherwise RFC 2833 will disintegrate.  Thoughts?

Any one feature (or event, for 2833) will need to be supported by two
independent implementations. It is not necessary that two
implementations support all events. In the case of simple constants such
as the events, it's also not exactly clear that it makes sense to remove
one event that currently may not have two implementations. After all,
somebody could just go right back to IANA and register that number.
(With IANA, there is no two-implementations requirement.)

Thus, I'd suggest that we find a volunteer with active implementation
interest in RFC 2833 to gather implementation reports on features and
events. This list (and the list of implementations) does not have to be
public, in case that's a concern.

After that's done, we can take a look at the problem cases of events
that have zero or one implementations and see whether this is a matter
of "useful, but just not there yet" or "not that useful after all".

---

From: Colin Perkins <[email-masked]>
Date: Wed, 06 Sep 2000 13:24:46 -0400

>intersecting set is the answer.  Otherwise RFC 2833 will disintegrate.  Thoughts?

The rules require that at least two independent interoperable
implementations exist for each feature. There is no requirement
that a particular implementation support every feature, so long
as each feature is supported by some implementations.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Wed, 06 Sep 2000 13:26:55 -0400

>of "useful, but just not there yet" or "not that useful after all".

Although note that this can't go to draft standard until RTP goes to draft,
which means we need to complete the RTP interop first.....

Colin