Flash отправляет аудио данные через TCP соединение в случае RTMP SIP Gateway + Wowza.
TCP протокол это протокол с поддержкой состояния и надежной доставкой пакетов.
Таким образом время прибытия аудио фрейма с Flash клиента на сервер вообще говоря не ограничено.
Это может быть 5, 10, 20, 30, 50, 100 и т.д. миллисекунд и зависит от условий сети.
Например, в силу особенностей протокола будут выполняться попытки получить очередной аудио фрейм, не принимая во внимание то что он может прибыть слишком поздно и быть не актуальным для данного потока.
Решением может являться Adaptive Jitter Buffer или простой playback buffer на стороне получателя. Такой буфер должен предотвратить разрывы в воспроизведении аудио потока и воспроизвести аудио более гладко.
Если используется Adaptive Jitter Buffer, это может уменьшить задержку путем сброса отдельных пакетов, которые пришли слишком поздно. Если это обычный playback buffer — буфер воспроизведения, это может увеличить задержку, т.к. такой буфер обычно сбрасывается при переполнении и действует менее гибко.
Другой вариант — использовать WebRTC или RTMFP для передачи звука(Flashphoner Web Call Server 3).
Здесь jitter buffer будет меньше за счет того, что WebRTC это фактически защищенный RTP протокол, а RTMFP работает поверх UDP — протокола без поддержки состояния и надежной доставки. Использование таких протоколов уменьшает jitter и задержку. Но и для них не получится получить абсолютно точный интервал 20ms при отправки аудио пакетов. Поэтому Adapter Jitter Buffer будет полезен на стороне приемника потока и в этом случае. Такой буфер является VoIP стандартом и используется практически во всех устройствах и софтфонах.
