SMG-2016: подмена CgPN на Redirecting и поле номер АОН

[SEA]

Добрый день.

Версия ПО ECSS-10 V.3.7.0.1944 2016/PBX/VAS/REC/IVR Build: Oct 4 2016 05:15:30
Версия SIP-адаптера 3.7.0.20

Собственно проблема такая:
На абоненте помимо поле номер есть поле номер АОН, куда вписывается тот АОН который нам необходим, плюс ещё ставим тип CgPN, например я ставлю 3832ХХХХХХ с типом National для звонков на РТК по фэншую...и всё нормально когда ты звонишь с этой учётки.
Теперь возникла необходимость переводить звонки извне SMG, поступающие на этих абонентов на внешку, но нам прилетают АОНы совсем плохие - разной длины и типа (заранее неизвестные), поэтому:
1.Включаем переадресацию на таком абоненте на мобильник например
2.На транк группе, ч/з которую пойдёт вызов (отмаршрутизируется по CdPN) на исходящей связи ставим галку "Подменять CgPN на Redirecting"

Что получаем:
-при звонке непосредственно с абонента поле "Номер АОН" подставляется в CgPN
-при включении любой переадресации на абоненте CgPN на транк-группе действительно подменяется на Redirecting, но поле "Номер АОН" НЕ подставляется в CgPN, а сам абонент тоже с фиктивной внутренней нумерацией, и соответственно с таким АОН Ростелеком не пропускает.

Применять модификатор не предлагать: схему откатали и она работает, но модификатор при анализе по маске CdPN конечно вписывает нужный мне CgPN, но он его заменяет всегда и для всех, даже если инициатор имел нормальный АОН. Отбор по комбинации CdPN+CgPN невозможна, т.к. CgPN заранее неизвестен.
Выстроить правильное хождение АОНа на сети с фиксацией длины и типов номеров тоже уже нельзя - сеть такая: печальная, не мной созданная...


Собственно я понимаю, что это не баг и так софт написан, НО:

У кого есть идеи как ещё решить?

Как вы лично относитесь к тому, что при переадресации "Номер АОН" НЕ подставляется в CgPN? Т.е. хочется знать мнение сообщества, может так правильнее как сейчас и если да, то почему?

Вопрос к Элтексу: прорабатывался ли этот момент и возможно ли изменение софта если народ скажет, что как я хочу правильнее?

[bravo]

Люблю такие штуки. Давайте разбираться.

У вас получается вся проблема в том, что транзитные станции на ССОП порой не корректно работают с параметром redirecton number, как раз таки подменяя CgPN этим полем. А по факту ничего не должны с ним делать, и вызов так и должен пройти до адресата с этим параметром, на мобильнике должна отразиться информация, что это переадресация и номер инициирующий самый первый вызов. Последний CgPN в данном случае будет только для биллинга, так как всё таки ему деньги платить за последний вызов.

Извините, я пока не вчитывался очень пристально в то, что вы написали, поэтому напишу две очевидные вещи, которыми вы можете воспользоваться:
– собрать данные о всех форматах внутренних номеров и редиректинг на Исх транке расписать с приведением к общему виду всего чего только у вас там может пролететь. После этого злобные буратины будут те, кто эти номера там будет продолжать вводить и использовать. И под них уже можно будет открывать единичные задачи, для допиливания таблицы преобразования.
- подменять редирекцию общим CgPN для организации. Все вызовы будут пролетать, но адресат не увидит, кто ему звонит на самом деле.

И выдумывать сложные схемы анализа и всевозможных вариантов тут точно не стоит! Вам необходимо приводить сеть в порядок. Для этого на год планируется модернизация внутреннего плана нумерации. Если не на оконечных устройствах, то на шлюзах, через которые они выходят (ну что бы внутри локации всё осталось как прежде, а всякого рода модификации, вроде приведения в общему виду или анализ направления и модификации для этого направления, происходили на ближайших шлюзах к локации.

PS: хотел было пуститься в изыскания, но отвлекли, а теперь пора убегать. Пишите, что об этом думаете, подумаем вместе.

[SEA]

Доброго дня...

Наверное Вам следует вчитаться в первое сообщение, возможно я не совсем явно выделил проблему: собственно SMG должен подменять CgPN на Redirecting и он это делает, но он подставляет вместо Redirecting значение из поля "Номер", а как я это вижу, он должен ставить значение из поля "Номер АОН" - это бы давало возможность работать по обеим схемам:
1.АОН= Redirecting = "Номер"= "Номер АОН" (если мы руками вписываем одинаковые значения)
2.АОН= Redirecting = "Номер АОН" (т.е. руками вписываем то, что необходимо именно нам).
Т.е. я предлагаю более гибкую схему, мне непонятно почему Элтекс это не реализовал....

Про то, что должно отдаваться как АОН, а кому должен выставляться счёт в цепочке звонка А-В-С, где на В происходит переадресация понятно, но в реальности для мелких клиентов подключенных по DSS этот вызов на стороне С выглядит как В-С и всех это устраивает...Вот когда по ОКС сдаёшь то там да, трясут - покажи то, покажи это, ещё и при переадресации требуют чтобы В отдавал свою категорию АОН, а не сохранял категорию АОН абонента А, если они отличаются, согласно праву абонента выбора оператора МГ/МН связи - вещь редкая, но по закону положено...Ещё вопрос, кстати, может ли SMG так делать - не проверял.

Про приведение сети в порядок: я работаю по временному контракту, на меня тут и так косо смотрят, когда я говорю, что вот тут сделано неправильно...Нормализация номера у создателей сети происходила исключительно по маске, а тип номера в крайнем случае менялся при выходе на вышестоящего оператора, попытка объяснить что АОН должен формироваться ЕЩЁ на инициаторе вызова В ЗАВИСИМОСТИ от направления с "правильным" типом вызвала странную реакцию: вроде головой кивали, но суть метода не уловили мне кажется....
На сети вообще жуткая каша: длина номера не фиксированная, сложная система префиксов между филиалами, нумерация по большей части фиктивная, ИНОГДА являющаяся окончанием полного публичного номера ГТС, половина выходов на внешку через СЛ, есть всё: TDM во всех видах и формах со всякими видами сигнализации, СЛ 2 и 4 проводные, IP и т.д. и т.п. и диспетчерские каналы - на переделку сети никто и никогда заявки не согласует. Поэтому приходится делать "ровными" новые узлы и ждать пока отомрут старые....правда мой личный прогноз на фэнщуй на сети отрицательный - сеть переделать можно, систему в целом (главным образом мышление людей) достаточно проблематично...
Но это всё лирика...

Нашёлся несколько иной способ для всей сети сразу (костыль конечно), благо железа хватает:
для переадресаций со всей сети заводим пул фиктивной нумерации и заворачиваем её на SMG, там на входе ставим модификатор в котором по маске CdPN из нашего фиктивного пула заменяем CdPN на номер куда переадресовываем, например +98913ххххххх...............$(сразу пишем на максимальную длину), а CgPN на необходимый АОН, например +383ххххххх..........$(здесь считаем, что максимум изначальный АОН м.б. 10-значным). Соответственно группа должна влетать в план нумерации где расписан префикс 98.
Таким образом факта переадресации мы избегаем, т.к. не приземляем её на абоненте, и не подменяем АОН в случае если через эту транк-группу идет вызов на номер сотового который есть в модификаторе, т.к. и анализ по маске фиктивного пула, и модификатор на входе. Правда абонентам этого SMG от этого не легче, и их надо слать на другой за данной фичей...

Но, ещё раз повторюсь, это костыль, хотелось бы наверное реакции от самого Элтекса по поводу можно ли при переадресации сделать АОН="Номер АОН" и снести костыль.

[Женя]

Но, ещё раз повторюсь, это костыль, хотелось бы наверное реакции от самого Элтекса по поводу можно ли при переадресации сделать АОН="Номер АОН" и снести костыль.

Задачка по этому поводу есть, но она не приоритетная.
Это сильно критично для Вас?
Пришлите в ЛС ваши контакты и название компании

[SEA]

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

[bravo]

По поводу вашего вопроса в первом посте:
У вас типичная проблема, когда в поле CgPN вставляется инициатор вызова, которого переадресовали. Если прилетело из города - вам ничего модифицировать не надо (ну в идеале или чуть подправить под формат, в котором вы должны отдать в город). Если звонящий из внутренней сети - у вас тот же самый набор преобразований, что и для редиректинга.
На ваш вопрос, относительно подмены номера CgPN на редиректинг - моё мнение таково, что этого надо стараться избегать! Дело в том, что эта функция родилась в попытках поддержать работу сервиса на учрежденческих сетях и станциях местного уровня. Дело в том, что операторы, которые присоединяют к себе местные узлы связи или подключают абонента со своим PBX, по идее должны фильтровать трафик, который сыпется с этих сетей и пропускать только лигитимные АОН, прописанные в договорах о пропуске трафика (ну или те, которые были выделены учреждению). И вот так сложилось, что в старых станциях (или биллинге) нет возможности оценить, переадресация это с полями redirecting number в сообщениях SETUP или IAM, или же оператор/учреждение через себя гонит левый трафик, транзитный... Чем оно заниматься не имеет права и тарифы там другие как правило. НО надо добиваться того, что бы оператор, куда сливается этот трафик, что-то с этим делал, потому как у вас всё законно и нужные поле при переадресации присутствуют в инициализирующих сообщениях.
И не всех это устраивает. У протоколов связи есть возможности всё передать корректно, что бы каждая система, участвующая в маршрутизации и учёте вызовов получила всё, что ей нужно для корректного учёта. Всё остальное уже ограниченность операторских коммутаторов.
Сразу же и ответ на ваш вопрос, почему в Элтекс этого до сих пор не реализовали - на мой взгляд потому, что они не pbx станцию пилили изначально. А в коммутации каналов никаких "Номер АОН" нет.

Ваше предложение я понял - для PBX это была бы ещё одна степень свободы. Причём реализовываться это не должно сложно.

А можно как то на вашу сеть посмотреть в виде схемы? Интересует методы объединения сетей и схемы выходов в ГТС? Я сам работаю на телефонном коммутаторе и понимаю, что спрашиваю) Но если вдруг вы можете это как-то завуалировать и убрать критические данные...

