ipLDK-300 АОН в зависимости от направления? Опции

[ava]

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

[ava]

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

[harris]

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

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

[harris]

Проверил как на версии 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)

[harris]

Поможет ли делить АТС на тенантные группы назначать разных операторов и разрешать им звонить друг в друга.

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

[ava]

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

[harris]

Согласен! я писал аон из договора может поэтому он шел насквозь. смогу все перепроверить только завтра.
Кстати, если перенаправлять вызов через конференцию Аон "нужный", но геморой для секретаря.
Спасибо!

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

[ava]

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

[harris]

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

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

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

[ava]

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

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

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

[ava]

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

[harris]

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

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

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

[stasmar]

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

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

[harris]

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

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

[ava]

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

[harris]

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

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

[stasmar]

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

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

[harris]

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

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

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

[ava]

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

[harris]

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

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