Subject: [AVT] draft-ietf-avt-rfc2833bis-08

From: Tom Taylor <[email-masked]>
Date: Wed, 16 Feb 2005 11:27:38 -0500

I have just posted a small revision of RFC 2833bis (core specification).  The 
revision reflects points made by Tim Melanchuk.  These points are that section 5 
no longer has advice about dealing with combined event and other payload types, 
and that receivers should know how to deal with such combined payloads.

The following changes were made in response to these points:

Section 1.4, end of first paragraph:

OLD: Depending on the
       application, it may be desirable to carry the signalling information
       in more than one form at once.  Section 5 discusses when and how this
       should be done.

NEW: Depending on the
    application, it may be desirable to carry the signalling information
    in more than one form at once.

Section 2.5.2.2, first paragraph:

OLD:

    In the gateway scenario, an Internet telephony gateway connecting a
    packet voice network to the PSTN recreates the DTMF or other tones
    and injects them into the PSTN.  Since, for example, DTMF digit
    recognition takes several tens of milliseconds, the first few
    milliseconds of a digit will arrive as regular audio packets.  Thus,
    careful time and power (volume) alignment between the audio samples
    and the events is needed to avoid generating spurious digits at the
    receiver.  Playout when audio packets continue to arrive as the event
    proceeds is discussed further in Section 5.2 below.

NEW:

    In the gateway scenario, an Internet telephony gateway connecting a
    packet voice network to the PSTN recreates the DTMF or other tones
    and injects them into the PSTN.  Since, for example, DTMF digit
    recognition takes several tens of milliseconds, the first few
    milliseconds of a digit will arrive as regular audio packets.  Thus,
    careful time and power (volume) alignment between the audio samples
    and the events is needed to avoid generating spurious digits at the
    receiver.  As well, some implementations send events and encoded
    audio packets (e.g., PCMU or the codec used for speech signals) for
    the same time instant for the duration of the event.  It is
    RECOMMENDED that gateways render only the telephone-event payload
    once it is received, since the audio may contain spurious tones
    introduced by the audio compression algorithm.  However, it is
    anticipated that these extra tones in general should not interfere
    with recognition at the far end.

Added Tim Melanchuk in the Acknowledgements section.

Tom Taylor
Nortel

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