В 4.2.4.7 говорится про ПГМ143/7 (CLI Transit)...

Ну тогда чего ж Вы хотите??
ORI - означает использовать оригинальный АОН, полученный из сети при входящем вызове!!!
Вы позвонили, к примеру со своего с мобильника, на "табло" будет номер вашего мобильника. Далее ответивший абонент делает перевод этого вызова на мобильник директора, и станция (т.к. ORI) в качестве CLI для исходящего вызова отсылает в сеть как раз номер вашего мобильника. Но этот номер не связан у провайдера с вашим потоком, поэтому провайдер заменяет этот "чужой" номер на Пилотный номер вашего потока, прописанный у самого провайдера.

К сожалению, в станции только одна опция "CLI Transit" для совершенно разных ситуаций:
- для автоматической переадресации во внешнюю сеть (СFWD Off-Net)
- для исходящего вызова из режима DISA (DISA-to-CO)
- для перевода вызова во внешнюю сеть (Transfer to CO)
- собственно для транзита (Transit -Out).
И в настоящее время разделить эти ситуации нельзя. Не предусмотрено.
Т.е. по уму тут должны были быть 4 опции вместо одной.

Извиняюсь, не знал всей ситуации. В данном конкретном случае, дела не меняет.

Если я не ошибаюсь - в некоторых случаях вызывающий сам может выбирать АОН выбором кода..

Ну это же другой случай!!
Здесь же не сам пользователь DISA набирает код доступа к исход, связи (DISA-to-CO), и его не заставляют авторизоваться, и не сам пользователь DISA набирает мобильный номер директора, а ответивший абонент переводит вызов (Transfer) во внешнюю сеть.

зы: автор утверждает, что менял cli аттенданта и менялся аон!!!!

Хм я конечно могу проверить еще раз, но по моему АОН подставляет лыжа из аттендонта, я и уцепился за эту информацию в обсуждении.

Так, давайте еще раз подробно уточним ситуацию.
1) Случай №1:
- Входящий DID вызов по потоку обслуживается в режиме DISA (прием назначен в ПГМ231 на сообщение VMIB)
- вызывающий абонент ничего не донабирает и по ПГМ167/2 попадает к "секретарю"
- секретарь делает Transfer на внешний номер
- вызов уходит с CLI, который назначен аттенданту (в ПГМ114 long CLI и т.п.)..
Так??

2) Случай №2:
- Входящий вызов поступает в станцию по другому DID-номеру в потоке (по прямому номеру директора).
- прием вызова по этому DID номеру назначен в ПГМ231 директору и/или секретарю
- на этот входящий вызов отвечает секретарь
- секретарь делает Transfer на внешний номер
- вызов уходит с CLI, который назначен секретарю (в ПГМ114 long CLI и т.п.).
Так??

P.S. Ну вот, пока я это писал автор вопроса исчез с форума... Опять все затягивается.
P.S.1: Нет. Он здесь.. ОК.

P.S. Ну вот, пока я это писал автор вопроса исчез с форума... Опять все затягивается.

Нет, нет я немножко отвлекся именно так![/quote]

Если все так, то уточните, какая версия прошивки на вашей станции.

[quote name='harris' date='6.10.2010, 17:28' post='40384']
Если все так, то уточните, какая версия прошивки на вашей станции.
3.8Bf

[quote name='harris' date='6.10.2010, 17:28' post='40384']
Если все так, то уточните, какая версия прошивки на вашей станции.
3.8Bf Поможет ли делить АТС на тенантные группы назначать разных операторов и разрешать им звонить друг в друга.
Меня всевремя отвлекают, простите.
Спасибо!

ОК. Тогда я беру тайм-ayт на 15-20 минут, чтобы смоделировать вашу проблему на своей станции и посмотреть трассировки.