[bravo]

С переадресацией вы какую-то дичь придумали конечно... т.е. если баба Клава с рабочего места ушла, а ей надо на мобильник переадресацию включить, она просит вас и вы делаете прям сию секунду, а когда приходит - убираете? Или я что-то не так понял? Как отбираются все эти "переадресации" ?

PS: уберите плюсики у номеров. а то это получается международка с формате international... или добавьте "7" после плюсика.

[SEA]

Не дичь, костыль пока работающего другого способа не придумано...

Баба Клава, чтобы включить переадресацию на свой мобильник (заранее определённый - это конечно минус) ставит переадресацию на номер из фиктивного пула. А ещё ей звонят с АОНами кривыми - фиктивными(точнее это может быть внутренний номер+префиксы выхода на узлы через которые он прошёл, например 6-076-35-200) и разной длины и типа, заранее неизвестными и комбинаций их ..... туча, поэтому АОН надо в обязательном порядке менять на приличный.

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

[SEA]

Схему предоставить не могу к сожалению...

И у Вас свой взгляд на это, с "узла" - наверное, привыкли на ОКСе сидеть, а он далеко не везде.
Я раньше в основном катался на SI-2000 v5, так там с ОКС никаких проблем не было, а для DSS можно было создать хитрый вариант когда АОН заменялся на номер В при CF и проблем не было. В конце концов на прежнем месте работы убедил руководство перейти на 10 значный АОН и внутри сети - проблемы как рукой сняло.
Сотовые операторы в этом плане молодцы - у них всё по E164 как я понял.

И, да, на текущем месте работы сеть корпоративная, здесь никто не знает о "сдать узел связьнадзору", а раз нет карающего меча, то и порядка нет.
У нас РТК не фильтрует номера от клиента, но как я понял на уровне биллинга отлавливает "левак" и потом смотрит техническое направление (поток Е1) и по башке даёт (вписывает в счёт) и там уже ты сам себе злобный буратино, если у тебя нижестоящий "клиент" балуется...

[bravo]

нуу, у меня два узла - один из которых местный. Так что DSS тоже полно (чуть более 50 потоков). Просто я с нуля всё делал, у меня всё в е164 и на каждой ТГ проверки и нужные преобразования имеются. Контролируется тип номера, что бы от заказчика ничего, кроме national/international, в план нумерации не попало. И категории оконечного элемента сети приписываю, как полагается по 46 приказу.
У всех нормальных операторов всё в е164 должно быть) как ни крути. Это всегда удобно во всех случаях жизни. На SI2000 можно было бы через City Connect ваш вопрос разрулить. Упоролись бы только список долбить =)


а разницы между SS7 и DSS я что-то не вижу в плане передачи параметров для анализа номера и маршрутизации...

[SEA]

Ну мы друг друга поняли
Разница есть в зависимости от типа сигнализации, пусть и не столь значительная: например маршрутизация по категории АОН - функция АТС, но эту категорию надо ещё получить и если у тебя ОКС или 2ВСК, то вэлком, а если нет, то бубен в зубы...

[bravo]

Не, категория оконечного элемента сети конечно фиксируется за операторами (а их всего сейчас 8 кажется)... но назначает её абоненту местный узел связи и только он. При этом сам не обязан её руководствоваться, так как он может сливать туда, куда ему удобно и куда есть возоможность. А вот зоновый узел уже обязан, так как у него должна быть возомжность слить куда надо - обязательно присоединение ко всем МгМн сетям.

[SEA]

Ну я говорю о разнице...Если я оконечный узел и хочу экономить, то мне это надо, а бывает нет техвозможности на ОКС и тогда будьте добры 2ВСК и начинается - выход на межгород (читай и сотовые) с занятием по 8 и переходом на декаду (хрен дождёшься пока простучит), разделение по направлениям и прочие прелести...Это я всё к чему - разница в тонкостях.
По нашим барашкам: переадресация при всей своей простоте на самом деле хороший индикатор кривости сети и часто головняк.
Элтекс об особенностях АОНа при переадресации знает, исправление в дорожной карте на эту проблемку планируется, осталось только дождаться когда. Ждём - это сильно поможет корпоративным сетям с закрытой нумерацией.
Про связку категория АОН+переадресация Элтексу тоже стоит подумать, если они позиционируют своё решение как операторское.

[bravo]

В БКП абоненты вызов выходит от абонента в категорией, которая назначена на потоке. Переадресация это или нет - не важно. Т.е. там всё нормально назначается. На smg не знаю, они у меня просто как транковые шлюзы.


А в чём экономия использования 2ВСК вместо ОКС? (у меня 2вск никогда в пользовании не было и в литературе я эту сигнализацию сознательно игнорировал)

[SEA]

Видимо меня не правильно поняли: экономия может быть при выборе оператора МГ/МН по категории АОН, а сигнализация здесь совершенно ни при чём, просто именно ОКС и 2ВСК её позволяют передавать, но 2 ВСК и ОКС это земля и небо как говорится...Просто если у тебя абоненты разные,т.е. хотят ходить через разных операторов, то намного проще поставить на абоненте категорию. В идеале с 1 потока должна быть возможность получения различных категорий и уже на её основе проводить маршрутизацию.
Назначение категории АОНа на потоке не совсем правильно - категория должна быть на каждом отдельном вызове.
И в случае переадресации в цепочке А-В-С, если у А категория 1, а у В категория 9 и например С-мобильник, то спрашивается на междугородке по какой категории должен отмаршрутизироваться вызов на С? Я считаю что правильно по 9, так как В пользуется 9 и по 1 его маршрутизировать (и выставлять счёт соответственно) нельзя.Соответственно узел, на котором сидит абонент В должен уметь при переадресации категорию 1 подменять на свою 9.
Хорошо что абоненты этого не знают и редко просят , а то мы бы зашились...
А вообще изначально тема не про это - пора заканчивать флуд, а то забанят...