Имеем:
патаюсь соединть три станции следующим способом:
11С rel 4.5 - h323 - 81C rel 6.0 - sip - ipldk 60
11я с 81й работают отлично, 81я с лдк то же, а вот при звонке с 11й на лдк, и с лдк на 11ю вообще нет слышимости в обе стороны. Т.е. происходит коннект, а дальше тишина.
Причем на 11й выпадает ошибка PRI0254
Database Error: The DCH is interfacing with a software issue not supported by
the application. Output data: DCH: x DATA: y z . Where:
x = D-channelnumber y = Release ID
z = Service identifier
Action: Verify that the release ID in the configuration record is the same as the
software release running on the far end switch.
If available, turn on the Alarm Filtering Package (#243) or Upgrade all the ISDN
MCDN switches to the same software Release.
Не могу понять на что ругается станция, ведь нет прямого соединения лдк и 11С, все работает через большую. По отдельности норм, а вместе не хотят.
Попробовал еще просто подвязать лыжу на h323 на НРС. Опять те же грабли и та же ошибка. Между собой станции не хотят работать, хотя с большой обе работают отлично.
Никаких проблем с сетью, файерволами и т.п. нет.
Имеем:
патаюсь соединть три станции следующим способом:
11С rel 4.5 - h323 - 81C rel 6.0 - sip - ipldk 60
11я с 81й работают отлично, 81я с лдк то же, а вот при звонке с 11й на лдк, и с лдк на 11ю вообще нет слышимости в обе стороны. Т.е. происходит коннект, а дальше тишина.
Голосовой траффик (RTP) идёт напрямую между конечными станциями. Есть IP-маршрутизация между ними?
При схеме h323 - sip, разве то же так будет?
Да, все станции находятся в одной сети, никакие маршрутизаторы на пути не стоят. Все друг друга видят и пингуют.
Традиционно глубокие самостоятельные размышления над проблемой, после чтения доки по IP Peer Networking, а также присутствующие в описании проблемы трейсы.
Конечно же, автор не рассчитывал, что ему вместо всего этого ему на форуме все разжуют, расскажут и чудесным образом догадаются, как устроена его сеть, все ли он так настроил и что происходит в сигнальном обмене между элементами.
Это такой очередной намек на то, чего традиционно не хватает в описании проблемы и подходе к ней.
Если бы проблема была с сетью, то я сам бы без проблем разобрался. Но в данном случае все станции сидят а одной l2 сети и проблем с прохождением траффика нет.
Прежде всего я создавал тему для того, что бы узнать, сталкивался ли кто либо с ошибкой PRI 254, при построении сети на ip, и нужно ли серьезно к ней относиться.
И возможно ли, что у лдк и 11С разные версии h323, которые в принципе не совместимы друг с другом.
Причем здесь версии H.323 у 11C и LDK, если по вашей схеме они по H.323 не взаимодействуют ?
В первом посте внизу есть фраза о том, что я пробовал и по h323 их связать. Тот же результат.
Сигнализационные сообщения ходят нормально (кпв, занятость, отбой), RTP не ходит. Точнее в данный момент я смотрел только с одной - со стороны лыжи wiresharkom, RTP улетает в сторону 11С, но оттудава тишина.
И тишина в трубках.
В вайершарке к тому же видно, что проблема не с кодеками, т.к. о кодеках они договариваются и соединение устанавливается.
Т.е. будете продолжать играть в телепатов, вместо описания схемы, настроек и выкладывания трейсов, намеки не действуют.
Например, из вашей писанины неясно, на 11С у вас IP Trunk, или она все же CS1000.
Ну, продолжайте в том же духе.
на 11й ip trunk без сигнального сервера
IPT-3.01.60_01_31_2005.6893,
MC Firmware Rls 8.4
81я cs1000
на cppm поднят nrs и два домена h323 и sip. По RAS h323 привязан ip trunk с 11й. Лдк привязана как статический sip endpoint.
Во вложении трейс звонка с лдк на 11ую.
172.30.0.20 - адрес лдк
172.30.0.11 - адрес НРС 81й
172.30.0.50 - адрес ip транка
7049
Большое спасибо за чудный трейс, в котором видно и обмен по Н.323, и обмен по SIP, и содержимое SDP.
А я-то думал, просто картинку пришлете. Скриншот, так сказать.
на 11й ip trunk без сигнального сервера
IPT-3.01.60_01_31_2005.6893,
Откровенно говоря на IP Trunk реализация H323 весьма своебразная, чужаков не признает и работает только в рамках SL1:D
Так в верхней схеме IPT c CS1K работает, по SL1 т.е.
Так в верхней схеме IPT c CS1K работает, по SL1 т.е.
А чего ж ей не работать? CS1K и с лыжей работает. А кто обещал что IPT с лыжей будет работать? 6-й релиз и с другими релизами не всегда корректно работает в плане слышимости:(
Так в верхней схеме нету общения IPT с лыжей по H.323, есть транзит H.323-SIP через CS1K MultiGroup.
Большое спасибо за чудный трейс, в котором видно и обмен по Н.323, и обмен по SIP, и содержимое SDP.
А я-то думал, просто картинку пришлете. Скриншот, так сказать.
откровенно не очень понимаю ваши "юморные" высказывания.
Пока есть возможность сделать трейс только с одной стороны.
Откровенно говоря на IP Trunk реализация H323 весьма своебразная, чужаков не признает и работает только в рамках SL1
Да я вот то же как то грешу на это. Уже не один день ковыряюсь, все настройки уже перепробывал.
Подключал даже лыжу по h323. В итоге те же грабли - лыжа с 81й нормально, 11я с 81й то же, а вот транзит с лыжи на 11ю приводит к тишине с обеих сторон.
Печальненько, по ходу придется опять строить ip вынос для Лыж на какой нить железке, которая будет смотреть на лыжи по h323, а в 81ю потоком E1.
Сейчас у нас для этого Квинтум используется. Хотелось уйти от этих костылей, но видимо не судьба(
Так в верхней схеме нету общения IPT с лыжей по H.323, есть транзит H.323-SIP через CS1K MultiGroup.
Такая схема то вообще жизнеспособна? ктонить пробовал на практике?
....
Сейчас у нас для этого Квинтум используется. Хотелось уйти от этих костылей, но видимо не судьба...
Что бы не использовать костели нужно использовать более современное железо и софт.
P.S. Про то, что дорого, говорить не надо, за реализацию желаний и хотелок, нужно платить. :)
Что бы не использовать костели нужно использовать более современное железо и софт.
P.S. Про то, что дорого, говорить не надо, за реализацию желаний и хотелок, нужно платить.
т.е. без апгрейда 11й до полноценного CS1000 актуального релиза, такая схема маловероятно, что заработает?
Очень интересно послушать, а что мешает вам снять трейсы и H.323, и SIP ?
Даже без портмиррора, на сигнальнике CS1K MG ?
т.е. без апгрейда 11й до полноценного CS1000 актуального релиза, такая схема маловероятно, что заработает?
Документация утверждает что должно работать. Проверять настройки, трясти производителя.
To Senar: А напрямую M11 с LG связать не пробовали, по H.323 (выше правда ссылка мн.уваж. Urri, что работать не будет)?
У меня была сходная ситуация на транзите
AlterCallSystem (H.323)-> CS1000 (H.323)-> Mera
Тоже проходил вызов без голоса. Проблему решило прямое соединение
ACS(H.323)->Mera.
Очень интересно послушать, а что мешает вам снять трейсы и H.323, и SIP ?
Даже без портмиррора, на сигнальнике CS1K MG ?
Пока не очень разобрался как на новом сигнальнике rel 6.0 включить просмотр трейсов... разбираюсь.
To Senar: А напрямую M11 с LG связать не пробовали, по H.323 (выше правда ссылка мн.уваж. Urri, что работать не будет)?
У меня была сходная ситуация на транзите
AlterCallSystem (H.323)-> CS1000 (H.323)-> Mera
Тоже проходил вызов без голоса. Проблему решило прямое соединение
ACS(H.323)->Mera.
Мне такой вариант не подходит. В центре должна быть узловая 81я, а 11С и лдк это просто небольшие выносы.
К тому же, на Лыже нельзя прописать, что бы она маршрутизировала звонки на два разных гейткипера.
Такое ощущение, что itg, как то странно отрабатывает RTP траффик, если он идет не от 81го Мерина.
Попробовал еще одну схему.
У нас есть Астериск, подвязанный по sip к 81й.
Т.е. схема
Астер - sip - 81я - h323 - ldk
Т.е. по сути все то же самое, кроме того, что вместо 11й с картой itg выступает ldk.
В итоге все нормально работает в обе стороны.
Похоже, действительно, itg карточка не хочет нормально работать, если вызов приходит по ip не от Меридиана.
Мне такой вариант не подходит. В центре должна быть узловая 81я, а 11С и лдк это просто небольшие выносы.
К тому же, на Лыже нельзя прописать, что бы она маршрутизировала звонки на два разных гейткипера.
А Зачем 2 гейткипера? Пропиши в статике. Лыжа это умеет через networking.
Такое ощущение, что itg, как то странно отрабатывает RTP траффик, если он идет не от 81го Мерина.
А тут точно, вопросов вагон и с itg и с bcm.
Кстати, для них очень важно СОГЛАСОВАТЬ параметры кодеков .
Похоже, действительно, itg карточка не хочет нормально работать, если вызов приходит по ip не от Меридиана.
В вашей начальной схеме вызов приходит "по IP" от CS1K.
Но чтобы это подтвердить, надо смотреть трассировку. Не можете сделать на самом сигнальнике - сделайте через миррор его порта ТLAN.
Лучше и порта ТLAN сигнальника, и порта ТLAN ITG.
И нужна трассировка, а нее скриншот.
А Зачем 2 гейткипера? Пропиши в статике. Лыжа это умеет через networking.
В принципе то можно попробовать, но как тогда быть с обратной маршрутизацией с itg? В ней то жестко прописан гейткипер.
А тут точно, вопросов вагон и с itg и с bcm.
Кстати, для них очень важно СОГЛАСОВАТЬ параметры кодеков .
По кодекам они вполне себе нормально договариваются, на itg это видно если командой посмотреть состояние установившегося соединения.
В вашей начальной схеме вызов приходит "по IP" от CS1K.
Но чтобы это подтвердить, надо смотреть трассировку. Не можете сделать на самом сигнальнике - сделайте через миррор его порта ТLAN.
Лучше и порта ТLAN сигнальника, и порта ТLAN ITG.
И нужна трассировка, а нее скриншот.
Попробую, с этим не все так просто. Вызов то приходит, сигнализация нормально отрабатывается. А вот дальше, что видно по "скриншоту" начинает идти RTP траффик, напрямую от хоста к хосту. Вот в нем, собственно, как я понимаю, и проблема.
По скриншоту не видно содержимое SDP и H.245.
В принципе то можно попробовать, но как тогда быть с обратной маршрутизацией с itg? В ней то жестко прописан гейткипер.
Если лыжа прописана в nrs, то все будет нормально.
По кодекам они вполне себе нормально договариваются, на itg это видно если командой посмотреть состояние установившегося соединения.
Нормально, ага, а потом rtp нету.
Они при несогласованности кодеков между собой не всегда договориться могут. Не говоря уже о стороннем оборудовании.