Здравствуйте !
Кто знает как решить проблему :
Стыковка со СТОП (EURO ISDN) , приходит входящий вызов на внутренний номер на котором стоит переадресация на сотку. Прикол в том, что оператору сотовой связи выдаётся CLID не внутреннего абонента Meridian а пришедший при входящем вызове. Можно ли где настроить чтобы при переадресациях на платные направления выдавалсь номер внутреннего абонента (плюс необходимые префиксы перед номером)инициировавшего переадресацию.
Заранее благодарен за совет.
Попробуй в CLS телефона на котором стоит переадресация поставить DNO2 и DNDN.
Если стык правильный - EURO DID, то:
LD 15; TYPE NET; OCLI EXT или OCLI ALL (если есть транзитные MCDN'ы).
Спасибо за ответ!
А что кроется за словами "правильный EURO DID стык"? У нас на стыке со СТОП TIE тип роута это получается не правильно и в чём это неправильность может себя проявить ?
Транки типов DID и COT используются для соединений PABX с Central Office Switch'ами.
Транки типа TIE - для соединений PABX - PABX.
Функция "Optional Sending of Forwarding CLID",
подробно описанная в книге "International ISDN PRI" (код 553-2901-301) в главе "ISDN PRI Central Office Connectivity" на странице 518 и в главе "EuroISDN Continuation Phase III" со страницы 348, работает на DID транках.
Спасибо!
Настроили DID роут и транки как в указанном Вами документе и появилась проблема с входящей связью... Видим в сетапе приходят правильные цифры (соответствующие внутреннему плану нумерации) но соединение не происходит с case 1 (неопределённый номер...). Пыталися пропустить через IDC (пример: 5000 конвертим в 5000) таже ситуация. В чём может быть проблема? Исходящие вызова без вопросов :((
В Д-канале поставьте OVLR YES.
Если я правильно понял то этот параметр отвечает за то что цифры для вызываемого абонента могут приходить к нам не пакетом (все сразу) а по мере их поступления... Не совсем понятно зачем он нужен ведь свичь СТОП присылает цифры пакетом (по крайней мере в пришедшем сетапе они видны сразу все). Интересный момент в том, что когда мы перешли с TIE типа (при котором всё работало) на DID в свиче СТОП ничего не изменялось.
Да если можно поясните бестолковому в чём смысл cause 1 (Невыделенный (неприсвоенный) номер. Необходимое назначение достоверно, но не может быть достигнуто....).
Большое спасибо.
Пора посмотреть на dch и маршрут.
Наиболее распространенная проблема при переходе на DID, заключается в следующем:
т.к. это соединение предназначено для приема вызовов из ТФОП, то принимать по таким транкам больше цифр, чем DN в станции - нет необходимости. Длина номеров в PABX определяется по LDN'у. Если он 4-хзначный, то из принятого по DID набора, Меридианом анализируются последние 4-е знака.
К счастью, эту схему легко можно обойти, ибо при настройке под оверлап, она не работает. Недостатков и пагубных побочных эффектов не будет.
В том, что в CO switch изменений не было - ничего интерсного не вижу.
Unassigned Number - означает, что вызываемый номер не существует. Набор в станции не прописан.
Что и неудивительно. Наверняка происходит что-нибудь вроде:
- СО присылает вам, скажем, 7 знаков номера (123-45-67);
- у вас наверняка прописано какое-либо преобразование, например в IDC 1234567 -> 1001, где 1001 - DN аппарата, на который должен терминироваться вызов;
- Меридиан ДО обработки по IDC берет к рассмотрению, скажем, последние 4-ре цифры набора (45-67);
- в IDC 4567 не прописано;
- в санции DN 4567 - отсутствует;
- Меридиан отбивает звонок, с причиной - "несуществующий номер".
При установке в Д-канале OVLR YES, включаются совершенно другие программные процедуры обработки входящего вызова.
или, если не хотите менять D-канал, пропишите какой-нибудь номер в LDN. Главное (как уже упомянул уважаемый Karter), что-бы его длина соответствовала количеству цифр, принимаемых из города.
Прошу извинить, что опережаю события, Картер - вопрос к Вам.
У нас 25.40B, и при решении аналогичного вопроса, применив OCLI, получили следующую систуацию. Номер в город отдается правильный, однако флаги TON (Type of number) и NPI (Numbering plan indentification) равны нулю, хотя должны иметь такие же значения что и при нормальном звонке.
Из-за этого город не понимает номера и заменяет пилотным, да еще и, естественно, имеет к нам претензии...
Вопросы:
1. наблюдается ли это и на других машинах с 25.40B
2. как лечить
При мониторинге исходящего, уже переадресованного, звонка - что в setup'е?
Такой метод, правда, несколько снижает гибкость системы...
Вот идет звонок с 2531150 на 2567777 у которого в свою очередь CFW на 2567333. Ниже - два сетапа входящий и исходящий по переадресации:
DCH 34 UIPE_IMSG CC_SETUP_IND REF 00000132 CH 34 4 TOD 12:31:10
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:442531150 NUM PLAN: E164 TON: NATL
CALLED #:7777 NUM PLAN: E164 TON: UNKNOWN
DCH 34 UIPE_OMSG CC_SETUP_REQ REF 000010AA CH 34 6 TOD 12:31:10
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:442567777 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:2567333 NUM PLAN: E164 TON: LOCL
Как видно во втором сетапе calling NUM PLAN и TON = Unknown, в то же время при обычном исходящем звонке NUM PLAN: E164 TON: NATL
Большое спасибо!
Получилось!
Получилось, это хорошо.
А у Вас при форварде не возникает проблема, описанная выше?
Правда, насколько я знаю, некоторым станциям наплевать на TON. Может и у Вас такая ситуация. Однако, если не затруднит, могли бы Вы промониторить call setup при форварде.
Заранее благодарю.
Нужна еще какая-то информация?
Вам удалось это повторить?
Karter, извините за настойчивость, удалось ли Вам повторить, мою проблему, или у Вас все нормально при переадресации?
Привет.
Как вы в итоге решили проблему с типом номера при forward?
Спасибо.
Только начал этим заниматься, пока не решил.
Ув. emperor и all, удалось ли решить данную проблему с изменением TON и NUM PLAN?
Согласно доке есть промтик SDID в LD16. Только вот у меня он что-то не спрашивается :(. Может с ним есть сложности? Необходимое SDID IDC прописано, 11С, 25.15 General.
М1 25.40В SDID в руте уже есть. Тока при CFW не подействовало... (((