Subject: Re: [AVT] 2833bis

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 04 Nov 2002 12:53:20 -0500

>
>     "Since all implementations MUST be able to receive events 0 through
>    15, listing these events in the a=fmtp line is OPTIONAL.
>
> There was some discussion about how appropriate this really was, and I 
> believe
> it was generally agreed, that mandating that all implementations of 
> RFC 2833
> support DTMF was not the right thing to do. For example, if I only want to
> convey V.25/V.8 ANS and ANSam, then why not ? Thus, the following 
> implementation
> note was added at http://www.cs.columbia.edu/~hgs/rtp/payload_audio.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."
>
> Taking a look at Section 3.9 in 2833bis, I see the offending text is 
> no longer
> there. If it doesn't say anything else about mandatory and implied 
> DTMF support
> anywhere else, then I'm happy.

If somebody finds a reference to something suggesting that this be 
mandatory, let me know. I don't know if this is a problem, but since 
listing 0-15 was OPTIONAL in 2833, we could stipulate that fmtp is 
mandatory now. In the spirit of limiting options and being explicit 
about capabilities, I see no drawback to making it mandatory.

> I like the soft-state idea. It has some nice self-synchronizing 
> properties that
> would seem to make the whole "state" concept less susceptible to 
> errors (whether
> human or network induced). 

I will add this unless somebody objects. This was implied, since there 
was no text that ruled out non-zero durations for events marked as 
'state?', but it can't hurt to call this out explicitly.

> If there are "good til cancelled" states that need to
> be communicated to the other party, and for which the soft-state 
> approach is not
> acceptable or desirable, then I wonder if a call control protocol 
> wouldn't be a
> more appropriate means of signaling such things.
>
> -- Flemming
>
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt