![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() |
![]()
Сообщение
#1
|
|
![]() Продвинутый пользователь ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 127 Регистрация: 30.6.2011 Из: Алматы, Казахстан Пользователь №: 16095 ![]() |
Есть iPECS-LIK100 (5.5Eg) + Dtim8(4.0Lc)
Два из шести каналов Voip на процессоре, используюься для связи по H.323!!! С исходящей проблем нет, а вот входящая всегда односторонняя!! Снял сниф, исходящего и входящего звонка: Заметил, что при исходящем звонке с моей стороны предлогается использовать порты 73XX. Противоположная сторона начинает слать RTP-пакеты на порт 73XX. Связь двусторонняя! При входящем звонке вижу что моя сторона использует sourse port 7300, но в ответе Call Proceeding OLC указывает порт 56477. В итоге исходящие пакеты уходят с порта 7300 и противопожная сторона слышит меня, а входящие пакеты приходят на порт 56477. И у меня в трубке тишина!!! Откуда берется этот порт? Его даже в rp info нет!!! Не могу понять!!! Подскажите кто-нибудь! Что-нибудь!!! 7277110 => 6883 это исходящий звонок! 6730 => 7110 это входящий звонок
Прикрепленные файлы
|
|
|
![]() |
![]()
Сообщение
#2
|
|
Частый гость ![]() ![]() ![]() Группа: Участники Сообщений: 67 Регистрация: 20.8.2009 Из: Харьков Пользователь №: 13655 ![]() |
Посмотрите сообщение 4959 ( connect OpenLogicalChannel ) там в OLC forwardlogicalchannel RTP 109.238.160.94:55000 RTCP network: 10.10.2.79:7301
А в сообщении 4666 (callProceeding OpenLogicalChannel) RTP 109.238.160.94:56477 Т.е. похоже на проблему в переназначении TSAP в call proceeding, и что кстати странно, RTP порт должен быть четным Еще раз перечитал посты, не заметил данных по трассе со стороны LAN, скорее всего неправильно отрабатывает H323-ALG, если IP WAN статический легче настроить IP FIREWALL как средство преодоления NAT, т.е. чтобы станция сама указывала IP WAN как TSAP в OLC. Или для текущего сеанса можно на маршрутизаторе со стороны WAN пробросом порта 56477 на 7302 |
|
|
![]()
Сообщение
#3
|
|
![]() Продвинутый пользователь ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 127 Регистрация: 30.6.2011 Из: Алматы, Казахстан Пользователь №: 16095 ![]() |
Посмотрите сообщение 4959 ( connect OpenLogicalChannel ) там в OLC forwardlogicalchannel RTP 109.238.160.94:55000 RTCP network: 10.10.2.79:7301 А в сообщении 4666 (callProceeding OpenLogicalChannel) RTP 109.238.160.94:56477 Т.е. похоже на проблему в переназначении TSAP в call proceeding, и что кстати странно, RTP порт должен быть четным Тот трейс который вы смотрите был снят после маршрутизатора!!! и адрес 109.238.160.94 маршрутизатор похоже подставляет сам! в тех трейсах которые на ifolder.ru можно сравнить что атс посылает, и как поля меняются поле маршрутизатора! сниф был снят одновременно!!!! Т.е. LIK trace H.323 LG LAN.pcap и LIK trace H.323 LG WAN.pcap это два трейса одного и того же звонка!!! Еще раз перечитал посты, не заметил данных по трассе со стороны LAN, скорее всего неправильно отрабатывает H323-ALG, если IP WAN статический легче настроить IP FIREWALL как средство преодоления NAT, т.е. чтобы станция сама указывала IP WAN как TSAP в OLC. Или для текущего сеанса можно на маршрутизаторе со стороны WAN пробросом порта 56477 на 7302 Я ведь и спрашивал как сделать так чтоб станция сама указывала IP WAN в OLC!!! у меня это не получается.... на MG там указан адрес WAN и связь двусторонняя!!!! А проброс портов 56477 на 7302 врятли думаю поможет потому что: Гляньте.. после сообщения 4959 ( connect OpenLogicalChannel ) прекращаются RTP-пакеты с противоположной стороны!!! идут только с моей стороны!!! лучше смотреть трейсы которые выложены на файлообменнике! там снифы одного и того же звонка до маршрутизатора и после!!! |
|
|
![]() ![]() |
Текстовая версия | Сейчас: 16.6.2025, 16:54 |