Эта статья объясняет прохождение RTP-потока в IP-телефонах: проблемы медиапотока через NAT, принцип RTP Keep Alive, настройку, анализ пакетов и стабильность аудио или видео после Hold и Resume.
Когда IP-телефон обменивается данными через NAT, внешние медиапотоки могут не проходить во внутреннюю сеть, что приводит к невозможности связи. Такая ситуация также может возникнуть, когда два уже соединенных устройства долго находятся в режиме Hold. Поскольку информация о NAT-сопоставлении, сохраненная внешним маршрутизатором, может устареть, связь может по-прежнему не восстанавливаться после Resume.
Для обеспечения нормальной связи в среде NAT прохождение RTP-потока имеет особенно важное значение.
Согласно RFC6263, когда устройство работает в режимах INACTIVE и RECVONLY, необходимо использовать один из рекомендованных спецификацией способов периодической отправки RTP-пакетов. Спецификация рекомендует мультиплексирование RTCP с RTP. Однако, учитывая, что многие терминалы могли не реализовать этот метод, для совместимости принято решение использовать другой подход.
Согласно разделу 4 спецификации, связь можно поддерживать путем периодической отправки RTP-пакетов с неправильным Payload Type.
1.3.1 Настройка
После включения показанной выше настройки активируется прохождение RTP-потока. Пакеты RTP Keep Alive отправляются в следующих случаях:
1 После установления телефонного вызова телефон отправляет RTP-пакеты для открытия канала NAT. Это применяется для видеовызовов X6.
2 После перевода телефонного вызова в режим Hold телефон периодически отправляет RTP-пакеты для поддержания соединения NAT.
1.3.2 Захват пакетов
На следующем изображении показан отправленный пакет RTP Keep Alive . В пакете, разобранном Wireshark, видно, что кодек обычного вызова — G.711 PCMU, и он отличается от кодека отправленного пакета RTP Keep Alive.
На следующем изображении показан полный пакет RTP Keep Alive.
