Здравствуйте. Есть такая задача у меня, необходимо систему HiPath 3800 связать потоком с Cisco. Я это сделал, поток поднялся, индикаторы аварий не горят, B-каналы определились в системе как QSIG network. Станция сторона master. В cisco подключены IP телефоны так и называются cisco. C них можно звонить абонентам станции, вызов входящий на станцию проходит, всё в порядке. А проблема заключается в том, что не работает исходящая связь!! То есть, IP телефонный аппарат cisco имеет номер 620007. Я на HiPath начинаю набирать префикс выхода на поток “0”, затем собственно номер 620007. При поциферной передаче, уже после набора “2” выдаёт короткие гудки и на дисплее пишет “НЕ ОТВЕЧАЕТ”. При способе передачи цифер “enblock” результат аналогичный. Я позаботился о том, чтобы не стояло запретов выхода на B-каналы потока. Помогите, может знает кто нибудь куда ещё можно ткнуться в станции чтобы поток уже заработал полноценно наконец. Может есть у кого опыт связывания АТС с маршрутизаторами? Перепробовал все возможные протоколы, не помогает.

Сомненьице у меня, что HiPath 3800 мастером с Cisco будет работать. И что мы слышим при наборе 0?

При наборе префикса "0" мы слышим в трубке тишину (ожидает дальнейшего набора). Собственно, методом enblock позволяет все цифры набрать, но в результате происходит disconnect и на дисплее пишет "не отвечает" И почему возникает такое сомнение что мастеров станция с циской не сойдётся?

Раз мы слышим тишину, то потока нет, потому и отбой.

Если HiPath выдает в Cisco все цифры, то это проблема Cisco.
То есть, получая из потока Е1 цифры Cisco не знает что с ними делать, или что эти цифры значат, когда они приходят из потока. Проблема маршрутизации в Cisco.

HiPath без особых проблем зацепляцеятся с Cisco по PRI.
Протокол правильно выбран QSIG, причем, мастером ставится та сторона, у которой наивысший по стабильности, источник синхронизанизации.
Здесь не ясна ситуация: как устроена сеть, есть ли от верхнего оператора поток Е1 наружу, куда он включен - в сименс или cisco.
В любом случае:
нужна трассировка соединения со стороны сименса.
Выкладывайте трассировку вызова (Maintenance -> Call Monitoring)

Раз мы слышим тишину, то потока нет, потому и отбой. Нет, это потому что у меня enblok-ом цифры отсылаются и скорее всего не выставлен диал тон после набора префикса. Поток не может быть не поднят, говорю же входящая прекрасно проходит с циски на станцию. Да и потом, я могу встать на канал напрямую и начать набирать. "6" пропустит и будет ждать набора дальше. По "2" уже отбой даёт и пишет "НЕ ОТВЕЧАЕТ"

Если HiPath выдает в Cisco все цифры, то это проблема Cisco.
То есть, получая из потока Е1 цифры Cisco не знает что с ними делать, или что эти цифры значат, когда они приходят из потока. Проблема маршрутизации в Cisco. Очень бы хотелось так думать. Просто циски я не знаю и к тому же ещё не я её настраиваю, а человек в Москве. Я далеко от него нахожусь. Сложность вот и в этом ещё заключается....он уже всё почти перепробовал и я не знаю куда ещё ткнуться можно по настройке потока на HiPath, поэтому и у вас помощи прошу, что уж если кто имел с этим дело то нюансы и фишки полюбому известны:)

Тут схема такая: медиаконвертер-->циско-->система HiPath3800. Это у меня в Архангельске в серверной так. К этой циске подключен IP телефон с номером 620007. Оператор же, просто обеспечивает расстояние потока по оптоволокну до Москвы, в которой уже насколько я понимаю такая же циска с конвертером, но только без АТСки, а сразу и циски у них там всё подключается на IP телефоны. И вот мне сказали пробовать набирать с системного аппрата на этот цисковский. С него входящая нормально проходит, а исходящая не идёт. Не пускает набрать 62 и хоть убей. А с трейсами монитора у HiPath возможно это будет сделать только в понедельник

Понятно. Давай KDS посмотрим где да что.
Можно в личку.
Кстати, какой медиа конвертер используется и поподробнее?

Обязательно выложу и KDS и трейсы монитора канала, но произойдёт это только завтра, сегодня у меня их просто нету

А насчёт медиаконвертера.....я думаю не суть какой он. Ведь использование только в том заключается чтобы их оптики в Ethernet превести, который потом в циске. Самое главное, мне надо чтобы HiPath с циской полноценно заработал хотябы локально, то есть в пределах одной серверной, а там уж и с удалённой соответственно должно заработать ))

Вот выкладываю данные о трассировке

Добрый день всем.
Первым делом вызывает сомнение что Cisco может воспринимать цифры в режиме overlap попробуйте посылать блоком.
Выложенный трейс по блоковой передаче номера представлен только для входящего звонка, а исходящий увидеть можно? (для HiPath3800)

Извиняюсь не туда глянул

Продолжаем разговор....
Входящую трассировку на звонок с 620007 на 148 можно увидеть?
Вы сказали что звонок нормально проходит...

Нет, это как раз трейс по ИСходящему enblock"у т.е зафиксированы именно набираемые цифры на системнике HiPath. В трейсе указаны набранные цифры called num, а набирающий как раз 148.

А входящий трейс конечно могу выложить, вот пожалуйста ))

смотря на kds. станция выступает в качестве slave
попробуй прописать наборный план 0-CXXXXXX

добрый день!
так а не понятно самое главное...на Циску-то цифры прилетают или нет?
там же тоже можно трассировку включить.
Кроме того может там по входящему АОНу что-то режется и т.д.

смотря на kds. станция выступает в качестве slave
попробуй прописать наборный план 0-CXXXXXX
1. Позвольте спросить, как вы смогли определить в моей кдс-ке что она в slave?? Я её насколько помню в мастер выставлял......и как мне ихвестно делается это вот так:

смотря на kds. станция выступает в качестве slave
попробуй прописать наборный план 0-CXXXXXX
Если вам известен ещё какой нибудь способ перевести станцию в слэйв--мастер, то очень прошу, поделитесь пожалуйста.
2. Записи 0-СХХХХХХ и 0-CX отличаются лишь тем, что в первом случае станция будет заранее знать сколько цифер ей ждать от набора, в отличии от второго способа который у меня прописан в маршруте. В моём же случае станция просто выжидает, считает что набор завершён и валит цифры в канал. НО, в моём то случае невозможно набрать даже вторую цифру (overlap). А enblock даёт в итоге такой же результат

добрый день!
так а не понятно самое главное...на Циску-то цифры прилетают или нет?
там же тоже можно трассировку включить.
Кроме того может там по входящему АОНу что-то режется и т.д.

К сожалению циску я не знаю, и не я ей занимаюсь. Сложность ещё и в этом. Поэтому не могу сказать что и как там отсекается. Но цифры уходят по моим трейсам, а по мониторам циски, как говорит спец который ей рулит, их не видит!:(

Но в LCR стоит en-bloc, а в System setting - digit-by-digit. А что мешает завернуть поток на поток и проверить прохожение вызова?

ВНИМАНИЕ ВСЕМ! Чтобы всем было понятно о какой схеме соединения систем идёт речь, я выкладываю её вот сюда и так же повторно КДС и мониторы вызовов:

Но в LCR стоит en-bloc, а в System setting - digit-by-digit. А что мешает завернуть поток на поток и проверить прохожение вызова?
Сдаётся мне, блок Toll restriction в System settings - ограничение звонка по параметру Digit-by-digit. Но у меня же enblock выставлен в LCR и нет запрета на него в Toll restriction. А вот завернуть поток на поток........вы имеете введу в системе HiPath содать петлю? Поднять поток внутри неё самой? Вам известно как это делается и как это должно выглядеть?

Сдаётся мне, блок Toll restriction в System settings - ограничение звонка по параметру Digit-by-digit. Но у меня же enblock выставлен в LCR и нет запрета на него в Toll restriction. А вот завернуть поток на поток........вы имеете введу в системе HiPath содать петлю? Поднять поток внутри неё самой? Вам известно как это делается и как это должно выглядеть?

Наверное имелось ввиду найти другой свободный поток на твоей АТСке и подключить проблемный на него и потестить.
Тоже интересный вариант.

Наверное имелось ввиду найти другой свободный поток на твоей АТСке и подключить проблемный на него и потестить.
Тоже интересный вариант.
Но у меня на АТСке всего один поток 30В каналов, больше нету. Остальные аналоговые транки. Я ж выше схему выложил, на ней всё указано что куда

Но у меня на АТСке всего один поток 30В каналов, больше нету. Остальные аналоговые транки. Я ж выше схему выложил, на ней всё указано что куда
я надеялся что в ЗИПе есть загашничек..

Плата DIUN2 содержит 2 потока или я ошибаюсь? 10-1 и 10-2?

Плата DIUN2 содержит 2 потока или я ошибаюсь? 10-1 и 10-2?Да, это так. Но второй порт платы DION не выдаёт потока почему то:( Я пробовал светодиодом, он не горит на передаче. К тому же у меня нет лицензии на 30 каналов второго порта

Если верить кдс, то 30 лицензий на 10-2 есть, т.е. все должно работать. При наличии свободного времени я-бы обнулил станцию в 0 и проверил поточку. Да и лицензиит можно перераспределить между двумя потоками.

Ребятя, а причем здесь мастер и слэйв?
Поток поднялся, пошли команды, забываем про это.
Стоит всего лишь вопрос о маршрутизации.
Сразу скажу, что Циска к набору цифра за цифрой относится плохо.
Поэтому рассматриваем вариант передачи блоком.

Давайте рассмотрим ваш трэйс:

1) HiPath отдает SETUP, в котором
calling num является unknown/ISDN, номер абонента 148
called num является unknown/unknown, блок цифр выглядит как 620007

2) В ответ HiPath получает от Циски команду RELEASE COMPLETE
с пометкой unallocated number.

И что непонятного?
Мы выдали в циску цифры 620007, а на эти цифры циска ругнулась, якобы у нее нету такого абонента. Хайпас тут не при чем, нужно настраивать Циску.
Циске не нравятся или пришедшие к ней цифры 620007, или тип номера unknown/unknown.

В общем в Циску цифры вы выдаете 100 процентов.
Или скажу так...в поток, с котого снят трэйс цифры вы выдаете.
И если этот поток в самом деле проводами включен в ту самую циску,
то именно она вас отбивает.
А то что спец по циске говорит, что не видит, так не верьте :-)
Знаем мы этих цискарей, не раз с ними коннектились.
У цискорей всегда проблемы на дальнем конце, но только не у них, пока не возьмешь за яйца :-).
Возбмите ваш трэйс и дайте почитать цискарю, в нем все видно.

В общем в Циску цифры вы выдаете 100 процентов.
Или скажу так...в поток, с котого снят трэйс цифры вы выдаете.
И если этот поток в самом деле проводами включен в ту самую циску,
то именно она вас отбивает.
А то что спец по циске говорит, что не видит, так не верьте :-)
Знаем мы этих цискарей, не раз с ними коннектились.
У цискорей всегда проблемы на дальнем конце, но только не у них, пока не возьмешь за яйца :-).
Возбмите ваш трэйс и дайте почитать цискарю, в нем все видно.Дело в том, этот самый цискарь уже поднял поток с другими филиалами, правда в них станции другие. Если он уж с другими поднял поток и циски настроил......то не уж то здесь не может. Все свои трйсы мо монитору каналов я в первую очередь выслал ему, а уж потом сюда выложил:) На меня уже начальство буксует, чувствую скоро нас обоих за жабры возьмут. Я прислушиваюсь к любому что мне здесь пишут и на данный момент вижу единственнымиразумными решениями - это ещё раз прогнать поток внутри станции (сделать петлю) при её полной инициализации, после которой соответственно выставив все необходимые параметры для поднятия потока

Ребятя, а причем здесь мастер и слэйв?
Поток поднялся, пошли команды, забываем про это.
Стоит всего лишь вопрос о маршрутизации.
Сразу скажу, что Циска к набору цифра за цифрой относится плохо.
Поэтому рассматриваем вариант передачи блоком.

Давайте рассмотрим ваш трэйс:

1) HiPath отдает SETUP, в котором
calling num является unknown/ISDN, номер абонента 148
called num является unknown/unknown, блок цифр выглядит как 620007

2) В ответ HiPath получает от Циски команду RELEASE COMPLETE
с пометкой unallocated number.

И что непонятного?
Мы выдали в циску цифры 620007, а на эти цифры циска ругнулась, якобы у нее нету такого абонента. Хайпас тут не при чем, нужно настраивать Циску.
Циске не нравятся или пришедшие к ней цифры 620007, или тип номера unknown/unknown.
Прошу вас, так же если можно глянуть мою КДС-ку. Меня начали там терзать смутные сомнения по вот какому адресу: Class of service-->Group assigment-->Station. Так вот в Station там же нет нифига, ни одного абонента, а в CON матрице прописано оба направления. При инициализации по умолчанию там присутствуют все внутренние номера....как я обратил сёдне на КДС ку от 3500 станции. Может ли в этом косяк быть?

Уважаемый, давайте не будем извините буксовать :-)

Мы с вами имеем трэйс, в котором черным по белому написано, что НЕОБХОДИМЫЕ И ПРАВИЛЬНЫЕ цифры мы в этот поток выдаем.
Что еще нужно ему?
Пусть посмотрит типы номера, цифры которые присылают ему работающие станции, сравним их с теми данными что высылаем мы и все станет на свои места. Но это в первую очередь цискарь должен быть сделать.
Работаем, работаем :-)

Добрый вечер уважаемые!
Прошу прощения за долгое молчание - дела.
Первым делом спасибо за выложенные трассировки. Настораживает что во входящей и исходящей трассировках разные Screening Indicator в calling num - с одной стороны это user-provided а с другой network-provided может сиська этого и не понимает в АОНе? Чтоб подрегулировать енто дело надо входить под супер-инженерным(develop) паролем и поиграть в настройках протокола потока (user-network).
Или второй вариант - это посмотреть как подрегулировать Type of Number/Numbering Plan в том же calling num так как посылается с HiPath3800 unknown/ISDN а с сиськи - unknown/unknown. Ну это я думаю Вы знаете где подрулить.
Я думаю пока все...
Попробуйте
Если не получиться пишите далее еще ковырнем
Информации достаточно много

Без вариантов, как и верно ответил Holder, проблема в конфигурации на стороне cisco 2821.
Там эти спецы по cisco в Москве, случайно, не КРОК называются?
- Попроси их прислать run-config: посмотрим, что наваяли.

Уважаемый, давайте не будем извините буксовать :-)

Мы с вами имеем трэйс, в котором черным по белому написано, что НЕОБХОДИМЫЕ И ПРАВИЛЬНЫЕ цифры мы в этот поток выдаем.
Что еще нужно ему?
Пусть посмотрит типы номера, цифры которые присылают ему работающие станции, сравним их с теми данными что высылаем мы и все станет на свои места. Но это в первую очередь цискарь должен быть сделать.
Работаем, работаем :-)Большое спасибо вам за совет:)

