Cisco 1760 исходящие dial-peer.

[SUrov_IBM]

Уважаемые знатоки, доброго времени суток.

 

Имеется действующая схема - маршрутизатор Cisco 1760 обеспечивает исходящие вызовы (местные и мобильные номера) из VoIP сети в сеть ТфОП (ISDN PRI).

 

[VOIP (SIP)] => {Cisco 1760} => [ТфОП (ISDN PRI)]

 

Для этого используются dial-peer:

 

dial-peer voice 100 pots

 description «местные»

 destination-pattern .......$ (семизначный номер)

 

dial-peer voice 110 pots

description «мобильные»

destination-pattern 89.........$

 

Вызовы из VoIP сети успешно проходят, с использованием данных dial-peer.

 

Задача:

 

По аналогии с VoIP, к маршрутизатору добавился поток T1 (non-ISDN) от мини-АТС,

для совершения исходящих вызовов в сеть ТфОП (ISDN PRI).

 

[T1 (non-ISDN)] => Cisco 1760 => [ТфОП (ISDN PRI)]

 

 

Вопрос:

 

Вызовы абонента ТфОП (семизначный номер) со стороны T1 (non-ISDN) успешно обрабатываются по «destination-pattern .......$».

 

При этом вызовы мобильного номера (в отличие вызова осуществляемого из VoIP сети)

попадает в обработку того же  «destination-pattern .......$», игнорируя существующий «destination-pattern 89.........$». То есть набирается 89xxxxx$ вместо 89xxxxxxxxx$.

 

 

Аналогичная ситуация происходит с вызовами по «destination-pattern 89.........$», если в маршрутизатор установить модуль FXS карты и позвонить с аналогово ТА в сеть ТфОП (ISDN PRI).

 

Если dial-peer voice 100 pots отключить, вызовы пройдут успешно.

 

Пожалуйста, подскажите как правильно указывать dial-peer исходящих вызовов от устройств non-ISDN и не VoIP, в данной схеме.

 

Заранее благодарю.

 

[vurd]

Никогда не занимался подобным, но если эти pots аналогичны роут мапам, то я бы поменял их местами, т.е. вместо pots 100, сделал бы pots 200. Возможно оно просто по приоритету "первое совпавшее" улетает не туда.

P.s. на рамках догадок о логике цисок

P.p.s.

https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/14074-in-dial-peer-match.html

The longest prefix matching criteria applies while each step is performed. At each step, if multiple matches are found, the one with the longest explicit match is chosen

[Sergey Taskin]

Кроме destination-pattern можно юзать answer-address и incoming called-number.
Не пробовали?

[SUrov_IBM]

В 10.10.2018 в 00:15, vurd сказал:

Никогда не занимался подобным, но если эти pots аналогичны роут мапам, то я бы поменял их местами, т.е. вместо pots 100, сделал бы pots 200. Возможно оно просто по приоритету "первое совпавшее" улетает не туда.

P.s. на рамках догадок о логике цисок

P.p.s.

https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/14074-in-dial-peer-match.html

The longest prefix matching criteria applies while each step is performed. At each step, if multiple matches are found, the one with the longest explicit match is chosen

Vurd, здравствуйте.

 

К сожалению, изменение номера pots, не является важным параметром в обработке звонков - вызовы проходят по такой же схеме.

[SUrov_IBM]

В 10.10.2018 в 06:26, Sergey Taskin сказал:

Кроме destination-pattern можно юзать answer-address и incoming called-number.
Не пробовали?

Sergey Taskin, здравствуйте.

Данные команды мне знакомы, просто не хотелось бы, строить очень мощные «костыли», с захватом входящего вызова.

 

При том, что VoIP "звонит" совершенно спокойно, будучи "non-ISDN" в данной схеме.
 

Была надежда разрешить вопрос «малой кровью», но похоже не получится.

[vurd]

11 часов назад, SUrov_IBM сказал:

Vurd, здравствуйте.

 

К сожалению, изменение номера pots, не является важным параметром в обработке звонков - вызовы проходят по такой же схеме.

Там в доке матч паттерны довольно хорошо расписаны, почитайте. Думаю, если вникнуть, то всё получится.

Готовогг рецепта у меня, к сожалению, нет.

[ShumBor]

Мне в свои времена, когда я 2801 настраивал e1<>SIP, помогла эта статья http://subnets.ru/blog/?p=1299 , может там что-то из картинки прохождения вызова удастся почерпнуть, по крайней мере я по ней  смог починить свою проблему заворота входящего вызова обратно в поток откуда он пришел(у меня мой диапазон как есть как на sip, так и на e1, циска ставилась для g729/t38, т.к основная атс смогла без глюков только G711 в sip). 

 

 

[SUrov_IBM]

Уважаемые знатоки, спасибо за Ваши советы и ссылки на статьи!

 

 

В общем, мою проблему удалось разрешить кране простым, но возможно не правильным образом.

destination-pattern .......$ в dial-peer voice 100 pots, был заменён на [1234679]......$

 

Что позволило осуществить исходящие (семизначные) звонки в ТфОП, если номер не начинается с цифры «8».

 

Согласно реестру нумерации, в префиксе 812 (Санкт-Петербург) я не нашёл семизначных номеров начинающихся с цифры «8»,

поэтому пока решил оставить схему исходящего вызова в таком виде:

 

dial-peer voice 110 pots
 description All-Russian mobile calls
 destination-pattern 89.........$

dial-peer voice 100 pots
 description Local Saint-Petersburg city calls
 destination-pattern [1234679]......$

Edited October 21, 2018 by SUrov_IBM

[YuryD]

Диалпиры не определяют pots/неpots. И там могучие регеэкспы, умеющие дофига. Ну или если лень - можно манипулировать подстановками номеров хоть в A хоть в Б. Ну и в стиле циско - список соответствий определяется номером правила, тот что что меньше - сначала, и если в него попало - дальше фишка не идёт.