Re: [AVT] 2833bis

[Henning Schulzrinne <hgs@cs.columbia.edu>]

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?

> p.6-8: There seem to be some minor inconsistencies and ambiguities 
> introduced
> by the new state event concept.
> - Timestamp: It's not clear if the duration value "0" can only be used 
> with
> state events or not.

Yes. I don't think we want this for other types of events, since it 
could mean that a tone gets "stuck" forever. I'll reference the 'state' 
flag in the table explicitly.

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

[More to follow]

Henning

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt