Good day,
Today's post will focus on the subject, which have been increasingly interested in by my students and blog readers. We will talk about how to route the call in CUCM depending on the calling number. This problem arises, typically, in situations where you want to block incoming calls from certain numbers, or, vise versa, to allow incoming calls only from certain numbers and all other call must be denied. Consider, for example, that the second task, ie, let's deny all incoming calls, except calls from certain numbers.
As always, to simulate the case we are using our lab. In the lab we have CUCM version 8.6, Cisco 2811 Voice Gateway connected to simulated PSTN (CUCME, Numbering Plan of Ukraine) via E1:
The figure shows the topology used. Incoming calls will be done from three different telephone numbers - local, long distance, international. Calls are routed to the internal phone 2001. When considering the problem, we assume that the gateway does not change Calling and Called Numbers, ie passes the call to CUCM transparently. All manipulations with the parameters of the call will be made on the CUCM, in addition, the gateway settings at the CUCM do not make any modifications to the numbers as well. We also assume that for all types of calls our PSTN sends 7-digit Called Number 5552001. In our lab topology phone 2001 is in the partition Phones. Access to it is provided by CSS Phones_css.
Well, the problem is: allow incoming calls to the number 5552001 only from the local PSTN, but prevent calls from long-distance and international networks. It is very simple, if you have CUCM of version 8.0 or later :)
To solve this problem we will use a new property of Translation Patterns, which was introduced in CUCM release 8.0. Now there is a new option - Route Next Hop By Calling Party Number. The idea of this new option is that the call is returned to CUCM's routing table after reaching this Translation Pattern (this is typical system behavior). Then CUCM searches appropriate route (Route Pattern / Translation Pattern / DN) and select the pattern, which best matches to the Calling Number of our call! Please note - the selected route matches not Called number, as usual, but incoming Calling Number! This is crucial for understanding the proposed solution.
Let's move on, folks! First of all, we create a new Translation Pattern A, which corresponds to the Called Number for an incoming call. In this example the Called Number is 5552001. In the settings for this Translation Pattern we check the check-box Route Next Hop By Calling Party Number. Don't forget to choose the radio-button Route this pattern. Leave all other settings as default:
Once we have checked the check-box Route Next Hop By Calling Party Number in the Translation Pattern, the following occurs. When the call reaches this Translation Pattern (ie when you call on 5552001), CUCM begins looking for an object in the routing table with pattern, which corresponds to the Calling number. If the routing table doesn't contain such object, the call is denied and released. We can say that by default when the checkbox Route Next Hop By Calling Party Number is checked, all calls from any number are denied.
Therefore, to solve the problem let's create a kind of a "white list", which contains external phone numbers allowed for incoming calls. The "white list" are additional Translation Patterns (B, C, D, etc.; their quantity depends on how many calling numbers or ranges of numbers are allowed). The patterns of these additional Translation Patterns match the allowed Calling Number / Numbers. In our example we create Translation Pattern B with the pattern 5554444 (our allowed local PSTN Calling Number). The Translation Pattern B matches our local PSTN number, but at the same time it makes the conversion of the called number 5552001 to 2001. It has also the CSS, which gives access to the internal numbers (Phones_css):
That's the trick. Easy? Definitely! If you want to allow incoming calls to 5552001 from other PSTN numbers, then configure additional similar Translation Patterns. Thus, for long-distance number in our example we need a Translation Pattern with mask of 445554444 and similar settings for 5552001 -> 2001 conversion.
In my example, the call goes like this:
A customer (5554444) dials 5552001 -> Translation Pattern A (5552001, Called) -> Translation Pattern B (5554444, comparison of the Calling Number) -> Phone 2001.
If the incoming calls to 5552001 are done from other PSTN numbers rather than local 5554444, all of them are released, and therefore our problem is solved.
If desired incoming calls from all other numbers can be sent to any other internal number (eg, 2002). For this purpose we can configure a Translation Pattern with the pattern !:
Today's post will focus on the subject, which have been increasingly interested in by my students and blog readers. We will talk about how to route the call in CUCM depending on the calling number. This problem arises, typically, in situations where you want to block incoming calls from certain numbers, or, vise versa, to allow incoming calls only from certain numbers and all other call must be denied. Consider, for example, that the second task, ie, let's deny all incoming calls, except calls from certain numbers.
As always, to simulate the case we are using our lab. In the lab we have CUCM version 8.6, Cisco 2811 Voice Gateway connected to simulated PSTN (CUCME, Numbering Plan of Ukraine) via E1:
The figure shows the topology used. Incoming calls will be done from three different telephone numbers - local, long distance, international. Calls are routed to the internal phone 2001. When considering the problem, we assume that the gateway does not change Calling and Called Numbers, ie passes the call to CUCM transparently. All manipulations with the parameters of the call will be made on the CUCM, in addition, the gateway settings at the CUCM do not make any modifications to the numbers as well. We also assume that for all types of calls our PSTN sends 7-digit Called Number 5552001. In our lab topology phone 2001 is in the partition Phones. Access to it is provided by CSS Phones_css.
Well, the problem is: allow incoming calls to the number 5552001 only from the local PSTN, but prevent calls from long-distance and international networks. It is very simple, if you have CUCM of version 8.0 or later :)
To solve this problem we will use a new property of Translation Patterns, which was introduced in CUCM release 8.0. Now there is a new option - Route Next Hop By Calling Party Number. The idea of this new option is that the call is returned to CUCM's routing table after reaching this Translation Pattern (this is typical system behavior). Then CUCM searches appropriate route (Route Pattern / Translation Pattern / DN) and select the pattern, which best matches to the Calling Number of our call! Please note - the selected route matches not Called number, as usual, but incoming Calling Number! This is crucial for understanding the proposed solution.
Let's move on, folks! First of all, we create a new Translation Pattern A, which corresponds to the Called Number for an incoming call. In this example the Called Number is 5552001. In the settings for this Translation Pattern we check the check-box Route Next Hop By Calling Party Number. Don't forget to choose the radio-button Route this pattern. Leave all other settings as default:
Once we have checked the check-box Route Next Hop By Calling Party Number in the Translation Pattern, the following occurs. When the call reaches this Translation Pattern (ie when you call on 5552001), CUCM begins looking for an object in the routing table with pattern, which corresponds to the Calling number. If the routing table doesn't contain such object, the call is denied and released. We can say that by default when the checkbox Route Next Hop By Calling Party Number is checked, all calls from any number are denied.
Therefore, to solve the problem let's create a kind of a "white list", which contains external phone numbers allowed for incoming calls. The "white list" are additional Translation Patterns (B, C, D, etc.; their quantity depends on how many calling numbers or ranges of numbers are allowed). The patterns of these additional Translation Patterns match the allowed Calling Number / Numbers. In our example we create Translation Pattern B with the pattern 5554444 (our allowed local PSTN Calling Number). The Translation Pattern B matches our local PSTN number, but at the same time it makes the conversion of the called number 5552001 to 2001. It has also the CSS, which gives access to the internal numbers (Phones_css):
That's the trick. Easy? Definitely! If you want to allow incoming calls to 5552001 from other PSTN numbers, then configure additional similar Translation Patterns. Thus, for long-distance number in our example we need a Translation Pattern with mask of 445554444 and similar settings for 5552001 -> 2001 conversion.
In my example, the call goes like this:
A customer (5554444) dials 5552001 -> Translation Pattern A (5552001, Called) -> Translation Pattern B (5554444, comparison of the Calling Number) -> Phone 2001.
If the incoming calls to 5552001 are done from other PSTN numbers rather than local 5554444, all of them are released, and therefore our problem is solved.
If desired incoming calls from all other numbers can be sent to any other internal number (eg, 2002). For this purpose we can configure a Translation Pattern with the pattern !:
Note !!! In my lab CUCM has minimal configuration only, so I didn't not put my Translation Pattern ! into any partition (now this TP is in the partition None, ie available to all). In real situation, an additional partition for Translation Pattern ! and the corresponding CSS for Translation Pattern A (5552001) are necessary. This grants that the Translation Pattern ! applies to calls to 5552001 only, and it is not used for incoming calls to all other numbers.
If you want to solve the inverse problem - to allow calls from all PSTN numbers, but block only a few of them, you can read about it here:
https://supportforums.cisco.com/docs/DOC-18367
This is how it works. :) As you see, it is not so complicated. Have a nice evening!
Здравствуйте, Дмитрий! Я очень рад что появилась эта статья, потому что маршрутизация вызовов в CUCM наболевшая тема.. Translation Pattern очень полезный инструмент в маршрутизации, который придает гибкость при обработки звонков что по Called, что по Calling номеру. Но в тоже время, мое мнение, есть и минус у Cisco в этом. А если требуется проверять по Calling ID номеров так 100-150? это же нужно создавать дополнительные Partition и CSS чтобы фильтровать и столько же Translation Pattern'ов .. Думаю это все можно было бы как то проще организовать каким-нибудь Access-list'ом на входящий трафик.
ReplyDeleteДобрый день, Евгений.
DeleteВ некотором смысле с Вами соглашусь, что иногда приходится выполнять много действий по конфигурации, и что не все в ССМ сделано настолько удобно, как хотелось бы. Количество создаваемых объектов при конфигурации всегда зависит от задачи - иногда надо 1-2-несколько, иногда и десятки
Access-list для этих целей в ССМ еще не придумали ,увы. Блокировку вызывающих номеров можно сделать и в шлюзе, если шлюз работает по H323 или SIP (но никак не MGCP).
Здравствуйте Дмитрий!
ReplyDeleteА если есть необходимость управлять внутренними номерами, т.е. мне нужно некоторым внутренним номерам разрешить звонки на внутренний номер, а другим внутренним - запретить. Translation pattern'ы, я так понимаю, здесь не участвуют. Есть ли механизмы для реализации такой задачи или только при помощи partition & CSS?
Добрый день, Родион!
DeleteДля внутренних звонков partition и css решают все необходимые задачи по запретам/разрешениям, и этот механизм прекрасно работает. Нет смысла наворачивать что-либо еще.
Можно, конечно, поизвращаться и с транслэйшн паттерн (аналогично способу, описанному мной в посте), но, чтобы выбрать нужный транслэйшн паттерн, придется снова использовать partition и css...
Так если я буду создавать для каждого номера, которому нужны особые доступы partition и css, сколько же у меня их в итоге станет? Многовато.. Но если это единственный способ, буду плодить)
ReplyDeleteЭто уже зависит от конкретной задачи :) Если уж получается много css и partition, то может и есть смысл применить translation pattern.
DeleteТак сложно что-либо сказать, не зная условий решаемой задачи. Это - как лечить больного по фотографии :)
Здравствуйте! Скажите пожалуйста, а можно разграничивать (например, запретить международные номера, а остальные разрешить) в CUCM версии 7.1
ReplyDeleteДобрый день,
DeleteЕсли речь идет о разграничении вызовов по набираемому (вызываемому, Called) номеру, то да, можно. Это обычная практика. Для этой цели используются partition и css.
Маршрутизировать же вызова в зависимости от номера вызывающего (Calling) абонента стало возможным только с релиза 8.0.
Здравствуйте, Дмитрий!
ReplyDeleteЕсли есть возможность, проконсультируйте пожалуйста по поводу такого вопроса. У нас в офисе стоит UC520. Телефония через sip-транк. Исходящие вызовы идут на все номера, кроме Билайн (речь идет о городе Алматы, Казахстан, номера Билайн начинаются с +7 777). При наборе номера Билайн идут частые короткие гудки. Не можете ли Вы подсказать, с чем это может быть связано, что нужно настроить, чтобы исходящие вызовы проходили? Для настройки UC520 используем Cisco Configuration Assistant, есть доступ к командной строке.
С уважением,
Вадим
Добрый день, Вадим!
DeleteВ первую очередь нужно проверить, правильно ли настроены диал-пиры (есть ли у вас диал-пир для номеров Билайн и правильный ли он, включая настройку кодеков), а также проверить, не установлены ли запреты на звонки Билайн с помощью COR-листов.
Если конфиг правильный, тогда нужно дебажить звонки и смотреть, правильно ли пересылается сигнализация, какие сообщения SIP приходят от оператора и какая причина отбоя (cause) при звонках на Билайн. Для этого можно воспользоваться командой debug ccsip messages.
Я, кстати, буду скоро в Алмате и буду вести курс CVOICE в учебном центре БАС. Он как раз рассматривает все аспекты настройки голосовых шлюзов циско. Курс планируется на 30.09. Если есть желание и возможность поучиться - добро пожаловать на курс :) (это так, к сведению, я по возможности помогу Вам вне зависимости от того, придете Вы на курс или нет :) )
Здравствуйте, Дмитрий! Большое спасибо за Ваш ответ.
ReplyDeleteВвел debug ccsip messages в консоли UC520 - никакого вывода вообще при звонках, что удачных, что неудачных.
По поводу диал-пиров, вот все записи о диал-пирах в шоуран: https://gist.github.com/anonymous/6539500
Вывод команды sh dialplan number 987778525490: https://gist.github.com/anonymous/6539524
Я честно говоря без понятия, правильный конфиг или нет, потому что в телефонии знаний нету. Если по моему листингу сможете что-то подсказать, что и как исправлять, буду очень признателен.
В БАС сдавал CCNA R&S. Спасибо за информацию, буду думать.
Доброе утро, Вадим.
DeleteЯ посмотрел конфиг ваших диал-пиров. Вроде бы с ними все в порядке. При звонке на номер 987778525490 должен выбраться как исходящиий диал-пир 1000. На нем нет никаких запретов COR, по идее звонок должен уходить к провайдеру.
Нужно смотреть дебаг. Вы говорите, что не видите никакого вывода вообще. А вы подключаетесь к роутеру по телнету? или конольным кабелем? Если по телнету, то тогда нужно еще ввести команду terminal monitor, чтобы сообщения дебага отображались.
Если Вы подключаетесь консольным кабелем и нет вывода debug ccsip messages, то тогда давайте глянем debag voip ccapi inout.
Здравствуйте!
ReplyDeleteСорри, я про терминал монитор совсем забыл! Вот вывод дебага:
Неудача: https://gist.github.com/anonymous/6549667
Успех: https://gist.github.com/anonymous/6549679
Доброе утро, Вадим!
DeleteПосмотрел Ваши дебаги. Циска отправяет прову звонок! А что Вы слышите в трубке при неуспешном звонке? Попробую пояснить.
При успешном звонке Вы отправляете INVITE (запрос на установление соединения), далее от прова приходят 100 Trying, 180 Ringing (в этот момент Вы должны слышать длинные гудки посылки вызова). Далее Вы вызов, видимо, отбиваете, поэтому следует сообщение CANCEL со стороны циски.
При неуспешном звонке ситуация чуть иная. Вы отправляете INVITE , далее от прова приходит 100 Trying, но затем следует 183 Session Progress. Обычно это сообщение выставляется в ситуациях, когда встречная сторона может перед соединением проигрывать аудиосообщения (приветствия, информацию или даже те же длинные гудки). Далее через 6 секунд снова идет CANCEL от циски - видимо, Вы кладете трубку.
А что Вы слышите в трубке в эти 6 секунд? Какое-то сообщение? Короткие гудки?
В успешном вызове Вы звонили на 987758525490, в неуспешном - на 987775864211. Странно, что к прову Вы отправляете 9ку в обоих случаях. У вас прямой SIP-транк к прову, или через промежуточную АТС?
Здравствуйте, Дмитрий.
ReplyDelete6 секунд я слышу короткие частые гудки. SIP-Транк, насколько я знаю, через промежуточную АТС.
Возможно такое, что звонок на Билайн должен формироваться в каком-то особом формате? Инженеры с промежуточной АТС говорили о том, что Билайн требует особого формата, вроде бы в Avaya нужно выбрать national или international, в то время как другие операторы сами приводят звонки к своему формату. Но эти инженеры не знают, как это настроить в Cisco. Прошу прощение за объяснение в стиле блондинки, но возможно это натолкнет Вас на какую-то мысль, а я постараюсь завтра описать проблему точнее.
Дополнение: промежуточная АТС - Avaya, к ней SIP-транк, от нее - E1 к прову.
ReplyDeleteИнженеры с промежуточной АТС говорят, что никак не преобразовывают наши вызовы. Пров вроде как получает тип звонка - unknown. На Avaya они для себя вроде бы поменяли call type на pub, что ли, и все заработало (звонки на 777).
Скорее всего они сделали что-то с типом номера. Вы на циске не решили бы эту проблему. Дело в том, что в протоколе сигнализации SIP не предусмотрена передача типа номеров. Все номера имеют тип unknown.
DeleteДругое дело, если бы к промежуточной АТС было бы подключение по Н323 или Е1 PRI. В этих системах сигнализации поддерживается передача разных типов номеров: Unknown, Subscriber, National, International.
Поэтому, изменение типа номера на Avaya было единственно возможным и правильным решением.
Дмитрий, прошу прощения, но у меня еще вопрос. С 777 пока не разобрались, возникла новая проблема. У нас есть две линии телефонные, воткнутые в 2 порта FXO на UC520. Есть 4 порта FXS. Им всем назначены extension - с 401 по 403 и 504. Нужно, чтобы звонки с двух портов FXO перебрасывались на нулевой порт FXS - 0/0/0, у которого внутренний extension 504. Как это можно настроить на UC 520 через интерфейс CCA или ком. строку?
ReplyDeleteдиал-пиры: https://gist.github.com/anonymous/6539500
воис-порты:
voice-port 0/0/0
cptone RU
timeouts ringing infinity
caller-id enable
!
voice-port 0/0/1
cptone RU
timeouts ringing infinity
description fax
caller-id enable
!
voice-port 0/0/2
cptone RU
timeouts ringing infinity
!
voice-port 0/0/3
cptone RU
timeouts ringing infinity
!
voice-port 0/1/0
cptone RU
connection plar opx 504
description Configured by CCA 4FXO-0/1/0-Custom-OP
caller-id enable
!
voice-port 0/1/1
cptone RU
connection plar opx 504
description Configured by CCA 4 FXO-0/1/1-Custom-OP
caller-id enable
!
voice-port 0/1/2
input gain 9
connection plar opx 504
description Configured by CCA 4 FXO-0/1/2-Custom-OP
caller-id enable
!
voice-port 0/1/3
cptone RU
connection plar opx 504
description Configured by CCA 4 FXO-0/1/3-Custom-OP
caller-id enable
!
Доброе утро, Вадим.
DeleteСудя по конфигу, у вас уже все настроено для того, чтобы звонок с FXO приходил на 504. Это делается на порту FXO с помощью команды connection plar opx 504. И все равно звонки у вас с FXO не приходят? А раньше это работало?
Сам телефон 504 сконфигурирован? Звонит, если на него с внутреннего телефона позвонить?
Дмитрий, поправил конфигурацию, удалил/снова залил для порта FXS 0/0/0 экстеншн 504. Сейчас в порты включено так:
ReplyDeleteFXO 0/1/0 - городская линия 3929750,
FXO 0/1/1 - городская линия 3929727,
FXS 0/0/0 - офисный телефон с экстеншн 504,
FXS 0/0/1-3 - офисные телефоны с экстеншнами 401-403, они используют номер 2597331 как и ip-телефоны, этот номер приходит через SIP-транк.
Сейчас поведение такое: при звонке с офисных телефонов на 504ый все нормально, с 504ого на офисные - все нормально, звонки идут. При звонке с сотового например на 3929750 или 3929727 звонок идет на 504ый с небольшой временной задержкой. При звонке с 504ого на мобильный (звонок через 9ку: 98775.......), скажем, на мобильном отображается номер исходящего - 727 2597331, т.е. SIP-номер. Возможно ли как-то настроить 504ый так, чтобы при звонке в город или на мобильные звонок шел как бы с одного из номеров, включенных в FXO порты, при этом сохранилась возможность с офисных телефонов переводить звонки и вообще звонить на 504 и обратно, с 504 на офисные телефоны?
Доброе утро, Вадим!
ReplyDeleteНомер SIP отображается потому, что звонок в город с 504 идет по SIP-транку, а не через FXO-порт. Конечно, сделать так, чтобы звонок отправлялся с 504го через FXO, можно. Для этого потребуется применение COR-листов.
Нужно сделать дополнительные диалпиры (pots) с destination-pattern для городских звонков (начинающихся с 9ки: 91.., 9[2-3]......, 98.........., 9810T), и указать в них нужный порт FXO. Далее с помощью COR-листов разрешаем 504му совершать исходящие через диалпир с FXO, а всем остальным - через диалпиры с SIP.
Вот такой механизм.
Дмитрий, добрый день!
ReplyDeleteХочу поблагодарить Вас за то время, которое вы уделяете на растолковывание непонятных моментов для нас.
Обращаюсь к Вам за помощью. Мне никто не может дать исчерпывающую информацию о разнице между translation и transformation паттернами. А именно, я не могу понять зачем в принципе нужны transformation паттерны? Что они могут такого, чего не могут translation паттерны? В каких ситуациях стоит их использовать?
Буду рад услышать Ваше мнение по этому вопросу. Спасибо!
Доброе утро,
DeleteПопробую кратко разъяснить разницу (собираюсь написать о transformation pattern пост, но все никак нет свободного времени).
Назначение Translation Pattern и Transformation Pattern одинаково - они применяются для модификации номеров (как Calling, так и Called). Разница между ними состоит в моменте "срабатывания", т.е. в каких случаях работает Pattern.
Translation Pattern работает В МОМЕНТ маршрутизации вызова, и срабатывает исключительно по набранному (Called) номеру. Модификации применяются только в том случае, если набранный номер попадает под прописанную в ней маску. Например, если набирался номер 5552001, а маска Translation Pattern была 5552ХХХ, то такая Translation Pattern отрабатывает, и выполняются прописанные в ней правила преобразования.
Transformation Pattern работают ПОСЛЕ маршрутизации. Они срабатывают в тот момент, когда вызов отправляется в выбранное устройство: в шлюз, в транк, на телефон (в телефонах применяются только Сalling Transformation Pattern). Существуют два типа Transformation Pattern - для Calling и Called номеров соответственно, и они срабатывают, если Calling или Called номер соответствуют их маске. Механизм такой: вызов прошел таблицу маршрутизации, выбрался Route List, Route Group и шлюз/транк/телефон, и после этого проверяются Calling и Called номера, и далее, если есть соответствие Transformation Pattern, производится модификация номера.
Пример использования Transformation Pattern - например, имеются 2 порта Е1, подключенных к разным провайдерам, и требуется чтобы к провайдерам звонки уходили с нужным Calling-номером: к одному провайдеру с одними Calling, к другому - с другими.
Более подробно с примерами и скриншотами работу Transformation Pattern опишу в посте. :)
Здравствуйте Дмитрий!
ReplyDeleteС недавнего времени активно использую в работе Call Manager правда 7 версии. Перед началом работы с ним перечитал много литературы по нему. И у меня как-то устоялось в голове (возможно неправильно), что входящий вызов с внешней линии обрабатывается либо hunt pilot либо translation patterns. Но встретил конфигурацию, в которой для обработки входящего внешнего вызова используются два этих способа.
Буду рад услышать ваши комментарии по этому вопросу.
Позволю себе задать еще один вопрос.
ReplyDeleteЕсть ли способ узнать какому hunt list привязана line group?
Доброе утро,
DeleteПостараюсь ответить на оба Ваших вопроса.
1. Неправильно считать, что входящие вызовы обрабатываются только Hunt Pilot или Translation Pattern. Входящий вызов приходит на устройство (Device), коим является шлюз или транк. Далее вызов направляется в ТАБЛИЦУ МАРШРУТИЗАЦИИ. Помимо Hunt Pilot и Translation Pattern, в ней также содержатся DN, Route Pattern, Call Park, MeetMe. Система сравнивает Called номер пришедшего вызова с записями в таблице маршрутизации, выбирает одну из них по наибольшему совпадению и отправляет вызов далее на устройство, связанное с выбранной записью. Если выбрался Hunt Pilot, то вызов отправляется на Hunt List, если был выбран DN - на телефон, если Route Pattern - на Route List, если Translation Pattern - то выполняются преобразования номеров и вызов после этого снова отправляется в таблицу маршрутизации.
Исходя из вышесказанного, вполне возможно, что входящий вызов придет на телефон, минуя Hunt Pilot или Translation Pattern. Например, если из города набирался номер 5552001, а DN у внутреннего телефона тоже 5552001, то вызов приходит прямо на DN. Или набираем тот же номер 5552001, а DN внутреннего 2001, но на шлюзе/транке настроено Significant Digits 4 (т.е преобразовать Called номер так, чтобы осталось 4 последних цифры), то вызов также придет на DN.
2. В настройках самого Hunt List Вы можете увидеть ассоциированные с ним Line Group. Возможно (не помню на память), что это Вы также сможете увидеть в Call Routing -> Route Plan Report. Собственно, это даст Вам возможность увидеть всю таблицу маршрутизации.
Спасибо за ответы.
ReplyDeleteПо первому стало понятнее, но возникли новые вопросы, у меня чуточку по другому картина сложилась в голове. Надо будит повторить пройденное, так сказать. Дмитрий можете подсказать хорошую литературу VoIP, в конкретном случае для Cisco?
По второму внесу пояснения. Call Routing -> Route Plan Report показывает привязанные к DN Line Group. А вот какому Hunt List принадлежит Line Group выяснить, используя Route Plan Report, не получается. У нас есть один или два номера, к которым привязана Line Group и исходя из схемы звонков, для данного DN, она не должна принимать участие в hunting. Я руками просмотрел все Hunt List, но ее там не нашел. Вот и возник вопрос можно ли это как-то автоматически, более наглядно реализовать.
Добрый вечер,
DeleteСамое лучшее, если есть, конечно, возможность - это проcлушать курс CIPT1 в одном из учебных центров. Если нет - в сети можно найти книги из серии Cisco Press с материалами по данному курсу.
По второму вопросу - если Line Group не привязана ни к одному HL, то она не участвует в хантинге. Затрудняюсь ответить, есть ли еще какой-либо способ, кроме просмотра вручную.
Здравствуйте Дмитрий.
ReplyDeleteСпасибо большое за вашу помощь.
Скажите пожалуйста, как с списке исходящих номеров сделать так, чтобы отображалось имя, а не номер. Может его можно заставить брать ФИО из корпоративный каталог (End User). CUCM 8.6
Добрый день, Артур!
DeleteПопробуйте прописать имена в настройках DN. Там есть поле Display Name. По идее, тогда будет отображаться и имя, и номер (проверить, к сожалению, не могу, так как в настоящий момент нет под рукой лабы).
Спасибо за уделенное внимание и ответы.
ReplyDeleteДмитрий позвольте у вас спросить. С недавнего времени обратил внимание, при звонке (вх/исх) на городской или мобильный телефон, тот кто стоит на стороне цифрового телефона слышит пропадания и заикания речи. А при звонках на внутренние телефоны такого не наблюдается. В настройках Call Manager`а ничего не менялось. В чем может быть причина?
ReplyDeleteДоброе утро,
DeleteНужно проверить настройки QoS на участке сети от шлюза до телефонов. Пропадания и заикания речи обычно связаны с перегрузкой сети. Возможно, что причина может быть и в самом шлюзе, если его DSP работают некорректно или повреждены.
CDR CMR DUMP одного из соединений показывает, что кодеки используемые телефоном и кодеки, используемые SIP провайдером, отличаются. На телефоном G.711 mu-Law 64K origMediaCap_payloadCapability = 4, у провайдера G.711 A-Law 64K destMediaCap_payloadCapability =2 (если я правильно понимаю значения этих показателей). Это может быть проблемой?
ReplyDeleteНет, не думаю, что это проблема. Думаю, что у вас звонок проходит через МТР, которое преобразует кодек G711mu в G.711a. Такое очень часто встречается, когда ССМ подключается в город через SIP-транк. Поэтому, одно плечо звонка (до МТР) содержит кодек 711мю, а второе - 711а.
DeleteЗдравствуйте. А в 9 CUCM такая маршрутизация возможна? Там нет такой галочки
ReplyDeleteДобрый день. Прошу извинить меня за задержку с ответом - слишком большая загрузка осенью. По идее, такая маршрутизация должна быть возможна и в CUCM9. Согласно админгайду по релизу 9.1, там тоже есть галочка Route Next Hop By Calling Party Number в настройках Translation Pattern:
Deletehttp://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/9_1_1/ccmcfg/CUCM_BK_A34970C5_00_admin-guide-91_chapter_0101011.html
Извините, я не туда смотрел, перепутал route pattern с translation pattern. Да, все есть.
DeleteНичего страшного, бывает и так :) Это не смертельно. Теперь Вы знаете, где искать.
DeleteДобрый день, хотелось поблагодарить за содержательный блог и задать вопрос по CUCME. Есть ли простой способ, т.е. без использования COR, разрешить звонок номер секретаря <=> номер директора, т.е. сделать так чтобы директор со своего номера мог звонить кому угодно, а ему на его номер мог звонить только секретарь и еще несколько внутренних номеров?
DeleteДоброе утро,
DeleteСпасибо за Ваш отзыв.
По поводу Вашего вопроса: COR - это основной способ ограничения звонков на те или иные номера. Можно еще попробовать ограничивать звонки с помощью правил и профилей трансляций номеров. Идея такая: для тех, кому нужно запретить звонки на какие-либо номера пишется правило и профиль трансляции для Called номеров. В правиле прописывается, что запрещенный к набору номер преобразуется в несуществующий (т.е такой, который не сконфигурирован в СМЕ). Например, пусть у директора прописан номер 2222. Тогда правило преобразует его в любой несуществующий, например в 5555 (2222 -> 5555).
Затем профиль трансляции применяем для исходящих звонков в тех ephone-dn, которым вводим ограничения.
Привожу пример конфига (2222 - номер директора, 5555 - несуществующий номер, 2001 - номер абонента, которому мы ограничиваем права на звонки)
voice translation-rule 1
rule 1 /^2222$/ /5555/
!
voice translation-profile director_restricted
translate called 1
!
ephone-dn 1
number 2001
translation-profile outgoing director_restricted
Спасибо, с translation-profile, действительно выглядит проще, чем COR.
ReplyDeleteДоброго времени суток. Спасибо за блог.
ReplyDeleteМожно вопросик, есть ли возможность на ISR или на CUCM настроить переадресацию на городской номер с добавочным в тоновом наборе?
Спасибо
Добрый вечер, Евгений!
DeleteСпасибо за отзыв. Раньше с этим донабором была прям беда. В ССМ релиза 9.0 появилась возможность донабора номера в клавишах Speed Dial. Посмотрите вот этот мой пост:
http://dbenda.blogspot.com/2013/01/cucm-90-speed-dials.html
С переадресацией я не пробовал такой вариант. Однако, чем черт не шутит. Попробуйте, возможно это тоже работает.
Добрый день, Дмитрий. Подскажите как выходить из ситуации, когда необходимо номера приходящие с одного SIP Trunk - маршрутизировать в разные Gateway в зависимости от Calling number. (Called может быть любой)
ReplyDeleteДобрый день, Дмитрий! В таком случае Вы можете применить описанную мной схему. Только в Translation Pattern B в поле Called Party Transformation Вам нужно будет указать промежуточный номер (например, 8888), потом сделать Route Pattern 8888, ведущую к нужному RL, RG, шлюзу.
DeleteСхема прохождения звонка:
Translation Pattern A (5552001, Сalled) -> Translation Pattern B (5554444, сравнение Calling-номера, преобразование Called в 8888) -> Route Patten 8888 -> Route List-> Route Group -> Gateway.
Добрый день, Дмитрий! Очень интересные и познавательные статьи, помогли в настройке MGCP и SIP. А возможно как то сделать принцип связи Директор-Секретарь. У директора номер например 1001 (его все знают и звонят на него), у секретаря 1002. На старой АТС Коралл у директора на телефоне была кнопка полная переадресация на секретаря (1002) и при желании он ее нажимал. Абонент звонил на 1001, попадал на 1002 и в дальнейшем секретарь соединяла абонента с директором. в данном случае переадресация с 1001 на 1002 игнорировалась. К сожалению так не работает на CUCM, Может Вы сталкивались с данным вопросом? Очень хотелось бы реализовать что то подобное на CUCM 10, Заранее благодарен.
ReplyDeleteДобрый день, Алексей! Спасибо за Ваш отзыв. Такой функционал можно реализовать и на CUCM. Почитайте, пожалуйста, про Cisco IP Manager Assistant. Вот тут, например:
Deletehttp://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmfeat/CUCM_BK_CEF0C471_00_cucm-features-services-guide-90/CUCM_BK_CEF0C471_00_cucm-features-and-services-guide_chapter_01110.html
или тут:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmfeat/CUCM_BK_CEF0C471_00_cucm-features-services-guide-90/CUCM_BK_CEF0C471_00_cucm-features-services-guide-90_chapter_0100110.html
Добрый день!
ReplyDeleteЗабрел на ваш блог. Очень понравилось, спасибо!
Здравствуйте, Олег! Спасибо за Ваш отзыв. Приятно, что мой труд полезен и нужен для других.
DeleteДобрый день, Дмитрий!
ReplyDeleteСпасибо за Ваши статьи и ответы на комментарии. Многое по CUCM становиться ясным. Подскажите, возможно на группах абонентов относящихся к одной партиции ставить свой CID для последующей маршрутизации на один и тот же шлюз (транк)?
Спасибо. Александр.
Александр, добрый день!
DeleteНе понял Ваш вопрос, если честно. Поясните, пожалуйста, что вы имеете ввиду под CID? Правильно ли я понимаю, что вам нужно одной группе абонентов разрешить исходящие звонки через один шлюз (транк), а другой группе - через другой?
Расскажите, пожалуйста, о своей задаче поподробнее.
Зачитался! Спасибо за ваши труды - понятно и доступно!
ReplyDeleteБольшое спасибо за отзыв. Приятно осознавать, что мой опыт кому-либо полезен.
Delete