Asterisk блокирует пакеты RTP H264 - PullRequest
Новая
       70

Asterisk блокирует пакеты RTP H264

1 голос
/ 27 марта 2012

У меня настроена сеть с 2 UAC за NAT (один - Jitsi, а другой - мой собственный UA, закодированный в C с поддержкой SIP). Asterisk настроен на общедоступный IP-адрес.

В sip.conf у меня есть следующее для обоих UAC: nat = yes directmedia = no

Затем я выполняю свой код, который вызывает клиент Jitsi. Я отвечаю через Jitsi, и все кажется великолепным. Asterisk предоставляет каждому UAC хост / порт RTP для отправки видео через пакет SDP, который я проанализировал соответствующим образом (аудио не включается в этот сеанс). Каждый пользовательский агент начинает передачу пакетов RTP.

Вот где возникает проблема: Звездочки начинают распечатывать

"Получен RTP-пакет из XX.XXX.XX.XXX:XXXXX (тип XX, следующий XXXXX, ts XXXXXx, len XXXXXX)"

неоднократно с обоих UAC, но фактически никогда нигде не отправляет ни одного из пакетов RTP (я бы ожидал «Отправить RTP ....»).

Я протестировал мой код RTP H264 через сервер вещания QuickTime, и пакеты правильно декодируются в локальной сети через различные медиаплееры. У моего SIP-вызова, похоже, нет проблем с подключением, и Asterisk никогда не печатает никаких предупреждений или ошибок в консоли.

Не могу понять, почему Asterisk не пересылает пакеты RTP. Любая помощь будет оценена.

Ответы [ 2 ]

1 голос
/ 27 марта 2012

Во-первых, Asterisk не «удерживает» RTP-пакеты.Существует три способа соединить два UA SIP:

  1. Локальный мост - трафик RTP проходит через Asterisk, но не интерпретируется Asterisk.В этом случае каждый UA направляет свой RTP на Asterisk, и Asterisk повторно передает RTP каждому UA.Выполнено минимальное количество декодирования.
  2. Удаленный мост - в этом случае сигнализация все еще обрабатывается между каждым UA и Asterisk, но Asterisk пересматривает пункт назначения RTP с каждым UA, чтобы быть другим соответствующим UA.В конце концов, каждый UA отправляет свой RTP другому UA напрямую, одновременно отправляя информацию сигнализации SIP в Asterisk.Это минимизирует нагрузку на Asterisk, поскольку трафик RTP напрямую не проходит через него.
  3. Собственный мост - аналогично локальному мосту, трафик RTP от UA поступает в Asterisk.Asterisk полностью декодирует RTP в аудио кадры и управляет передачей аудио кадров.Это происходит, когда Asterisk должен «понять» содержимое трафика RTP, например, при использовании features.conf для передач DTMF.

Параметр directmedia информирует Asterisk о том, что UA оптимально хотят отправлять свои медиамежду собой и обходят звездочку.Он попытается отправить необходимые повторные сообщения INVITE, чтобы настроить этот сценарий, после того как вызов будет установлен обоими UA.

Поскольку вы включили Directmedia для обоих ваших UA, Asterisk попытается разместить их вудаленный мост.Возможно, это не удастся, в зависимости от ряда факторов, но в целом он будет ожидать, что он не находится "в цикле" в отношении передачи RTP туда и обратно между UA.Это объясняет, почему он не пересылает RTP-трафик, который он получает от одного из своих UA.

Я подозреваю, что, поскольку Jitsi хорошо справляется с этим параметром, записанный вами UA не учитывает новый IP-адрес назначения.в SDP отправленного ему повторного ПРИГЛАШЕНИЯ Asterisk, и вместо этого продолжает отправлять RTP в Asterisk, когда вместо этого он должен отправлять его непосредственно в Jitsi UA.

0 голосов
/ 24 мая 2012

Кажется, мне нужно было использовать STUN, чтобы найти мой публичный IP-адрес.

  1. Я перешел с Asterisk на FreeSWITCH.Хотя это не решило мою проблему, я обнаружил, что FreeSWITCH гораздо проще настраивать и отлаживать, что помогло в моем поиске.

  2. Оказывается, что ни FreeSWITCH, ни Asterisk действительно не заботятся о том, какой IP-адрес вы им предоставляете.во время сеанса SIP они просто будут использовать IP-адрес / порт, на который получен пакет (через заголовок IP), для связи.Это смутило меня, потому что я мог позвонить между двумя UAC, но после ответа на звонок аудио / видео носитель никогда не достигнет правильного пункта назначения.Оказывается, реализации RTP будут использовать IP-адрес, указанный в сообщении SDP, при настройке медиапотока, независимо от того, какой IP-адрес SIP использовал для связи.

В конце концов, яиспользовал STUN для обнаружения общедоступного IP-адреса / порта для вызывающего UAC и вставил эту правильную комбинацию IP / порта в сообщение SDP.Впоследствии, когда отвечающий UAC (Jitsi) настроил свой медиапоток, у него теперь была правильная комбинация IP / порта для отправки / получения мультимедиа.

...