RE: [AVT] RFC 2833 questions: Intervals, durations, and lost packets.

["Lubbs, Stephen" <stephen.lubbs@intel.com>]

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.


Regards,
Steve

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Monday, October 28, 2002 12:33 PM
To: Lubbs, Stephen
Cc: AVT (E-mail)
Subject: Re: [AVT] RFC 2833 questions: Intervals, durations, and lost
packets.


Please read the updated version (draft-ietf-avt-rfc2833bis, issued a few 
days ago) and see if it answers your questions.

Lubbs, Stephen wrote:
> Hi Folks,
> I have a few questions related to RFC 2833, to wit:
> 
>    1. Is the intent of the spec that RFC 2833 packets should
>       be transmitted every 50 ms or is it that they should be
>       transmitted at the interval represented by the duration of audio
>       packets sent prior to RFC 2833 events?

See the draft.

>    2. If both audio packets and RFC 2833 packets are transmitted
>       concurrently, is it allowable for the duration of each RFC packet
>       be different from that of the packet interval of the audio
>       packets. Is there a recommendation with respect to this?

The spec can't spell all allowable permutations. If nothing is said, 
normal RTP rules apply. Since every RTP packet even with the same PT 
could, conceivably, cover a different time interval, this is certainly 
possible. I would expect that this would test the robustness of most 
implementations, so maybe we should add this to a torture test...

>    3. If both audio packets and RFC 2833 packets are transmitted
>       concurrently and an RFC 2833 packet is missing, is the intent that
>       the last RFC 2833 packet received should be extended or should the
>       audio packet be played out in its stead? Should the ability of the
>       codec to represent the event be considered?

This is an implementation decision since it does not affect correct 
interoperation. Consider it product differentiation.

>    4. If both audio packets and RFC 2833 packets are transmitted
>       concurrently and an RFC 2833 packet is missing, assuming that the
>       last RFC 2833 packet should be extended for a period that would
>       represent up to 3 lost packets, which should be used to calculate
>       the duration of the extension: the duration of the previously
>       received RFC 2833 packet or the packet interval of the previously
>       received audio packets?

See above; you can only guess at what you might have received.

>    5. If both audio packets and RFC 2833 packets are transmitted
>       concurrently which takes precedence? There seem to be
>       contradictory statements in the RFC.

Please point out contradictory statements by citation in the I-D. In 
general, this is one of million of possible failure cases which should 
only occur if somebody goofs. Depending on the application, you could 
justify any approach, including dropping the packet, since the sender is 
obviously confused and may not mean either.

> 
> Regards,
> Steve Lubbs
>  
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt