Проблемы односторонней передачи аудиоданных с SIP по AT&T
У меня есть клиент, у которого есть VoIP PBX, подключенный к оптоволоконному соединению Уровня 3. У него есть офисы все по всей стране использование различного ISPs. Два из тех офисов используют AT&T, обоих в различных состояниях. Каждый - T1, другой DSL. В течение прошлой недели, каждый день около полудня EST, оба сайта AT&T имеют односторонние речевые проблемы, где они не могут услышать другую сторону. Это длится остальную часть дня. Следующим утром вещи хорошо работают снова до полудня. Телефонные журналы показывают, что не получают поток RTP. Все другие сайты неAT&T хорошо работают. Я сделал, чтобы они попытались подключить свои телефоны к другим системам на другом ISPs (один на Comcast, один на Уровне 3 и один на Мегапути) без успеха. Я сделал, чтобы они включили телефон непосредственно в маршрутизатор T1 с общедоступным IP, обойдя NAT/брандмауэр, без успеха. Я изменил порты SIP и RTP на нестандартные порты без успеха.
Я координирую с ними для установки захвата пакетов на дальнем конце, в то время как я делаю захват пакетов на PBX, но я надеялся узнать, встретились ли другие с односторонними речевыми проблемами с AT&T недавно, и если так, как Вы смогли разрешить проблему.
Только резюмировать:
- 2 различных офиса в 2 различных состояниях на AT&T одновременно испытывают односторонние речевые проблемы каждый день, начиная около полудня. Вся их другая прекрасная офисная работа неAT&T.
- 2 офиса, которые затронуты, имеют различные коммутаторы и маршрутизаторы.
- Попытка другого PBXes на другом ISPs не устранила проблему.
- Устанавливание настройки телефона с общедоступным IP и обходом LAN и NAT не устраняет проблему.
- Используя нестандартный SIP & RTP порты не устранили проблему.
- Я попробовал как много изменений всего вышеупомянутого, о котором я мог думать без изменения.
Я делал это в течение 8 лет и никогда ничего не видел вполне как это.
Одностороннее аудио с SIP/RTP вызовами вызвано тем, что одна из пар RTP потоков не установлена. Это либо проблема маршрутизации (т.е. NAT), либо проблема с брандмауэром. По умолчанию, SIP обычно приводит к тому, что RTP-потоки создаются по UDP с портами назначения с обеих сторон между 10000-20000 или 16384-32768. Обе стороны должны иметь возможность установить нежелательное исходящее соединение с другой стороной (т.е. НОВОЕ соединение с точки зрения conntrack). Брандмауэры с контролем состояния соединений, разработанные для предотвращения входящих соединений, являются распространенной причиной этого, когда NAT не является проблемой.
Конечно, может быть так, что провайдер перемешивает пакеты и препятствует соединению, но это очень маловероятно, если у вас есть бизнес-подключение любого типа. Имейте в виду, что это брандмауэры на обеих сторонах.
.