Читал FAQ "10. Как закрыть входящий поток одним АОНом"
http://bbs.radiolink.ru/forum/showthread.php?s=&threadid=9738

У меня похожая проблема, только я бы сказал - нужно выдавать оператору определённый А-номер (другие номера он не пропускает).
Если бы у меня был один оператор - не было бы проблем, а это второй PRI (от мобильного оператора).
Для первого оператора на всех внутренних номерах прописаны честные CLID, и не красиво менять на них на всех CLIDы чтобы выходить на мобильные через второй PRI.

Попробовал по FAQ использовать Billing Number.
Правда у меня один двунаправленный Rout (DID, EURO), я на нём прописал
SBN YES
BILN YES
BLEN х
BNUM xxxxxxxxx
Не работает - в поток всё равно идёт CLID прописанный на внутреннем номере.
Может корифеи подскажут - возможно ли это в принципе или может я где-то что-то не включил ?

billing number не пойдет, это для транзитных соединений.

Отдать в другой PRI отличный номер от первого PRI не получится... к сожалению...
Если я не прав, буду только рад :)

P.S. В rdb блоке есть параметры:
CPFXS (YES) NO Customer-defined Prefixes
HNTN 0-9999 Home National Number
HLCL 0-9999 Home Local Number

Но при выходе на поток, к этим параметрам в а-номере все равно будет добавляться DN.

2 Ocean Спасибо, порою в этом направлении
Может можно отключить добавление DN
Нашёл вашу тему "Cpfxs No минус Dn", ответа в форуме не видел, и как вы это обошли ?

Seluk_a пишет

Нашёл вашу тему "Cpfxs No минус Dn", ответа в форуме не видел, и как вы это обошли ?

Средствами Меридиана проблема не была решена... договорился с вышестоящим оператором, что они сами закрывали мой поток одним а-номером.

А мой вышестоящий оператор упёрся:(

Ставите коммутатор м-200 МР-4 с 4E1 потоками и отдаете оператору все чего он пожелает..
Средствами Меридиана сильно с модификацией номеров не поиграешь.:mad:

Это и обидно... новые релизы станции все выходят, а ни каких улучшений манипуляции а-номера не добавляют.
Приходится огород городить из разного рода железа третьих производителей.
А поставленная в данном топике задача встречается очень часто.

Ocean пишет
billing number не пойдет, это для транзитных соединений.

Отдать в другой PRI отличный номер от первого PRI не получится... к сожалению...
Если я не прав, буду только рад :)

P.S. В rdb блоке есть параметры:
CPFXS (YES) NO Customer-defined Prefixes
HNTN 0-9999 Home National Number
HLCL 0-9999 Home Local Number

Но при выходе на поток, к этим параметрам в а-номере все равно будет добавляться DN.


Чтобы вместо различных DN добавлялся один и тот же определенный номер, используем SDID. Хорошо если все внутренние номера начинаются на одну цифру, тогда ее преобразуем в тот самый номер. Чтобы не было конфликта, входящие городские в этой же IDC-таблице заруливаем на CDP LSC + DN, в LSC отрезаем первые цифры и получаем DN.

Данная задача, манипуляция разными CLIDaми при большом кол-ве маршрутов, не есть задачей PBX, коим является Меридиан. Для подобного рода задач необходимо покупать операторский CO-свич ,например CS2000. Поэтому нужно растолковать оператору, который уперся, что клиент не будет менять оборудование из- за того, что оператору влом подставить пилотный номер.
А вообще можно попытаться выкрутиться, сделав петлю на какойнить другой маршрут (СOшки, VoIP), а потом завернуть опять в PRI.
Другой вариант, договорться с первым основным оператором ,чтобы он подставлял пилотники, а на второго отдавать честные СLIDы.

shved пишет
Данная задача, манипуляция разными CLIDaми при большом кол-ве маршрутов, не есть задачей PBX, коим является Меридиан.

Два PRI ни есть большое количество маршрутов, а типовая ситуация (да и два городских номера на одном DN от двух разных операторов бывает). Манипулировать и анализировать CLID ни кто не требует, задача: PRI поток закрыть одним CLID без каких либо условий... не вижу тут задачи для которой нужна станция уровня carrier.

P.S. В блоке rdb в CPFXS был бы достаточен параметр по аналогии с таблицей CLID: DIDN no. И не было бы вопросов.

To Ocean:
Я умом понимаю, что на самом деле убрать бы это т паровоз в виде вн. DN, и не было бы проблем. Но, я привел пример аргумнтации для оператора, чтобы он со своей стороны был более лояльным и позволил подстановку своего пилотного номера, что в этом такого? Для большинства нормальных операторов это обычная практика. Или станции операторов не умеют подставлять пилотніе номера, или они не хотят, или у их менеджеров не налажено взаимодействие со своим техническим отделом ? Сам не раз сталкивался с такими твердолобыми операторами, поэтому не могу их понять.

Ocean пишет
P.S. В блоке rdb в CPFXS был бы достаточен параметр по аналогии с таблицей CLID: DIDN no. И не было бы вопросов.
А если бы части абонентов на руте потребовалось DID YES ? Опять затык. :) Я не к тому, что такая возможность была бы плоха (сам не раз горевал по этому поводу), просто тут надо делать более гибчее...

Ocean пишет

Отдать в другой PRI отличный номер от первого PRI не получится... к сожалению...
Если я не прав, буду только рад :)


Через phantom DN со своим CLID ENTRY работает.

А как фантом DN привязать к потоку ?
Можно поподробнее как это работает ?

Например,

FTR DCFW 16 XXXX,
где XXXX = ACOD к PRI руту

далее прикрутить к 9 - ке phantom DN.

Так получиться, что все кто захочет позвонить в город (а не только на мобильный) будут выходить через PRI мобильного оператора.
А мне нужно чтобы звонки на городские номера шли через городского оператора, а на мобильные - через мобильного.

9 - ка была указана для примера, это может быть любая другая цифра или комбинация цифр (мобильные префиксы к примеру).

Пока сделал влоб, благо первый оператор как оказалось не обращает внимание на мои А-номера.
А теперь вернулся к попыткам сделать как надо.
С фантомным не проходит - CLID то я ему прописал по по ACOD выхожу на канал, но выдимо после переадресации не сохраняются набранные после акода цифры.
Судя по трассировке - просто нет исходящего номера

Malex пишет
А если бы части абонентов на руте потребовалось DID YES ? Опять затык. :) Я не к тому, что такая возможность была бы плоха (сам не раз горевал по этому поводу), просто тут надо делать более гибчее...


Вот меня это единственное бесит. С клидами сложности. Все могут, а Меридиан не может. Причем для 911 они ж забили гвоздь, там можно делать отдельные. А вот я бы сделал так, по простому, добавил бы в блок tn возможность прописать несколько клид ентри на номер. Т.е. <DN/key> <EntryX> [Entry1] ... [EntryN]

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

А вообще хотелось бы нормальное управление и транзитными тоже. Т.е. добавить что-то типа барса-нарса, но для клидов. Был бы шик.

Новые релизы выходят, какой то функционал добавляют, но похоже, что касается CLID, наши желания не совпадают с желаниями вендора :)