Произошла ошибка в моем маршрутизаторе (и других маршрутизаторах от других производителей), который представлял собой двойное сопоставление портов.
разрешение было настроить переадресацию порта с использованием следующих правил:
Команды Аудио: UDP 50000-50019
Команды Видео: UDP 50020-50039
Команды Совместное использование: UDP 50040-50059
вот полные детали объясненияописанной проблемы:
• Из файлов журналов мультимедиа для рабочих и нерабочих вызовов проверки подключения не завершаются все время.Первоначально как в рабочем, так и в нерабочем случаях клиент действительно получает ответ от MP (Media Processor) ip напрямую, как показано ниже: Working
tc :: icemachine :: IceMachineImpl :: ProcessReceive 13:41: 20.835 18208 TL_INFO [19ABA2EF970]: ICEMCHN # 0 ProcessReceive () PipeInfo {UDP, Local: 10.10.10.0: 50006, PalBasedPipe} PipeData {IceData, Encap: Turn, {IP:}, Peer: 104.209.195.0: 50232 , {010100342112a442b3 ...}}
Не работает
tc :: icemachine :: IceMachineImpl :: ProcessReceive 13: 40: 59.885 18208 TL_INFO[19ABA832A20]: ICEMCHN # 0 ProcessReceive () PipeInfo {UDP, Local: 10.10.10.0: 50002, PalBasedPipe} PipeData {IceData, Encap: нет, {IP:}, Peer: 104.209.192.0: 51402 , {000100542112a4423f ...}}
Однако в рабочем вызове хост ip не повышается, и он работает через IP-адрес ретранслятора на 3480
Вывод пар ICEMCHN: Failed IceCandidatePair {P: 0x7efffdfefdfffbfc L: IceCandidate {F: 1 Rtp: {HostUDP, {IP: 10.10.10.0: 50006}, база: 10.10.10.0: 50006, rel: 10.10.10.0: 50006, bw: 0, p: 0x7efffdfe, pipe: UDP}, Rtcp: {Mux}} R: IceCandidate {D, F: 1 Rtp: {StunUDP, {IP: 104.209.195.0: 50232}, base :, rel :, bw: 0, p: 0x7efffdfe, pipe: None}, Rtcp: {Mux}} DL:,}
ICEMCHN Пары Дамп: Succeeded IceCandidatePair {P: 0x0afff5fefdffffcL: IceCandidate {D, F: 5 Rtp: {TurnUDP, {IP: 52.114.188.0: 3480, ID: {864350ac4fd269e1}}, основание: 10.10.10.0: 50006, отн .: 108.168.97.0: 50006, bw: 0,p: 0x0afff5fe, pipe: UDP}, Rtcp: {Mux}} R: IceCandidate {D, F: 1 Rtp: {StunUDP, {IP: 104.209.195.0: 50232}, base :, rel :, bw: 0, p: 0x7efffdfe, pipe: None}, Rtcp: {Mux}} DL: 52.114.188.0: 3480,52.114.188.0: 3480}
В нерабочих журналах нет ответа на пару хостов, а также происходит сбойсбой на резервном пути TL_WARN [19ABA832A20]: ICEMCHN # 0, резервный путь не найден
После обсуждения с группой продуктов мы обнаружили, что 1. Клиент отправляет пакет проверки подключения к MPдля модальности аудио исходный порт 50006, dst порт 53176 Мп получает его, мдобавленный исходный порт - 1026 2. Клиент отправляет пакет проверки подключения к MP для модальности видео, исходный порт - 50032, порт dst - 57270 MP получает его, сопоставленный исходный порт - 1026 3. Клиент отправляет пакет проверки подключения к MP для совместного использования приложения.модальность, порт источника 50052, порт dst 59746 MP получает его, порт источника сопоставления равен 1026
Таким образом, NAT использует один и тот же порт источника для нескольких разных портов источника и назначения.Когда вызов продолжается, клиент отправляет больше пакетов проверки подключения к MP и не получает ответы как для аудио, так и для видео;когда происходит сбой аудио-модальности, вот почему он отказывается от вызова.Однако из журналов MP я могу сказать, что MP фактически получает эти запросы и отвечает на них.
Из трассировок wireshark я мог видеть запрос, отправленный с IP-адреса клиента на IP-адрес медиа-процессоракак указано ниже 6052 37.667639 10.10.10.110 137.116.60.197 STUN 150 Пользователь запроса привязки: nz22: 7IQN Версия 4 интернет-протокола, Src: 10.10.10.110, Dst: 137.116.60.197 Протокол пользовательских дейтаграмм, Порт Src: 50006 ,Порт Dst: 53176
И отправляемый ответ пересылается NAT на другой IP-адрес, как показано ниже
6065 37.733923 137.116.60.197 10.10.10.110 STUN 114 Ответ об успешной привязке XOR-MAPPED-ADDRESS: 108.168.97.86:1026 Интернет-протокол версии 4, Src: 137.116.60.197, Dst: 10.10.10.110 UsПротокол дейтаграмм, порт Src: 53176, порт Dst: 50058 XOR-MAPPED-ADDRESS: 108.168.97.86:1026
Из приведенного выше трафика ясно видно, что трафик был отправлен с MPмаршрутизируется на NAT (108.168.97.86:1026) и изменяет порт источника.NAT неправильно поддерживает сопоставления и перенаправляет все принятые пакеты через порт 1026 на один и тот же порт источника, вероятно, 50052, который работал.50052, вероятно, получает все, что прибывает в 1026, и именно поэтому я вижу следы отброшенных пакетов, поскольку его принимающие пакеты должны действительно идти к 50032 или 50006.
Основываясь на наших исследованиях и анализе, это кажется NATотображения.Как видно из трассировки Wireshark, NAT пересылает все полученные пакеты через порт 1026 на один и тот же исходный порт , вероятно, 50052, который используется для общего доступа к приложениям, и в журналах я мог видеть успешную модальность совместного использования приложений, котораяработал. Проблема в том, что NAT не хранит отдельные пути .Он заканчивается таким образом, что трафик со всех 3-х портов сервера направляется на один и тот же частный порт, в данном случае 50052.
NAT может выбрать для этих частных портов отдельные публичные порты или для этихчастные порты тот же публичный порт, как и здесь.любой способ действителен. Дело в том, что если вы решите повторно использовать один и тот же общедоступный порт, то единственный способ узнать, какой правильный частный порт предназначен для пересылки трафика, - это отслеживать, из какого пункта назначения трафик поступает или отправляется,что NAT, возможно, здесь не делает . Первое, что клиент групп делает с этого порта источника (то есть 50006), это отправляет трафик распределения на его ретранслятор.Это первый выходной медиа-пакет, который увидит NAT.Часто NAT будут пытаться дать этому трафику тот же общедоступный порт, что и частный порт, и фактически этот NAT, похоже, делает это - порт, который ретранслятор видел на NAT, был таким же, как частный порт 50006 (то же самое свидео и обмен приложениями).1026 не входил в игру, пока NAT не увидел пакеты с того же исходного порта, привязанного к разным адресатам - в данном случае MP.Таким образом, первый пакет от 50006, предназначенный для ретранслятора, был назначен общедоступным портом 50006 NAT.Однако пакет от того же самого частного порта, предназначенного для MP (другой ip и порт чем ретранслятор), получил порт источника 1026 NAT.Сервер на самом деле пытается отправить пакет непосредственно на IP-адрес компьютера, но этот IP-адрес является частным IP-адресом, поэтому пакет никогда не будет приближаться к машине.Сервер также пытается отправить пакет на общедоступный IP-адрес, который клиент отправил в своем предложении.Обычно это происходит до того, как клиент готов принять пакет, и поэтому большинство NAT отбрасывают эти пакеты.