Добрый вечер уважаемые!
Прошу прощения за долгое молчание - дела.
Первым делом спасибо за выложенные трассировки. Настораживает что во входящей и исходящей трассировках разные Screening Indicator в calling num - с одной стороны это user-provided а с другой network-provided может сиська этого и не понимает в АОНе? Чтоб подрегулировать енто дело надо входить под супер-инженерным(develop) паролем и поиграть в настройках протокола потока (user-network).
Или второй вариант - это посмотреть как подрегулировать Type of Number/Numbering Plan в том же calling num так как посылается с HiPath3800 unknown/ISDN а с сиськи - unknown/unknown. Ну это я думаю Вы знаете где подрулить.
Я думаю пока все...
Попробуйте
Если не получиться пишите далее еще ковырнем
Информации достаточно много
Дело в том, что я сразу же как начал настраивать поток, то первым же делом вошёл туда под заводским паролем:) и наигрался там уже с этими настройками протоколов досыта:) И Type of Number/Numbering Plan тоже уже весь "перелопатил", не помогает:)

Без вариантов, как и верно ответил Holder, проблема в конфигурации на стороне cisco 2821.
Там эти спецы по cisco в Москве, случайно, не КРОК называются?
- Попроси их прислать run-config: посмотрим, что наваяли.
Нет, это не КРОК :) Настраивает cisco компания SATEL. Обратите внимание на выложенную выше мной схему соединения оборудования(2 страница моей темы). Проблема ещё в том заключается, что непонятно в какой циске недорулено. Их там две. Я консультировался с сервисным отделом наших поставщиков оборудования HiPath, они так же смотрели у меня KDS и сказали что при таких настройках должно работать поток cisci и HiPath. Выслали пример настройки cisco и станции, вот в понедельник посмотрим что получилось

fazil, больше не мучай сименс.
Попроси SATEL прислать run-config с обоих железок.

Уважаемый Fazil доброе утро!
Я не получил ответа - меняли network и user на потоке?
Остальное слова. Тип номера понял-меняли...

Уважаемый Fazil доброе утро!
Я не получил ответа - меняли network и user на потоке?
Остальное слова. Тип номера понял-меняли...Да, всё это менялось. Поток поднимается только в том случае, если Network стоит HiPath. Под user почему то не поднимается. А если пробовать менять тип номера, то это тоже не помогает, я пробовал. Результат остаётся таким же.....не набирается 620007

Коллега, цифры 620007 НАБИРАЮТСЯ.
Они НЕ ПРИНИМАЮТСЯ циской.
Не путайте :-)))))))))))))

Коллега, цифры 620007 НАБИРАЮТСЯ.
Они НЕ ПРИНИМАЮТСЯ циской.
Не путайте :-)))))))))))))
По всей видимости это почему то так. Хотя специалист из САТЕЛ, который рулит цисками, что точно такая же схема работает с другими станциями других удалённых филиалов. Нигде больше в др удалённых филиалах к сожалению системы HiPath не стоит. Я не могу понять одной маленькой тонкости большой проблемы: почему такая же система маршрутизаторов от других станций всё принимает, а с сименса принять не может. Ну то что я в поток отправляю цифры это и так понятно. Вот из-за этой маленькой тонкости и ведётся весь наш этот длинный разговор )) Я предложил специалисту из САТЕЛ подключиться к нашему разговору и чтоб он выложил конфиги цисок. Вот мне например, не понятно какой конкретно циску надо рассматривать конфиг чтобы понять проблему. Ведь циски то 2, напоминаю и выкладываю опять же схему соединения всего оборудования сюда:

Необходимы выводы команд show tech и show cdp neib detail с используемых 2821 и Catalyst.

Делал я ткое соединение. Промахался неделю. Точно помню, что нашел какой-то нюанс, но не могу вспомнить - хоть убей. У меня где-то есть кдс с этого объекта, после обеда выложу.

Необходимы выводы команд show tech и show cdp neib detail с используемых 2821 и Catalyst. Эти команды нужно выводить в режиме реального времени? О чём они говорят? Я выложу run-config обоих железок, как только они у меня будут

Делал я ткое соединение. Промахался неделю. Точно помню, что нашел какой-то нюанс, но не могу вспомнить - хоть убей. У меня где-то есть кдс с этого объекта, после обеда выложу. Я уже бьюсь чуть ли не 3-ю неделю, всё без результатно. Уж не знаю какой ещё может быть нюанс в хайпасе......я уже всё станцию перелопатил, как только не извратился, какие только параметры не выставлял. Перепробовал все планы нумерации, протоколы.......и самое главное, я ЗАМКНУЛ 2 ПОТОКА ВНУТРИ СТАНЦИИ !! То есть потоковая плата же имеет 2 порта по 30B каналов, ну вот я сделал 2 потока внутри одной станции. Прекрасно работает, перезваниваюсь между абонентами с одного потока на другой или в пределах одного потока, без разницы. Умоляю, вспомните что за нюанс такой.....или хотя бы КДС найдите и выложите пожалуйста

Посмотрел KDS.... да..... откуда такая маниакалная потребность убирать усе галочки... даже там, где они никому не мешают, а также там, где они и совсем не помешают? Непонятно, зачем было кроить какой-то новый протокол, скрещивая EDSS c QSIG, кода готовых предложений по стандартным протоколам более, чем достаточно? И возвращаясь к любимым галкам, а зачем было в параметрах направления на киску убирать DIV.LEG-Info?? :confused:

Посмотрел KDS.... да..... откуда такая маниакалная потребность убирать усе галочки... даже там, где они никому не мешают, а также там, где они и совсем не помешают? Непонятно, зачем было кроить какой-то новый протокол, скрещивая EDSS c QSIG, кода готовых предложений по стандартным протоколам более, чем достаточно? И возвращаясь к любимым галкам, а зачем было в параметрах направления на киску убирать DIV.LEG-Info?? :confused:В любом случае, это ничегьо не меняет. Сегодня был протокол QSIG, как вы выражаетесь, без выкройки нового протокола......просто сёдне выбрал QSIG мастер снял галки CRC4. Вот и всё.....результат такой же. Да и галка кстати говоря, стоит у меня там напротив параметра DIV. LEG - Info. Что она стоит, что не стоит....результат не меняется. Пробовал и с ней, и без неё

Посмотрел KDS.... да..... откуда такая маниакалная потребность убирать усе галочки... даже там, где они никому не мешают, а также там, где они и совсем не помешают? Непонятно, зачем было кроить какой-то новый протокол, скрещивая EDSS c QSIG, кода готовых предложений по стандартным протоколам более, чем достаточно? И возвращаясь к любимым галкам, а зачем было в параметрах направления на киску убирать DIV.LEG-Info?? :confused:Узнать бы что она означает.....эта галочка:)

Галку поставьте, пусть стоит.
Она означает не отправлять дополнительную информацию в поток например при переадресации, трансфере. Если мы ее ставим, то инфа не отправляется, циске она и не нужна.

В циске нужно прописывать Dial Peerы и на вход и на выход. Может прописали только на выход? И вообще в циске много утилит дебуггеров, которые помогли бы понять в чем проблема. Не понятно, почему ваш цискарь до сих пор ничего не сделал.
Можно сделать show all history, где черным по белому будет видно, через какие peerы проходит вызов и где он затыкается. А то что типа с другими работает а сименсом нет, это ответ не инженера, а дворника.

Узнать бы что она означает.....эта галочка:)

Для этого достаточно было-бы заглянть в help Manager E.
"No Div. Leg. Info

If this flag is set, the standard diverting LEG information signal is not sent to the CO. The DIV. LEG info contains the call number of the A user. The DIV. LEG info should be suppressed if problems occur in the case of external call forwarding (CF ext.)."

И еще одна непонятка в Вашей станции: где клок генератор(CMS)?

Галку поставьте, пусть стоит.
Она означает не отправлять дополнительную информацию в поток например при переадресации, трансфере. Если мы ее ставим, то инфа не отправляется, циске она и не нужна.

