Re: RFC 2833 questions: Intervals, durations, and lost pack ets.

Lubbs, Stephen wrote:

> Hi Henning,
> Thanks for the answers. The latest draft has addressed some of my 
> question.
>
> Looking at the latest 2833bis draft, the statements I thought were 
> some what
> contradictory were the 2nd and third sentences of section 3.2:
>
> "In the first approach, it sends events and encoded audio packets (e.g.,
> PCMU) for the same time instant. In that mode, events are treated as
> redundant encodings for the encoded audio stream."
>
> And the next to the last sentence of section 3.2:
>
> "It is RECOMMENDED that gateways only render the encoded tone since the
> audio may contain spurious tones introduced by the audio compression
> algorithm. "
>
> The first example seems to imply that when both events and audio are
> available the audio should take precedence. The second example seems to
> indicate that when both are present the event should take precedence. 
> Hence
> my confusion.

I'm not sure that the notion of 'precedence' makes a lot of sense in 
practice. For entering a calling card code, a receiver would likely use 
the named events; for just relaying, a system might use the audio unless 
there's a packet loss. In general, since the named events have a higher 
"fidelity", I would expect that end systems would prefer them in almost 
all cases. Since this does not in any way affect bits on the wire and 
2833(bis) is being put to lots of different uses, my hunch is to punt. 
In other words, applications will know which one serves them best and I 
see no advantage in interoperability to tell the application writer what 
to do. As I said, except in "goof" cases, the two are semantically the same.

My general maxim is to keep the number of statements that can't be 
tested reliably by an external observer to a minimum.

I would welcome succinct alternative suggestions, but they should, I 
believe, avoid trying to anticipate applications.

Henning

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