Проверил как на версии 3.8Bf, так и на следующей версии - 3.8Ct.
Все одинаково. Если в ПГМ143/7 установлено значение CLI Transit = ORI, то во всех случаях перевода входящего внешнего вызова обратно в сеть станция посылает оригинальный CLI, т.е. в качестве CLI посылается АОН, принятый во входящем вызове.
При тестировании:
- назначен Attendant = STA300, которому назначен CLI= 7777300;
1) Случай №1:
- на DID-номер 620 приходит входящий вызов с АОНом=9136883 и обслуживается в режиме DISA (прием назначен в ПГМ231 на сообщение VMIB)
- вызывающий абонент ничего не донабирает и по ПГМ167/2 попадает к "секретарю" STA301 (СLI: 7777301)
- STA301делает Transfer на внешний номер
- вызов уходит с CLI = входящему АОНу (9136883)

2) Случай №2:
- Входящий вызов с АОНом=9136883 поступает в станцию на другой DID-номер - 301.
- прием вызова по этому DID номеру назначен в ПГМ231 непосредственно на STA301
- на этот входящий вызов отвечает STA301
- STA301 делает Transfer на внешний номер
- вызов уходит с CLI = входящему АОНу (9136883)

Тенантные группы здесь ничем не помогут.
До конца непонятно, что у Вас там происходит и как именно Вы это все проверяете.
Нужно бы посмотреть файл вашего конфига и трассировки с потока в одном и в другом случае.

[quote name='harris' date='6.10.2010, 19:02' post='40402']
Тенантные группы здесь ничем не помогут.
До конца непонятно, что у Вас там происходит и как именно Вы это все проверяете.
Нужно бы посмотреть файл вашего конфига и трассировки с потока в одном и в другом случае.
Согласен! я писал аон из договора может поэтому он шел насквозь. смогу все перепроверить только завтра.
Кстати, если перенаправлять вызов через конференцию Аон "нужный", но геморой для секретаря.
Спасибо!

Конференция - это уже другая фича. Там входящий вызов никуда не передается, а ставится в режим удержания!! Далее абонент инициирует обычный исходящий вызов, при котором просто отправляется CLI самого абонента, как и полагается. И только потом два вызова объединяются в конференцию.

С конференцией понятно. Я теперь все время думаю как у меня АОН менялся, "трезвый" был точно, но звонил сам на себя из потока.

Вы при проверке звонили в обоих случаях с одного и того же телефона или с разных??? Какой CLI приписан к этому телефону (телефонам) в ПГМ114???
Тут нужно смотреть на все детали. Вы звоните со своей же станции. Значит АОН соответствует тому пулу номеров, которые у провайдера прикреплены к вашему потоку. И точно этот АОН уходит при передаче вызова. Т.к. АОН правильный, то провайдер пропускает его без изменений. Но как только Вы звоните с любого другого городского номера, то при переводе вызова провайдер подменяет этот "чужой" АОН на пилотный (глобальный) номер потока, и "директор" получает вызов от этого пилотного номера.

На самом деле вся задача решается просто:
- нужно разделить исходящий поток на 2 транка (по ПГМ141/1 и по ПГМ322)
- для одного транка поставить CLI Transit= CFW и направлять в этот транк всех собственных абонентов вашей транзитной станции. При переводе вызова во всех случаях будет использоваться CLI секретаря.
- для другого транка оставить CLI Transit = ORI и направить туда все исходящие транзитные вызовы (от других АТС из вашей корпоративной сети). Пройдут CLI, сформированные на оконечной АТС.

Все так. Разделить исходящий поток на 2 транка и сам думал, но в час пик нагрузка на поток 19-23 ки и возможно наращивание емкости. Важно что понятно явление и решение принять будет уже проще.
Спасибо всем кто помогал разобратся.

Кстати, а есть смысл просить Корею подкрутить совт в этом месте, (как Харрис писал выше) ведь у многих проблема серьёзнее намного и не каждый оператор подставляет серийный АОН. у меня есть коллега, он включен в "Ростелеком" они требуют жестко то, что хотят и не пропускают его..

1) В каком месте и как "подкрутить софт"?? Что именно?? Вместо одной опции CLI Transit cделать 4 опции?? Я подобное запрашивал еще пару лет назад. Отказали. Другим странам сие не требуется.
2) ИМХО, что либо серьезное просить корейцев изменить в софте не имеет смысла, т.к. на замену серии ipLDK уже пришли новые линейи станций: iPECS LIK и iPECS MG.

А с чем связана необходимость пропусать CLI, сформированной на оконечной АТС??
Можно ведь для всех транзитных вызовов посылать CLI аттенданта транзитной АТС. Тогда на потоке можно будет поставить CLI Transit = CFW, и тогда будет отсылаться CLI того абонента, который переводит вызов на внешний номер.

Такое красивое решение ув. Харрис сделал (я его в сокровищницу своей памяти золотыми буквами записал - буду потом хвастаться знанием этого), а Вы даже не примените это решение.. , хотя бы временно - до расширения.

Стас! Умерь, пжлст, свой пыл...

Станции используются, в том числе, как вынос емкости ТФОП, есть арендаторы которые сидят на своих договорах.
Если возвращаться к начальному вопросу тут дешевле донести до директора, что ему не звонят просто спросить как дела!
Спасибо! АОНы всегда были загвоздкой.

Станция ipLDK - позиционируется как офисная АТС. Но не предназначена для использования в качестве транзитной АТС, хотя в ней и есть простейшие возможности для транзита. А Вы как раз хотите транзитить потоки на ipLDK. Тогда придется мириться с рядом ограничений.
Я при случае, при контакте с разработчиками (может быть они будут собирать предложения по функционалу для версии 4.0) опять попробую поднять тему с расширением транзитных функций iPLDK в отношении формирования АОНов (CLI).

А на новых поколениях есть это разделение для более полного использования транзитов? У меня планируется более широкое использование транзита. Будет еще один повод обновить ряд..

В iPECS MG это решается другими способами. Там больше возможностей, включая возможность непосредственно назначить таблицу для преобразования АОНов. Увы, подробнее пока сказать не могу - еще не возможности изучены в деталях.
В iPECS LIK пока этого нет. Но это стоит в плане на январь-февраль след. года. Сейчас корейцы решают вопрос о том, каким именно способом они будут реализовывать "гибкое" формированиа CLI при транзитных вызовах. Может быть, сделают аналогично MG (это желательно даже в целях унифиации), либо как-то по-другому (мы также предлагали пару вариантов).
В любом случае, эта задача по обеспечению гибкого формирования CLI является приоритетной в новых станциях и будет решаться каким-либо образом. Т.е. корейцы готовы решать такую задачу в новых моделях станций, но в старую серию станций у них уже нет желания, сил и возможностей, чтобы вносить серьезные изменения.

P.S. Стас! А оно тебе надо??? Разве у вас используется транзит??

Да, я понимаю. Только мы (наверное, большинство участников форума) вначале находим себе работу, где как-то платят.
В рамках скудного финансирования меняем восемь городских линий на спаренных телефонах и АТС "раvасоник" на вполне приличный бренд (считаю, что LDK обладает превосходным соотношением цена-качество), а потом руководство, считая, что нет предела бесплатному совершенству требует всё круче и круче или мол найдем, кто может. Такова Селяви.
Пардон, если не в тему.

Да. Это все мне понятно и знакомо. Ситуация более чем типичная!! Обычно руководство желает потратить 100 рублей, но при этом получить удовольствия на 1000$.
Проблема в том, что от группы разработчиков ipLDK, насколько я знаю, сейчас осталось только 2 инженера, остальные уже полностью заняты в проектах по новым станциям. Оставшиеся 2 корейца в основном готовы только исправлять обнаруженные баги, но не добавлять новые функции (к тому же они участвуют и в новых проектах тоже, но часть своего времени еще тратят на ipPLDK). Посмотрим..., может еще удастся как-то продавить их на внедрение новых опций в ipLDK (в версии 4.0).

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

Чей АОН увидит директор при Mobile Extension?

Смотря какая версия софта: либо аттенданта, либо АОН данного абонента, у которого включена опция Mob.Ext.

добрый день.
немного подыму тему для себя. т.е. пгм 143/7(CLI Transit) для фнукции Mobile Extension не учавствует???

Вы немножко не понимаете суть работы АТС. Приходит входящий звонок, его принимает абонент и переводит дальше. Вот тут и работает CLI Transit. Либо CLI SLT, кот. перевел звонок, либо CLI входящего звонка. А в случае Mobile Extension АТС от имени абонента набирает номер сотового телефона. Здесь формируется по прг. 143/12

абонент 100 звонит по внутренней связи абоненту 400(у абонента 400 включена функция mobile ext). на дисплее абонента 400 высвечивается внутренний номер 100. нужно и на мобилке, чтобы высвечивался номер 222-100, а не 222-400.(222- префикс из города)

когда из города звонят на номер 222-400, то здесь понятно, что провайдер не выпустит из моей атс чужой номер.

в IPECS MG - это всё отрабатывает корректно. видимо LDK это не реализовано(кажется в этом же топике про это и говорилось). в общем спасибо.
а про пгм 143/12 - это когда в потоке PRI провайдер шлёт разные пулы номеров. вот тогда и формируешь каждому абоненту нужный наружу CLI.

A опция CLI Transit не имеет отношения к данному случаю.
См. опцию пгм143/3 - CLI/Redirect Display.
Но точно уже не помню, работает ли она для вызова на мобильного абонента.

для LDK 143/3 - Type of Calling Number
CLI/Redirect Display - 114/3 (это атрибуты абонентов)

Ну да, в атрибутах абонентов, пгм114.
Речь идет фактически о переадресации. Еще раз : я не уверен, сработает ли это при вызове Mob.Ext.
А в пгм236 (Mob. Ext) на версии 3.9 не появились новые опции по поводу CLI ?? Сейчас не имею возможности посмотреть и проверить...

Нет, это не влияет. Пробовал, отображается только CLI по прг.143/12. Это первое. И второе. Оператор предоставляет поток с городскими номерами, это указывается в договоре. Если совершен звонок на сотовый номер, операторы при взаимозачете смотрят тарификацию звонков. Если в прг.143/7 поставить ORI, то из потока на сотового оператора будет выходить номер абонента, например другого оператора. Что является нарушением договора. Да, хотелку можно сделать, но есть еще юридическая сторона.

я конечно извиняюсь, но повторюсь:
абонент 100 звонит по внутренней связи абоненту 400(у абонента 400 включена функция mobile ext). на дисплее абонента 400 высвечивается внутренний номер 100. нужно и на мобилке, чтобы высвечивался номер 222-100

т.е. и абонент 100 и 400 из одного пула номеров провайдера(от 222-100 по 222-499 - это мои номера). здесь нет криминала по поводу терминации трафика. просто хотелось на мобилке увидеть номер 222-100, а не 222-400(с которым мобилка в паре получает звонки, используя функцию Mobile Ext)/ тут нет транзита.

ладно, нельзя - так нельзя

В вопросе идет речь о другом.
-У него идет внутр. вызов от STA100 на абонента STA400
- У вызываемого абонента STA400 включен Mob.Ext
- Нужно, чтобы на мобильник приходил АОН от абонента STA100, т.е. от вызываЮЩЕГО, а не АОН от абонента STA400, переадресующего вызов на свой мобильник!!!
При переадресации внутр. ввзовов тип CLI (вызывающего или переадресающего) как раз регилируется опцией пгм114/3 (CLI/REDIRECT DISPLAY). Нужно проверить это же для случая переадресации на Mob.Ext.

проверю - отпишусь . спасибо!

Так вы проверили опцию пгм114/3 или нет???

проверил. при этой функции"mobile ext" - результат тот же

Ну, тогда увы...