В циске нужно прописывать Dial Peerы и на вход и на выход. Может прописали только на выход? И вообще в циске много утилит дебуггеров, которые помогли бы понять в чем проблема. Не понятно, почему ваш цискарь до сих пор ничего не сделал.
Можно сделать show all history, где черным по белому будет видно, через какие peerы проходит вызов и где он затыкается. А то что типа с другими работает а сименсом нет, это ответ не инженера, а дворника.
Может и забыли что то прописать........сейчас пока вот дожидаюсь пака выложит или пришлёт run-config обоих цисок

Для этого достаточно было-бы заглянть в help Manager E.
"No Div. Leg. Info

If this flag is set, the standard diverting LEG information signal is not sent to the CO. The DIV. LEG info contains the call number of the A user. The DIV. LEG info should be suppressed if problems occur in the case of external call forwarding (CF ext.)."

И еще одна непонятка в Вашей станции: где клок генератор(CMS)?Вообще то да......последний вам вопрос наводит на полезную мыслю. Так то CMS модуль в основном используется при организации минисотовой связи Cordless на хайпасе, но и ри сетеобразовании стороны мастер тоже.....Сравнил просто 2 кдс-ки от 3800 с разныых объектов, и действительно, на той другой 3800 CMS присутствует.....правда поток на ней работает со станцией ПРОТОН и хайпас в слэйве. А в моём случае щас 3800 связывается с циской и CMS нету, и станция у меня в мастере. Ну чтоже, замечание принимаю:) спасибо большое, буду узнавать у поставщиков, действительно без CMS станция небудет мастеров с циской работать или в нём нет необходимости

2 fazil:
поверьте, Q.sig Вам не нужен - у Сименса и у Циско разный взгляд на него. Используйте обычный EDSS1.
3800 умеет "мастера" и без клок-генератора.

В принципе Н3000 с циской по PRI вяжутся без проблем и по DSS и по QSIG, во сяком случае лет уже 8-10, до этого были проблемы, которые решались только заменой софта на цисках(видимо на более современное). Использовать QSIG болеее предпочтительно(правильно) с точки зрения возможностей создания корпоративной сети на оборудовании HiPath. А по поводу того что: "3800 умеет "мастера" и без клок-генератора.", вполне возможно..., мало ли что там производитель рекомендует, мы и сами с усами :), толко не надо после это обижатся и кричать, что этот HiPath гавно, и вообще не работает :D

2 GeoM: "во сяком случае лет уже 8-10..."
- отчего ж тогда Caller name и Call Forward работают только с конца 2007-го? :)
Про рекомендации производителя - это не ко мне, а к поставщикам fazil'а.
Моя мысль была в том, что отсутствие клока не ведёт к невозможности использования 3800-го в качестве стороны сети.

Я так и не увидел конфигурацию с 2821.
Похоже, что спец из сател наконец, добрался до циски, и все заработало.

Извиняюсь, вношу поправку в выложенную ранее схему. К сожалению из-за невладением нужной информации и сам и многих из вас ввёл в заблуждение. Здесму выкладываю отредактированную схему по организации цифровой связи между циско и HiPath. Предыдущая схема с новой выложенной имеет некоторые отличия

Я так и не увидел конфигурацию с 2821.
Похоже, что спец из сател наконец, добрался до циски, и все заработало.Оказывается дело может быть не только в цисках. Как выяснилось, вызовами рулит некий сервак в питере, а он уже выбирает направление на основании пришедших данных и получается что по идее только голосовой тракт проключается между 2821 и хайпасом. Вот здесь в конце темы я выложил отредактированную схему.

Всем спасибо за советы!! ))) У меня всё заработало. В самом деле, ковырять сименс уж так тщательно и не обязательно было. Поток на исходяшку тепперь работает дааже оверлэпом и без cms модуля. Я уж не знаю какие волшебные настройки были сделаны на циске и серваке, но у меня всё теперь работает при EDSS1. С QSIG пока не известно