Re: [AVT] 2833bis

[Flemming Andreasen <fandreas@cisco.com>]

Henning Schulzrinne wrote:

> Sorry for the delay in getting back to this draft. I'm ready to do
> another update; comments below. I've split my response into several
> messages to keep the follow-up manageable.
>
> Flemming Andreasen wrote:
>
> > Questions/Comments
> > ================
> > p.5: After the sentence "A compliant implementation MUST support the
> > events
> > listed in Table 1 with the exception of "flash"."  the implementation note
> > "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."
> > should be added (and/or perhaps in Section 3.9). Also on p. 25 (Optional
> > parameters).
>
> The last part "including 0 through 15" contradicts RFC 2833. Or are you
> suggesting that inclusion implies a higher level of support beyond just
> swallowing packets whole? This would still mean that RFC 2833 wouldn't
> declare this, even if they did something "meaningful" with the packets.
> In general, I don't think that distinguishing processing behavior is
> useful, since there doesn't seem to be a bright line. What exactly does
> "meaningful" mean? I can see that this probably means "regenerate the
> tone" for a gateway, but what about other devices?
>

RFC 2833 states that

    "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.

>
> >
> > - duration: The definition states "...has so far lasted as long as
> > indicated by
> > this parameter.", however this is inconsistent with the duration "0",
> > and also
> > seems inconsistent with the definition of state events under the "E:"
> > (end bit)
> > definition that follows:
> > - E (end bit):  The new text seems to imply that state event can be
> > sent with
> > an "anticipated or good till cancelled duration", i.e. not necessarily
> > just the
> > duration so far, however as noted, this is inconsistent with the
> > "duration"
> > parameter. It's also not entirely clear if this is only allowed for state
> > events (I assume so). Rephrasing parts of the paragraph might aid in the
> > understanding here too.
>
> The description after "Some events..." was left over from an earlier
> discussion of states and contradicts the zero-duration rule. It assumes
> a non-zero indication, basically a time-out value after which the state
> is reset unless it is refreshed. I think zero is simpler to implement,
> but the timeout value might make for a reasonable soft-state
> implementation that avoids systems getting "stuck" after packet loss.
> I'd appreciate feedback on this.
>

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). 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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt