Есть 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 это входящий звонок
Полная версия этой страницы: Односторонние входящие по H.323
Цитата(Александр Т. @ 27.2.2012, 14:34) 
Есть 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 это входящий звонок
Два из шести каналов Voip на процессоре, используюься для связи по H.323!!!
С исходящей проблем нет, а вот входящая всегда односторонняя!!
Снял сниф, исходящего и входящего звонка:
Заметил, что при исходящем звонке с моей стороны предлогается использовать порты 73XX.
Противоположная сторона начинает слать RTP-пакеты на порт 73XX.
Связь двусторонняя!
При входящем звонке вижу что моя сторона использует sourse port 7300,
но в ответе Call Proceeding OLC указывает порт 56477.
В итоге исходящие пакеты уходят с порта 7300 и противопожная сторона слышит меня, а входящие пакеты приходят на порт 56477. И у меня в трубке тишина!!!
Откуда берется этот порт? Его даже в rp info нет!!!
Не могу понять!!!
Подскажите кто-нибудь! Что-нибудь!!!
7277110 => 6883 это исходящий звонок!
6730 => 7110 это входящий звонок
А у вас все порты нужные проброшены на роутере? В частности, 7300??
http://www.artcom.ru/_files/Download/Docs/...5_APR152010.rar
Цитата(Dron @ 27.2.2012, 16:39)
А у вас все порты нужные проброшены на роутере? В частности, 7300??
http://www.artcom.ru/_files/Download/Docs/...5_APR152010.rar
http://www.artcom.ru/_files/Download/Docs/...5_APR152010.rar
Порты да! Проброшены!
7000 - 7011
7100 - 7111
7300 - 7311
ну и
50000 - 57000 прокинул
Это кстати сниф перед маршрутизатором! Со стороны WAN!
Цитата(Александр Т. @ 27.2.2012, 14:45)
Порты да! Проброшены!
7000 - 7011
7100 - 7111
7300 - 7311
ну и
50000 - 57000 прокинул
Это кстати сниф перед маршрутизатором! Со стороны WAN!
7000 - 7011
7100 - 7111
7300 - 7311
ну и
50000 - 57000 прокинул
Это кстати сниф перед маршрутизатором! Со стороны WAN!
Что то на кривой NAT смахивает...
Что за роутеры используются?
Цитата(Dron @ 27.2.2012, 16:49)
Что то на кривой NAT смахивает...
Кстати сейчас просматриваю сниф между атс и маршрутизатором!
Правда звонок с другой атс! И вижу что там при входящем звонке указывается порт 7302, и ip локальный!
Попробую сейчас еще раз сниф снять но уже между маршрутизатором и атс!
Цитата(Dron @ 27.2.2012, 16:49)
Что за роутеры используются?
Lincsys WRT-120n
Цитата harris ®-а
Вот что... А попробуйте в ПГМ132 для модулей/телефонов, расположенных в основной сетке (192.168.10.0) указать адрес роутера = 192.168.10.1 (т.е. повторить то, что прописано для MFIM).
Кажется, что я где-то читал, что при использовании устройств Local-Remote (LO) адреса роутеров прописываются как для устройств Local-Remote (LO), так и для Local (L).
Вот что... А попробуйте в ПГМ132 для модулей/телефонов, расположенных в основной сетке (192.168.10.0) указать адрес роутера = 192.168.10.1 (т.е. повторить то, что прописано для MFIM).
Кажется, что я где-то читал, что при использовании устройств Local-Remote (LO) адреса роутеров прописываются как для устройств Local-Remote (LO), так и для Local (L).
выписка из мануала по этому поводу:
Для использования возможности подключения управляемой WAN, системе iPECS могут быть назначены IP адреса маршрутизатора для всех устройств, которые могут делать попытку соединения точка-точка через управляемую WAN, включая элементы системы в LAN iPECS. Необходимо обратить внимание, что если девайсу не назначен IP адрес маршрутизатора, то система будет использовать IP адрес маршрутизатора в системе и план IP адресов элементов системы.
Для использования возможности подключения управляемой WAN, системе iPECS могут быть назначены IP адреса маршрутизатора для всех устройств, которые могут делать попытку соединения точка-точка через управляемую WAN, включая элементы системы в LAN iPECS. Необходимо обратить внимание, что если девайсу не назначен IP адрес маршрутизатора, то система будет использовать IP адрес маршрутизатора в системе и план IP адресов элементов системы.
Цитата(stasmar @ 27.2.2012, 16:58)
Цитата harris ®-а
Вот что... А попробуйте в ПГМ132 для модулей/телефонов, расположенных в основной сетке (192.168.10.0) указать адрес роутера = 192.168.10.1 (т.е. повторить то, что прописано для MFIM).
Кажется, что я где-то читал, что при использовании устройств Local-Remote (LO) адреса роутеров прописываются как для устройств Local-Remote (LO), так и для Local (L).
Вот что... А попробуйте в ПГМ132 для модулей/телефонов, расположенных в основной сетке (192.168.10.0) указать адрес роутера = 192.168.10.1 (т.е. повторить то, что прописано для MFIM).
Кажется, что я где-то читал, что при использовании устройств Local-Remote (LO) адреса роутеров прописываются как для устройств Local-Remote (LO), так и для Local (L).
Для sequens'a Voip GW адресс роутера не назначается, так как это каналы процессора!
а на остальных модулях ip роутера прописан!
Сделал сниф между атс и маршрутизатором:
при входящем вызове, вижу что порт 7300 используется и локальный ip...
ну и rtp - пакеты туда - сюда гуляют.... на первый взгляд все нормально!!!
только вот почему-то когда декодирую, могу прослушать только свой разговор...
а те пакеты которые приходят от противоположной стороны такое ощущение как будто пустые!!!
Есть два трейса со стороны интернета (LIK trace H.323 LG WAN) и со стороны АТС (LIK trace H.323 LG LAN)
Если сравнить:
(LIK trace H.323 LG LAN)
Пакет №6691: с моей стороны отправился ответ "H.225 Connect OpenLogicalChannel"
В Fast Start'e....
Item 0
Audio Data: G711Allaw64k
Media Channel:
IpAddress: 10.10.2.79 (указывается локальный iP-адресс и номер порта 7302)
Media Control Chanel:
IpAddress: 10.10.2.79 и порт 7303
Item 1
Audio Data: G711Allaw64k
IpAddress: 10.10.2.79 (указывается локальный iP-адресс АТС и номер порта 7303)
(LIK trace H.323 LG WAN)
Пакет №3661: с моей стороны отправился ответ "H.225 Connect OpenLogicalChannel"
В Fast Start'e....
Item 0
Audio Data: G711Allaw64k
Media Channel:
IpAddress: 109.238.160.94 (указывается адресс Firewall'a и номер порта 55011)
Media Control Chanel:
IpAddress: 10.10.2.79 и порт 7303
Item 1
Audio Data: G711Allaw64k
IpAddress: указывается локальный iP-адресс АТС и номер порта 7303
После этого входящие RTP-пакеты проподают!!
Есть только исходящие!!!
В итоге получается!! что маршрутизатор меняет ip-адресс медиа канала на firewall!
Причем, в исходящих RTP маршрутизатор также меняет порт с 7302 на 7312
Может быть в ответе "H.225 Connect OpenLogicalChannel" LIK сам должен подставлять firewall ????
Протестировал на MG!!
Связь с пол пинка заработала!!!
Снял сниф!!! В тех полях где при входящем звонке на LIK указывается локальный IP-адресс, на MG указывается IP-адресс firewall!!!!
По аналогии с Sip'ом на MG помню устанавливал на линиях VOIP FW Usage в ON и тогда при входящем звонке в ответном 200OK в описании SDP указывался адресс Farewall для RTP-пакетов!!!
если в Off - указывался локальный ip
Какой параметр нужно поменять на LIK? чтоб его!!! =) хе хех!!!
кстати на момент трейса на MG, в CO Line Attribute, VOIP FW Usage был выставлен в ON!!
Протестировать вы выкл. пока не успел!!!
На сегодня хватит! )
Тут есть трейсы!
http://ifolder.ru/29028694
Если сравнить:
(LIK trace H.323 LG LAN)
Пакет №6691: с моей стороны отправился ответ "H.225 Connect OpenLogicalChannel"
В Fast Start'e....
Item 0
Audio Data: G711Allaw64k
Media Channel:
IpAddress: 10.10.2.79 (указывается локальный iP-адресс и номер порта 7302)
Media Control Chanel:
IpAddress: 10.10.2.79 и порт 7303
Item 1
Audio Data: G711Allaw64k
IpAddress: 10.10.2.79 (указывается локальный iP-адресс АТС и номер порта 7303)
(LIK trace H.323 LG WAN)
Пакет №3661: с моей стороны отправился ответ "H.225 Connect OpenLogicalChannel"
В Fast Start'e....
Item 0
Audio Data: G711Allaw64k
Media Channel:
IpAddress: 109.238.160.94 (указывается адресс Firewall'a и номер порта 55011)
Media Control Chanel:
IpAddress: 10.10.2.79 и порт 7303
Item 1
Audio Data: G711Allaw64k
IpAddress: указывается локальный iP-адресс АТС и номер порта 7303
После этого входящие RTP-пакеты проподают!!
Есть только исходящие!!!
В итоге получается!! что маршрутизатор меняет ip-адресс медиа канала на firewall!
Причем, в исходящих RTP маршрутизатор также меняет порт с 7302 на 7312
Может быть в ответе "H.225 Connect OpenLogicalChannel" LIK сам должен подставлять firewall ????
Протестировал на MG!!
Связь с пол пинка заработала!!!
Снял сниф!!! В тех полях где при входящем звонке на LIK указывается локальный IP-адресс, на MG указывается IP-адресс firewall!!!!
По аналогии с Sip'ом на MG помню устанавливал на линиях VOIP FW Usage в ON и тогда при входящем звонке в ответном 200OK в описании SDP указывался адресс Farewall для RTP-пакетов!!!
если в Off - указывался локальный ip
Какой параметр нужно поменять на LIK? чтоб его!!! =) хе хех!!!
кстати на момент трейса на MG, в CO Line Attribute, VOIP FW Usage был выставлен в ON!!
Протестировать вы выкл. пока не успел!!!
На сегодня хватит! )
Тут есть трейсы!
http://ifolder.ru/29028694
Цитата(Александр Т. @ 1.3.2012, 16:05)
Есть два трейса со стороны интернета (LIK trace H.323 LG WAN) и со стороны АТС (LIK trace H.323 LG LAN)
Если сравнить:
(LIK trace H.323 LG LAN)
Пакет №6691: с моей стороны отправился ответ "H.225 Connect OpenLogicalChannel"
В Fast Start'e....
Item 0
Audio Data: G711Allaw64k
Media Channel:
IpAddress: 10.10.2.79 (указывается локальный iP-адресс и номер порта 7302)
Media Control Chanel:
IpAddress: 10.10.2.79 и порт 7303
Item 1
Audio Data: G711Allaw64k
IpAddress: 10.10.2.79 (указывается локальный iP-адресс АТС и номер порта 7303)
(LIK trace H.323 LG WAN)
Пакет №3661: с моей стороны отправился ответ "H.225 Connect OpenLogicalChannel"
В Fast Start'e....
Item 0
Audio Data: G711Allaw64k
Media Channel:
IpAddress: 109.238.160.94 (указывается адресс Firewall'a и номер порта 55011)
Media Control Chanel:
IpAddress: 10.10.2.79 и порт 7303
Item 1
Audio Data: G711Allaw64k
IpAddress: указывается локальный iP-адресс АТС и номер порта 7303
После этого входящие RTP-пакеты проподают!!
Есть только исходящие!!!
В итоге получается!! что маршрутизатор меняет ip-адресс медиа канала на firewall!
Причем, в исходящих RTP маршрутизатор также меняет порт с 7302 на 7312
Может быть в ответе "H.225 Connect OpenLogicalChannel" LIK сам должен подставлять firewall ????
Протестировал на MG!!
Связь с пол пинка заработала!!!
Снял сниф!!! В тех полях где при входящем звонке на LIK указывается локальный IP-адресс, на MG указывается IP-адресс firewall!!!!
По аналогии с Sip'ом на MG помню устанавливал на линиях VOIP FW Usage в ON и тогда при входящем звонке в ответном 200OK в описании SDP указывался адресс Farewall для RTP-пакетов!!!
если в Off - указывался локальный ip
Какой параметр нужно поменять на LIK? чтоб его!!! =) хе хех!!!
кстати на момент трейса на MG, в CO Line Attribute, VOIP FW Usage был выставлен в ON!!
Протестировать вы выкл. пока не успел!!!
На сегодня хватит! )
Тут есть трейсы!
http://ifolder.ru/29028694
Если сравнить:
(LIK trace H.323 LG LAN)
Пакет №6691: с моей стороны отправился ответ "H.225 Connect OpenLogicalChannel"
В Fast Start'e....
Item 0
Audio Data: G711Allaw64k
Media Channel:
IpAddress: 10.10.2.79 (указывается локальный iP-адресс и номер порта 7302)
Media Control Chanel:
IpAddress: 10.10.2.79 и порт 7303
Item 1
Audio Data: G711Allaw64k
IpAddress: 10.10.2.79 (указывается локальный iP-адресс АТС и номер порта 7303)
(LIK trace H.323 LG WAN)
Пакет №3661: с моей стороны отправился ответ "H.225 Connect OpenLogicalChannel"
В Fast Start'e....
Item 0
Audio Data: G711Allaw64k
Media Channel:
IpAddress: 109.238.160.94 (указывается адресс Firewall'a и номер порта 55011)
Media Control Chanel:
IpAddress: 10.10.2.79 и порт 7303
Item 1
Audio Data: G711Allaw64k
IpAddress: указывается локальный iP-адресс АТС и номер порта 7303
После этого входящие RTP-пакеты проподают!!
Есть только исходящие!!!
В итоге получается!! что маршрутизатор меняет ip-адресс медиа канала на firewall!
Причем, в исходящих RTP маршрутизатор также меняет порт с 7302 на 7312
Может быть в ответе "H.225 Connect OpenLogicalChannel" LIK сам должен подставлять firewall ????
Протестировал на MG!!
Связь с пол пинка заработала!!!
Снял сниф!!! В тех полях где при входящем звонке на LIK указывается локальный IP-адресс, на MG указывается IP-адресс firewall!!!!
По аналогии с Sip'ом на MG помню устанавливал на линиях VOIP FW Usage в ON и тогда при входящем звонке в ответном 200OK в описании SDP указывался адресс Farewall для RTP-пакетов!!!
если в Off - указывался локальный ip
Какой параметр нужно поменять на LIK? чтоб его!!! =) хе хех!!!
кстати на момент трейса на MG, в CO Line Attribute, VOIP FW Usage был выставлен в ON!!
Протестировать вы выкл. пока не успел!!!
На сегодня хватит! )
Тут есть трейсы!
http://ifolder.ru/29028694
Используете 324 программу? А что там для Firewall Routing? Если я все правильно понял, что то уже соображается плохо...
Цитата(Dron @ 1.3.2012, 18:39)
Используете 324 программу? А что там для Firewall Routing? Если я все правильно понял, что то уже соображается плохо...
324-ю да!!! Использую!!!
Firewall Routing - ON!!!
Этот параметр для входящей тоже используется???
Цитата(Александр Т. @ 2.3.2012, 6:52)
324-ю да!!! Использую!!!
Firewall Routing - ON!!!
Этот параметр для входящей тоже используется???
Firewall Routing - ON!!!
Этот параметр для входящей тоже используется???
Board Base Attributes(132) [N] --> Firewall IP Address, RTP Packet Relay Firewall IP Address??
Цитата(Dron @ 2.3.2012, 11:05)
Board Base Attributes(132) [N] --> Firewall IP Address, RTP Packet Relay Firewall IP Address??
В 132 PGM
Firewall IP Address прописан для всех сиквенсов!
RTP Packet Relay Firewall IP Address прописан только для Voip GW!
Для Dtim не прописывается!!!
ток честно сказать я на абум его прописал потому что не нашел информации по его использованию!!
Посмотрите сообщение 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
А в сообщении 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
Цитата(mike71 @ 2.3.2012, 16:26)
Посмотрите сообщение 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 порт должен быть четным
А в сообщении 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 это два трейса одного и того же звонка!!!
Цитата(mike71 @ 2.3.2012, 16:26)
Еще раз перечитал посты, не заметил данных по трассе со стороны 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-пакеты с противоположной стороны!!!
идут только с моей стороны!!!
лучше смотреть трейсы которые выложены на файлообменнике!
там снифы одного и того же звонка до маршрутизатора и после!!!
я бы по возможности проверил лог на другой стороне ( H.323 GK или шлюз ). По идее ALG на роутере подменяет транспортные для RTP на внешние, но вот почему с удаленной стороны нет RTP потока на них непонятно. Кроме того, возможно в фазе call proceeding по RTP с удаленной стороны идут сигналы КПВ или речевые извещения. А вот в фазе после ответа вызываемого (получение сообщения connect) на той стороне хорошо бы посмотреть события и ошибки.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.