Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

[Roman Shpount <[e-mail]>]

On Wed, Jan 27, 2016 at 12:17 PM, Jean-Marc Valin <[e-mail]>
wrote:

> The problem I see is that unlike G.711, modern codecs (not just Opus)
> aren't stateless. It's not a simple thing to just stop and restart
> transmission during telephony events -- especially if you want to
> avoid glitches and want all implementations to behave the same. You
> need to consider look-ahead (6 ms for Opus, with 5-10 ms being
> typical), but also the "memory" from the previous frame.
>

In this regard Opus is no different then G.729 which was used with
telephone-events for ages. Sending a telephone-event packet is an audio
codec switch. Its behavior should be no different then switch from Opus to
PCMU or from Opus to CN and back. I assume statefull codec such as Opus
should reset its state before starting to send audio after such switch
occurs. Is this correct? From what I know this was never defined anywhere
and it might be a good idea from the codec designers to specify what is the
best behavior for codec switches from telephone-event or CN. Since most of
codecs converge very quickly I see this implemented equally often with or
without codec state reset. Also, since telephone-events are normally
followed by a period of silence (intertone gap), codec state plays much
smaller role in practice.

> Packet boundaries of audio encoded using codecs such as G.711 or
> > Opus should create a continuous stream as far as RTP timestamps are
> > concerned with RFC 4733 telephone event packets unless
> > discontinuous RTP is used. It should be possible to align decoded
> > audio and telephone-events based on RTP timestamps.
>
> What do you mean "create a continuous stream"? I thought you wanted
> the codec to stop transmitting.
>

Yes, I do want the code to stop transmitting. I want the clean codec switch
from non-event audio codec to telephone-event and back. What I mean here is
if you have PCMU packet with timestamp 1000 and duration 160 the following
telephone-event start timestamp should be 1160. The transition in other
direction should also happen without the timestamp gap so that if
telephone-event start timestamp is 1160 and the total tone duration is 800
then next non event audio packet should start with timestamp 1960.
Furthermore, I like to recommend to switch from non-event to
telephone-event and back on the regular packet boundary. This means no
partial audio packets (17 ms audio packet before telephone event) and no
gaps or overlaps after telephone-event (no telephone events with duration
117 ms which causes subsequent audio packet either start before the end of
the telephone-event or with a 3 ms gap after the event or exactly after the
telephone event but with 3 ms offset in comparison with audio packets
before telephone events).

Sorry for spending so much time on telephone-event generation but equipment
generating broken telephone-event streams and then causing havoc in the
phone network is something that is something that wasted couple of weeks of
my time this month alone. I simply want to provide the list of
recommendations for rtcweb which will cause the least amount of interop
trouble in the future.

Regards,
_____________
Roman Shpount