Many of my readers and students are very interested in the topic of how to connect their CUCM to IP telephony service provider via SIP-trunk. This topic is very relevant, as more and more providers offer SIP services and connections, in addition to traditional E1 or BRI lines. This post will discuss the basic settings for SIP-trunks (i.e. without DTMF, fax settings, transfers, etc.).
In my example I will connect my lab CUCM to Russian ITSP Telme (http://tel-me.ru). I have created a basic account there and received one internal directory number for our test. The DN is 00044847. The connection parameters are as follows:
1. SIP trunk between CUCM and CUBE.
2. SIP connection between the CUBE and the provider.
First, we set up SIP trunk on CUCM. As usual, screenshots illustrate the process. Go to the CM Administration, then select Device -> Trunk -> Add New and add a new SIP trunk. Specify the trunk Name, Description, Device Pool, and do not forget to check Media Termination Point Required check box. It is necessary first of all to enable SIP Early Offer signaling, and also solves many other problems (DTMF in-band, problems with call transfer, alaw / ulaw conversion, etc). If you use this check box in your system, there must be preconfigured and registered MTP already (what MTPs are and their role you can find here):
Updated: I wrote this article a long time ago, and MTP Required check box was the only one solution to enable SIP Early Offer on the trunk in CUCM 8.0. However, in newer CUCM there are some other options for the Early Offer and you can read about them in my recent post – How to enable Early Offer in SIP Trunk CUCM?
For outgoing calls create a Route Pattern. I will check outgoing calls by making call to a SIP terminal registered at the same provider (its number is 00012345). It is also possible to call provider’s technical support number, which is 00010004. Therefore, I will configure Route Pattern 9.00xxxxxx (9 is an Access Code to this destination). In a real system you will need to set up additional Route Patterns for calls to other directions:
When calling to SIP provider network, it is required to send a correct Calling number (CLID), which is required by your provider. Otherwise the call will not be allowed. Therefore, in Route Pattern settings let’s make appropriate Calling number manipulation. In our example we have only one number from the provider, so I use it. If the provider gives you a few directory numbers, a more complicated translation might be done. Do not forget to remove the Access code (9) from the Called Number:
For incoming calls to CUCM let’s create a Translation Pattern. To reach our CUCM from SIP network we dial 00044847. This number must be converted to one of the CUCM’s extensions, for example, to 2002:
Now, the basic CUCM setup is completed . It’s time to continue with the CUBE. Here are the network interface settings (assuming the routing configuration has already been done):
interface FastEthernet0/0.100
description WAN
encapsulation dot1Q 100
ip address 10.10.100.11 255.255.255.0
!
interface FastEthernet0/0.111
description HQ-1 Servers
encapsulation dot1Q 111
ip address 10.1.1.101 255.255.255.0
!
interface FastEthernet0/0.112
description HQ-1 Phones
encapsulation dot1Q 112
ip address 10.1.2.101 255.255.255.0
IP-IP calls are prohibited at Cisco voice gateways by default. Therefore, let’s allow such calls as well as make SIP signaling binding to one of the interfaces: to the interface, whose address we have configured at CUCM SIP trunk):
voice service voip
allow-connections sip to sip
sip
bind control source-interface FastEthernet0/0.100
Then configure SIP UA settings for registration and authentication at the ITSP network:
sip-ua
credentials username 00044847 password ciscolab realm sip.telphin.com – регистрирует номер 00044847 в сети провайдера
authentication username 00044847 password ciscolab realm sip.telphin.com – указывает параметры аутентификации при исходящем звонке.
registrar dns:sip.telphin.com:5068 expires 3600 – адрес сервера Registrar
sip-server dns:sip.telphin.com:5068 – адрес прокси-сервера, через который будем осуществлять исходящие звонки
Now it is time to make voice dial-peers: one or more dial-peers to the provider network, and one dial-peer to our CUCM for incoming calls:
dial-peer voice 8 voip
description To_SIP_Provider
destination-pattern 000…..
session protocol sipv2
session target sip-server – our outgoing calls are done via SIP Proxy
codec g711ulaw
voice-class sip outbound-proxy dns:voice.telphin.com:5068 – as far as our CUBE is behind NAT, we need to use SIP outbound proxy. So set outbound proxy nameIP address and port here.
!
dial-peer voice 847 voip
description To_CUCM
destination-pattern 00044847
session protocol sipv2
session target ipv4:10.1.1.1
codec g711ulaw
In fact, here are all the necessary settings. Now, check the registration of the directory number 00044847 at the provider’s network by using show sip-ua register status command. Then make incoming and outgoing calls from / to ITSP network. If you face some problems with SIP signaling, use debug ccsip messages command on CUBE for troubleshooting.
Good luck and have a nice day! 🙂
Огромное спасибо. Очень толково и по делу.
Есть небольшой вопрос. А как в таком сценарии реализовать донабор внутреннего номера? Т.е. звонят по номеру – слышат тон – набирают внутренний – дозваниваются.
Добрый день,
Спасибо за отзыв 🙂 Донабор можно реализовать, например, с помощью tcl или vxml скрипта на шлюзе (в нашем случае CUBE). О vxml скрипте можно прочитать тут:
http://alakinalexandr.blogspot.com/2013/02/vxml.html#more
Если у вас имеется голосовая почта, или IP IVR, или CVP, то донабор номера можно реализовать и средствами данных приложений.
НО! Не забудьте про настройку механизмов передачи DTMF (в посте я об этом не писал)
Добрый день, Дмитрий!
Спасибо за полезную статью.
От себя хочу добавить, что CUCM 8.6 поддерживает отправку SIP INVITE с аутентификацией, таким образом можно делать исходящие звонки без отправки SIP REGISTER (во всяком случае, провайдер Задарма это поддерживает). Но входящие звонки принять уже не получится, хотя в большинстве случаев это и не нужно.
Добрый день, Денис!
Да, верно, CUCM умеет совершать исходящие звонки без предварительной регистрации, отправляя звонки с аутентификацией. Если провайдер это поддерживает и не нужны входящие звонки, то можно обойтись и без регистрации.
Однако, не все провы поддерживают звонки (даже исходящие) без регистрации. В этом случае CUBE, или девайс ему подобный, спасает. TelMe как раз не поддерживает 🙁
Добрый день! Спасибо большое за статью! Интересует вопрос больше идеологического взгляда – стоит ли разделять логику работы между CUCM и CUBE? Например, есть 6 офисов, в каждом по CUBE и своему VoIP-провайдеру. Все офисы соединены по VPN'у. В центральном офисе есть CUCM-кластер, в офисах SRST. И при этом мы всю логику по выбору шлюзов и по плану нумерации естественно держим на CUCM, но при этом трансляции номеров в номера VOIP-провайдеров держим на CUBE (в вашем примере все такие манипуляции происходят непосредственно на CUCM например)? Так же и со входящими звонками: Мы транслируем в какой-то номер все приходящие звонки непосредственно на CUBE, можно с IVR, можно просто сразу в hunt-группу, и отправляем на CUCM, где он сам разберется, что дальше делать… Является ли это хорошей практикой?
И ещё один вопрос, как в CUCM использовать трансляцию номера в зависимости от того, кто звонит? Например, когда звонят в город (допустим, набор через 9ку), то номера с 100-200 транслируются в городской 111-11-1, номера 201-300 – в 111-22-2, а 301 – в 111-33-3? Без манипуляции с called-номером?
Добрый день, Сергей!
Попробую ответить на Ваши вопросы. По первому вопросу – нет абсолютно никаких рекомендаций по поводу того, где выполнять трансляции номеров: на шлюзе или в ССМ. И та, и другая методика являются абсолютно приемлемой. Где удобнее и понятнее настраивать трансляции – там их и делают. Если шлюз MGCP, то тогда, конечно, трансляции выполняются только на ССМ, а в случае CUBE оба варианта одинаково хороши.
По второму вопросу – для модификации номера вызывающего абонента в зависимости от номера звонящего можно применить, например, External Phone Number Mask (параметр в блоке DN), или, что более прогрессивно, модификацию номера с помощью Transformation Pattern, которая применяется затем к шлюзу или транку (т.е прикрепляется к шлюзу или транку с помощью Calling Party Transformation CSS). Такая методика прекрасно работает и применяется в случаях подключения CUCM к разным провайдерам (как при Е1, так и при SIP).
К сожалению, эта методика более сложная, и о ней в 2х словах не рассказать. Может быть, если будет вдохновение, напишу об этом пост.
Здравствуйте!
А как же всё-таки быть если провайдер выдал несколько номеров и транслировать нужно их все?
Здравствуйте, Кирилл!
Уточните, пожалуйста, что Вы подразумеваете под трансляцией? Изменение Calling номера при исходящем звонке с ССМ в сторону прова или изменение Called номера при входящем звонке со стороны прова в ССМ?
Здравствуйте!
Интересует именно изменение calling номера на один из выданных провайдером при исходящих с ССМ.
Доброе утро,
Тут могут быть варианты, все зависит от вашего плана нумерации, выданного провайдером. Если последние цифры нумерации, выданной провайдером, совпадает с номерами внутренних абонентов, то все просто – в Route Pattern настраиваем Calling Party Transform Mask. Например, провайдер дает вам 100 номеров (00055500 – 00055599), а внутренние номера у вас 100 – 199. Тогда Calling Party Transform Mask нужно задать как 000555ХХ.
Если же более сложный случай, когда нет такого совпадения нумерации, нужно применять модификацию номера с помощью Transformation Pattern, которая применяется к транку (т.е прикрепляется к транку с помощью Calling Party Transformation CSS). К сожалению, кратко не получится рассказать, как она работает. Нужно писать отдельный пост с картинками и пояснениями.
Добрый день.
Спасибо за статью. Подскажите как будет выглядеть подключение к sip-провайдеру, в случае, когда у нас все-в-одном: на одном рутере и CME и CUBE?
Достаточно ли будет в простейшем случае настроить dial-peer на sip-провайдера для исходящих звонков и translation rule для входящих?
Добрый день, Евгений!
В этом случае CUBE нет, как такового (разве что у вас телефоны Cisco используют SIP сигнализацию). Да, действительно, в таком случае достаточно будет настроить диал-пиры и трансляции номеров для входящих и исходящих звонков.
Но!!! При подключении во внешний мир не забывайте о SIP-атаках (хакеры). Если вы не предпримете меры, то рискуете потерять деньги, за счет того, что хакеры прекрасно через ваш шлюз будут звонить в вашу городскую сеть (межгород, международные звонки). Так что будьте осторожны.
Вот тут можете немного почитать о таких атаках и методах защиты:
http://palavdin.blogspot.com/2012/10/achtung-ios-1512.html
Да, и еще хочу добавить – если подключаем СМЕ к прову, то не забываем про регистрацию SIP-UA у провайдера. Т.е настройки аутентификации, credentials нужно тоже будет сделать.
Ну и также не забудьте про НАТ…
Здравствуйте, Дмитрий! Огромное спасибо Вам за эти информативные статьи. Обращаюсь за помощью c Call Routing, имеется схема CCM 8.6 – cisco2921 – E1-ISDN. Внутренняя нумерация XXXX. С исходящими все понятно по Route Pattern'ам(пример города 6 знач.- 9.[^08]XXXXX) уходят на шлюз с добавлением Prefix(Outgoing Calls)- 834233.
Входящие приходят в формате E.164. Обрабатываются в Translation pattern'е – 33XXXX, добавляется Prefix 98 к caller ID и Called Party Transform Mask XXXX.
Все работает. Проблема такая – к входящему звонку добавляется 98 в итоге получается 988342XXXXXX, а вот перезвонить нельзя в город, нужен формат 9XXXXXX. Сотовые и межгород работают и перезваниваются при таком формате, а город нет. Изменял Calling Party Transform Mask как XXXXXX и Prefix 9 город стал перезваниваться, но и сотовые и межгород режутся до 9XXXXXX и понятно что нет перезвона. Как сделать проверку по caller ID чтобы: если звонок идет из города 8342XXXXXX то он резался до 9XXXXXX, а остальные звонки не затрагивались?
Добрый день, Евгений!
Я бы предложил Вам использовать на шлюзе настройки Incoming Calling Party Settings. Посмотрите, там можно подставить разные префиксы в зависимости от типа номера – Type of Number (TON), который обычно передается E1 ISDN и для Calling и для Called номеров.
Как известно, существуют 4 типа номера:
Unknown – обычно используется, когда номер передается в 3х или 4х значнм формате
Subscriber – городской абонент (5, 6 или 7 знаков)
National – междугородний абонент (код города + номер абонента)
International – международный абонент (код страны + код города + номер абонента).
Провайдер, соответственно, при входящем вызове должен вам присылать Calling номер с правильным типом. Т.е если звонок идет от городского абонента, то его тип номера должен быть Subscriber, если с межгорода – то National, если из другой страны – то International.
Ну а Вы уже в зависимости от типа номера подставляете нужный префикс – если TON=Subscriber, то подставляется 9, если TON=National – то 98, если TON=International – то 9810.
Все это, конечно, будет работать если провайдер у вас добросовестный, и все присылает "по-честному".
Здравствуйте Дмитрий!
На текущий момент момент в организации используется CME, все телефоны – программные. Сигнализация – SIP. Хотим подключить несколько SIP номеров от провайдера.
Если я правильно понимаю, то для того что бы наш ISR G2 выступил в роли голосового шлюза необходима покупка CUBE лицензии? Или можно обойтись без нее?
Спасибо!
Добрый день,
Теоретически да – лицензия на функционал CUBE нужна. Мне, к сожалению, не доводилось настраивать и тестировать CUBE на 29х/39х роутерах – только на 28х/38х. Я задал Ваш вопрос инженерам одного из интеграторов, они ответили, что покупка лицензий – это чистая формальность (на честность, так сказать), и что все функции CUBE будут работать и без лицензий (как в свое время работал СМЕ). Попробуйте настроить, если не получится, то лицензии всегда можно купить.
День добрый, Дмитрий
Спасибо за информативную статью.
У меня вопрос, поддерживает ли CUBE регистрацию по SIP у 2-х провайдеров? К примеру одно соединение основное, второе резервное. В моей случае в роли CUBE – Cisco 2901
Добрый день,
Благодарю Вас за отзыв :). Если я понимаю правильно, то с появлением 15го ИОС, возможна регистрация и у нескольких провайдеров (до 6ти). Посмотрите:
HQ-1(config)#sip-ua
HQ-1(config-sip-ua)#registrar ?
<1-6> Registrar Index Value for configuring multiple registrars
WORD Registrar Server address
dhcp Registrar Server address provision via DHCP
Поэтому, думаю, что без проблем сможете зарегиться у 2х провов.
Добрый день, простите что вклиниваюсь..
А как на диалпирах указывать на разных провайдеров?
Есть какая то вариация команды session target sip-server ?
Добрый день,
Думаю, что с этим не будет никаких проблем:
session-target dns:sip.telphin.com:5068
Аналогичным образом делаем для других провайдеров.
Не совсем понятно какой registrar будет использоваться с командой:
session-target dns:sip.telphin.com:5068
И соответственно какие будут использованы юзер и пароль
Имеется в виду, как в диалпире указать что использовать скажем registrar 1 а не 2
Добрый день,
Прежде всего, хочу извиниться за задержку с ответом – к сожалению, не всегда есть время сразу отвечать из-за проводимых курсов и поездок.
По существу Вашего вопроса: будет использован registrar (а точнее, SIP-сервер), указанный в команде session-target (в моем предыдущем ответе это sip.telphin.com). Registrar – это всего-лишь один из компонентов SIP-сервера (таких компонентов всего 4 – registrar, proxy, location, redirect), и отвечает он только за регистрацию терминалов.
Команда session-target выполняется на диалпире, таким образом мы и указываем, что при наборе определенного номера (destination pattern), сигнализация SIP должна отправляться на сервер sip.telphin.com. В другом диалпире для других набираемых цифр Вы можете указать другой SIP-сервер, например, session-target dns:intervoip.com.
"И соответственно какие будут использованы юзер и пароль" – для звонка через sip.telphin.com, будут использованы пароль/логин из команды authentication c соответствующим realm = sip.telphin.com. Вот пример из моей статьи:
authentication username 00044847 password ciscolab realm sip.telphin.com
Для звонка через другой SIP-сервер нужно прописать вторую команду аутентификации с другим realm (пример для сервера intervoip.com):
authentication username 12345678 password student realm intervoip.com
Дмитрий, подскажите пожалуйста, возможно ли на каком-нибудь цисковом железе/ПО организовать конвертор сигнализации SIP/H.323 trunk <-> MGCP (в качестве Call Agent выступает Huawei SoftX)? Вроде бы в Cisco IOS Software Version 15.1(4)M2 на 7301 есть все необходимое, однако я никак не могу найти подходящей документации с примерами, которая помогла бы мне это настроить.
Добрый день, Евгений!
К сожалению, мне такого рода задачи (конвертировать SIP/H323 в MGCP не приходилось решать). Однако, скажу свое мнение – думаю, что это невозможно на циске. Поясню свою мысль – циско-шлюз регистрирует на Call Agent'е (CUCM) аналоговые или цифровые физические порты (FXO, E1, FXS). Для этой цели используется даже система обозначения и имен физических портов, которые содержат в себе номер слота, номер модуля и номер порта. А какие имена будут иметь транки H323/SIP, ведь физических портов ведь нет???
Вы пишете про 7301, а подскажите, пожалуйста, что навело Вас на такую мысль (возможно, какая-то статья или форум)?
Конвертация MGCP в E1 вполне гуглится, например:
http://yate.null.ro/pmwiki/index.php?n=SS7.ConfigCiscoMGCP
http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a00801ad22f.shtml
Ну а дальше сработала логическая цепочка: E1 -> SIGTRAN -> SIP Trunk 🙂
И началось все именно с первой статьи, а дальше возникла мысль избавиться от какой-нибудь железки. Реализация MGCP Media Gatewy (в отличие от Call Agent) в yate не документирована и скорее только делает вид, что работает. Поэтому начал смотреть в сторону циски.
В Cisco IOS Software Version 15.1(4)M2 на 7301 есть команды mgcp, однако ничего связанного с ccm там уже нет. Т.е. в лучшем случае я смогу конвертировать MGCP в E1?
Так с Е1 и вопросов нет 🙂 – MGCP прекрасно для управления шлюзом с портами Е1 подходит. 28я, 29я, 38я, 39я да и другие серии шлюзов Cisco абсолютно хорошо работают с MGCP.
Скажите, а сделать SIP Trunk из SIP c регистрацией на том же Cisco IOS Software Version 15.1(4)M2 на 7301 – это менее противоестественное желание? Что посоветуете почитать по этому поводу?
Думаю, что SIP-транк – это более естественное желание. Почитать – да, собственно, любую литературу по настройке голосовых шлюзов циско. Погуглите книжки из серии Cisco Press по курсу CVOICE (Cisco Voice over IP).
Да и в моей статье, в которой Вы сейчас комменты пишете, фактически приведен пример SIP-транка на шлюзе циско.
Добрый вечер,
Вопрос действительно очень масштабный и в двух словах его не описать, конечно же. Я бы посоветовал Вам почитать литературу или посмотреть видео по курсу CVOICE (например, те же CBT Nuggets). А еще лучше – пройти авторизованный тренинг циско, если есть возможность. (я, кстати, буду вести такой курс скоро в учебном центре Микротест в Москве 10.06.2013, могу Вам также предложить поучиться дистанционно, он-лайн ,если есть желание).
Если говорить о плане действий, то по минимуму нужно сделать следующее:
– настроить диал-пиры для входящего и исходящего звонков;
– настроить список доверенных внешних сторонних устройств, которым будут разрешены входящие звонки на ваш шлюз (если IOS версии 15 и новее);
– настроить правила преобразования Calling и Called номеров для ваших SIP-звонков.
Здравствуйте. Хотел бы попросить помощи в следующей ситуации: имеется Cisco 500 series UC-520-16, несколько цискофонов (7906 и 7940). Со внутренними телефонами я разобрался, но теперь стоит задача выпустить телефоны в ГТС.
Выход в гтс выполнен в виде SIP-транка, похоже, не требующего авторизации (пользователь-пароль не даны, даны только адреса для оборудования, городской номер, и адрес сип-прокси). Как правильно подключить этот сип-транк на циске и как научить телефоны звонить наружу и принимать оттуда звонки? Попробовал на одном из портов настроить данный адрес, при звонке извне в дебаге, вроде как, виден входящий вызов.
Прошу прощения за масштабный вопрос, но ни с телефонией, ни с оборудованием cisco до этого случая не сталкивался. Хотелось бы получить хотя бы примерный порядок действий.
Заранее спасибо.
Спасибо за ответ. Тренинг – это замечательно, но сроки не располагают. Нужно закончить эту работу буквально на днях.
Почитав в интернете, поспрашивав на форуме, разобрался во всем:)
Последней проблемой было то, что я забыл указать в исходящем диал-пире использование сип-протокола.
Но на насчет курсов я уже задумался.
Здорово, что разобрались, не так это и сложно, на самом деле. Но курсы все же посетить стоит, если планируете поддерживать голосовые решения (у меня или у другого тренера, не суть важно). Главное понять и разобраться досконально, как это работает.
Буду рад, если придете на курсы ко мне в Микротест (если Вы из России), или к моим воспитанникам – инструкторам Cisco Центра Знаний (если Вы из Украины).
Здравствуйте, Дмитрий! Подскажите решение: имеется телефон cisco 9971, на консолях у которого занесены на Speed_Dial городские, сотовые, междугородние номера телефонов. Как этому списку из SD разрешить звонки на этот телефон 9971, а все остальные пересылать на другой номер (DN)? Или вообще остальные блокировать желательно средствами CUCM.
Добрый день, Евгений!
Я не совсем понял задачу Вашу. Правильно ли я понимаю, что на номер телефона 9971 должны приходить ВХОДЯЩИЕ звонки только с номеров кнопок SD? Звонки со всех других вызывающих номеров должны блокироваться или отправляться на другой DN? Так?
Т.е должна быть фильтрация звонков по номеру вызывающего абонента?
Да, пропускать входящие звонки из SD, а остальное пересылать на другой номер или вообще блокировать. И если можно хотя бы в двух словах рассказать как происходит фильтрация входящего трафика на CUCM (проверка по caller ID например), можно ли создать COR-лист или это все организуется в Translation Pattern?
Доброе утро, Евгений!
В двух словах это, увы, не рассказать. Собираюсь написать в ближайшее время об этом пост в блоге. Может быть, к концу недели статья будет. Пока что могу привести Вам ссылки, где об этом можно почитать:
http://palavdin.blogspot.sk/2012/10/ani.html
https://supportforums.cisco.com/docs/DOC-18367
Спасибо Вам за ссылки. Также отдельное спасибо за ваш труд, эти посты и ответы на наши вопросы очень помогают осознать и понять все тонкости настройки CUCM. Будем ждать новых статей в вашем блоге!
Добрый день, Дмитрий!
Спасибо за статьи!
Когда планируете затронуть тему Transformation Pattern?
Заранее благодарен,
Денис.
Здравствуйте, Денис!
Статья по Transformation Pattern выйдет в ближайшее время (через неделя,может через две). В настоящий период у меня очень большая загрузка, посему пишу в блоге меньше.
Здравствуйте, Дмитрий!
Хотел с Вами посоветоваться, правильно ли я собираюсь сделать или нет.
При подключении по SIP CUBE к провайдеру последний хочет, чтобы вместо ip-адреса клиента в заголовках присутствовал ip-адрес его (провайдерской) АТС.
Допустим, адрес клиета 1.1.1.1, провайдера – 2.2.2.2.
Поможет ли в этой ситуации включение на dial-peer voice в сторону провайдера voice-class sip profiles такого содержания:
voice class sip-profiles 1
request ANY sip-header From modify "" ""
request ANY sip-header Contact modify "" ""
Здравствуйте,
Да, что именно использование подобных voice class sip-profiles поможет в данной проблеме.
Здравствуйте Димитрий!
Хочу задать вопрос по дизайну решения с CUBE. Так, например, у маршрутизатора CISCO 881 есть WAN порт и LAN порт (-ы). CUBE сможет реализовать подключение к провайдеру только с WAN порта или сможет подключиться и с LAN порта? Вопрос в возможности работы на одном порту (LAN или WAN).
Спасибо!
Добрый день,
Все зависит от того, какой тип подключения предоставляет провайдер. Если от прова приходит Ethernet, то можно и по LAN подключиться.
CUBE – это возможность соединить между собой два VOIP звонка (VOIP Call Leg). Будет ли это работать с одним портом – можно сказать только, если глянуть на схему вашей топологии, чтобы понять как построена маршрутизация.
Здравствуйте Дмитрий!
Например, такой случай. CUCM – 192.168.0.2, CUBE LAN port – 192.168.0.3 (маршрут по умолчанию – 192.168.0.1), шлюз в сети – 192.168.0.1. То есть CUCM подключается к CUME, а он в свою очередь подключается к SIP провайдеру выходя через шлюз по умолчанию. Таким образом все реализуется на одном порту.
Спасибо!
Доброе утро,
Думаю, что такая схема вполне будет работать. Однако, учитывайте, что могут быть проблемы, связанные с NAT (односторонняя слышимость, отсутствие разговора вообще).
Дмитрий, а Type of Number (TON) передается по SIP ?
Доброе утро,
Нет, к сожалению, TON по SIP не передается. Описанный выше пример будет работать для шлюзов H323 и MGCP.
Спасибо, Дмитрий. Получается, что для входящих по SIP логика обработки для добавления кода выхода должна основываться на длине входящего номера?
Да, именно так, другое что-то в таком случае вряд-ли можно придумать.
Здравствуйте Дмитрий!
Прежде всего хочу поблагодарить вас за ваш труд, он бесценен!
Теперь к делу, настроен SIP Trunk, исходящие звонки проходят удачно, а вот со входящим проблема, короткие гудки, и в дебагах ошибки 1. SIP/2.0 407 Proxy Authentication Required 2. SIP/2.0 503 Service Unavailable, не подскажите в чем может быть проблема?
Добрый вечер,
Спасибо за Ваш отзыв. Чтобы ответить на Ваш вопрос, нужны дополнительные данные. Для начала объясните, пожалуйста, свою топологию (подключены с CUBE/без CUBE, на каком устройстве снимаете дебаг).
В ближайшие 2 недели я смогу Вам отвечать и помогать только по вечерам. Так что заранее приношу извинения за задержки с ответами.
Добрый день Дмитрий,
Имеется тестовая площадка CUCM 8.6, роутер 2911 и SIP Trunk с 10-ю номерами.
Звонки из CUCM в наружу удачно проходят, однако извне в CUCM не проходят, при дебаге на роутере выдает следующее:
1. SIP/2.0 407 Proxy Authentication Required – хотя авторизации практические нету, открытый транк.
2. SIP/2.0 503 Service Unavailable -грешу на провайдер а доказательств нету.
Translation Pattern вроде настроен правильно. Но до него дело не доходит. При звонке из вне выкидывает что такого номера не существует.
В чем может быть причина, подскажите пожалуйста?
P.S. Не дождавшись ответа был запостен еще один пост по теме, прошу удалить его что бы не дублировать посты:)
Добрый день, Вусал!
Проверьте, не включен ли у вас на роутере sip registrar (voice service voip -> sip -> registrar). Если включен, то это может быть причиной того, что запрашивается аутентификация.
Для точной диагностики мне нужна конфигурация маршрутизатора, и снятый с него дебаг debug ccsip messages при входящем звонке. Напишите, пожалуйста, комент с адресом Вашей почты. Вечером я перешлю Вам свой адрес почты, и потом вышлете мне на него конфиг и дебаг.
Хорошего дня!
день добрый, Дмитрий
Очень надеюсь на Вашу консультацию.
в связке ССМ -(h.323) -2821 -(SIP) – IPS
на циске описаны используемые кодеки
Код:
voice class codec 2
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729br8
codec preference 4 g729r8
соответственно пир
Код:
dial-peer voice 1080 voip
description ==Calls to area via Telphin==
translation-profile outgoing Telphin-out
destination-pattern 088.T
voice-class codec 2
session protocol sipv2
session target dns:sipserver
session transport udp
dtmf-relay rtp-nte
clid network-number 000XXX
при звонках на определенное направление, оператор использует шлюз понимающий только PCMA (711alaw), но циска почему то шлет только PCMU (ulaw), хотя пиру прописан voice-class codec 2
Код:
v=0
o=CiscoSystemsSIP-GW-UserAgent 4730 9848 IN IP4 78.107.43.188
s=SIP Call
c=IN IP4 78.107.43.188
t=0 0
m=audio 17062 RTP/AVP 0 121 101 19
c=IN IP4 78.107.43.188
[b]a=rtpmap:0 PCMU/8000[/b]
a=rtpmap:121 frf-dialed-digit/8000
a=fmtp:121 0-15
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
мне прилетает 488 Not Acceptable Here. Почему могут не использоваться кодеки из класса 2 ?
Доброе утро,
Думаю, что такое поведение CUBE связано с тем, что сам ССМ при звонке через CUBE (по h323) запрашивает кодек G711u. ССМ так делает по умолчанию, и до релиза 9.0 никаких настроек в нем для выбора кодека G711a вместо G711u предусмотрено не было.
Вы, наверное, знаете, что политика выбора кодека на ССМ устанавливается с помощью Region. Однако, там выставляется лишь максимальная полоса для одного звонка, но не сам тип кодека, и если указывать полосу в 64к, то ССМ выбирает G711u. В релизе 9.0 это было исправлено, и можно указать еще и G711a.
Что можно сделать, если у вас не 9й релиз? Конверсия G711u в G711a обеспечивается c помощью МТР (Media Termination Point). Т.е. Вам нужно на своем ССМ настроить МТР и разрешить их использование для Н323 шлюза/транка (все это делается в ССМ, галочка MTP required).
Можно также попробовать на CUBE применить voice-class codec без кодека G711u для диал-пира, который используется как incoming при звонке в SIP сеть.
утро доброе, спасибо за ответ.
Дело в том, что на CUCM настроен MTP и на шлюзе он указан, так же на шлюзе указаны inbound и outbound faststart (g711ulaw, как раз из за этого и использовался именно pcmu). После указания 711alaw звонки пошли, но есть подозрение что попадись при вызове шлюз без поддержки alaw, звонок не пройдет. Посему вопрос, за что отвечает faststart ? насколько я понимаю, это команда заменяет sip early media в cisco ios. При этом, если снять галки faststart, но звонки часть звонков перестает ходить, а часть не передает RTP.
Доброе утро,
Faststart – это один из режимов работы сигнализации H323, при котором согласование кодеков происходит ДО момента ответа вызываемого абонента. Если Вы снимите галки inbound и outbound faststart, то тогда CUCM будет работать только в режиме slow start (т.е согласование кодеков ПОСЛЕ ответа вызываемого абонента).
Проблемы со звонками в случае отсутствия этих галочек могут возникнуть. Дело в том, что участок с сигнализацией SIP у Вас работает в режиме Early Offer (т.е опять же выбор кодека происходит ДО ответа). CUBE не поддерживает соединение участков H323 Slow Start – SIP Early Offer равно как и H323 Fast Start – SIP Delayed Offer.
Поэтому правильно настраивать так, чтобы с одной стороны CUBE был H323 Fast Start, а с другой – SIP Early Offer.
Early Media – это режим, при котором не только производится выбор кодека ДО ответа вызываемой стороны, но еще и начинается передача голоса ДО сигнала ответа. Он применяется как в Н323, так и в SIP.
Здравствуйте ,Дмитрий!Сможете подсказать , по Corporate directory почему телефоны 6941, 7941-7961 отображают только 31 элемент по поиску без условий , например по фамилии выводит найдено 31 из 535 , при нажатии далее , возможен только новый поиск сначала и снова список из первых 31 фамилии .Проверено на 2 разных кластерах CUCM 8.6 22900
Хотелось бы что бы они выводили весь список сразу , либо при нажатии кнопки далее хотябы следующие по списку фамилии и так до конца
Добрый день,
К сожалению, не подскажу ничего с ходу по данной проблеме – еще с таким не сталкивался. Вполне возможно (это предположение), что за количество выводимых контактов на дисплей отвечает какой-то из сервисных параметров (Service Parameters) в настройках ССМ. Посмотрите, пожалуйста, сервисные параметры, может что-то удастся найти.
Дмитрий,добрый день.
Спасибо за Ваш блог.
У нас такая топология: CUCM 8.6.2-SIP-CUBE 2951-SIP-провайдер. В последнее время возникла необходимость расширить диапазон городских номеров, но наш провайдер этого обеспечить не может. Т.е. возникла необходимость подключиться к ещё одному провайдеру. Понятна схема с покупкой ещё одного CUBE 2921 и настроикой CUCM со звонками части абонетнов через одного провайдера, части через другого. Но денег жалко, не подскажите есть ли типовые решения для подключения двух SIP провайдеров к одному CUBE и как в этом случае заставить часть телефонов на CUCM звонить через одного определенного провайдера а части телефонов через другого?
Доброе утро,
Спасибо за Ваш отзыв. Я думаю, что нет необходимости покупать второй CUBE, все можно сделать и на одном, если, конечно, нет проблемы с IP-маршрутизацией и адресацией. CUBE может работать одновременно с шестью провайдерами.
Для того, чтобы одни абоненты выходили через одного провайдера, а другие – через другого, необходимо сделать на CUCM 2 разных Rout Pattern и 2 разных сип-транка. Одна группа абонентов звонит через один роутпаттерн, вторая – через второй. Доступ у роутпаттернам ограничиваем с помощью CSS и Partition. Или же, вместо всего этого можно использовать Local Route Group.
На CUBE нужно будет сконфигурировать 2 разных диал-пира – один в сторону одного провайдера, второй – в сторону другого.
Я, конечно, описал все это в общих чертах. Чтобы описать более детально, нужно знать точнее ваши исходные данные. Система достаточно гибкая, и такие вещи, безусловно, позволяет реализовать.
Ну да я забыл упомянуть главную проблему. Провайдеры равнозначные и получается что диал пиры должны быть одинаковые как в сторону одного провайдера так и в стороны другого. Т.е. на CUCM все настраиваем как Вы описали, в итоге вызов попадают на шлюз и оба провайдера могут этот вызов обработать теоретически, но вызов от определенного Calling номера должен уйти через определенного провайдера. Т.е. необходимо некую фильтрацию на шлюзе по Calling номерам осуществлять в сторону провайдера или как-то задать жесткое соответствие что из SIP ТРАНКА 1 от CUCM вызовы уходят только на SIP транк к ПРОВАЙДЕРУ 1, а из SIP транка 2 от CUCM – на SIP транк к ПРОВАЙДЕРУ 2. Напрашивается вариант с введением кода выбора провайдера при наборе городского номера, но тогда прийдется объяснять людям что у одних код такой у других такой в итоге будет неразбериха.
Можно предложить такой вариант – подставить код провайдера в СUCM (путем модификации Called-номера любым известным Вам способом: в роутпаттерн, в роутгруппе, в настройках шлюза или даже с помощью Translation Pattern).
Т.е. пользователь как набирал, так и набирает себе номер, CUCM подставляет нужный код прова, далее на шлюзе делаем 2 разных диалпира, и при отправке вызова к прову код прова удаляем с помощью voice translation-profile.
Другой вариант – это использование COR-листов на шлюзе. Однако, тут нужно точно знать, какой входящий диалпир выбирается на шлюзе при звонке с того или иного абонента (по критерию, например, answer-address). Такая конфигурация более сложна и требует четкого понимания выбора входящих диал-пиров.
Спасибо за совет. Попробуем реализовать первый вариант.
Здравствуйте Дмитрий!
Скажите пожалуйста, если мы берем с провайдера по SIP-Trunk-у 10 номеров, как можно реализовать отдельные номера для каждого пользователя? Что бы каждый пользователь использовал свой номер при выходе в город и наоборот!?
Доброе утро, Вусал!
Такая штука реализуется с помощью модификаций вызывающего (Calling) и вызываемого (Called) номеров. Модификации номеров можно делать как в CUCM, так и на шлюзе в зависимости от того, где удобнее.
Сценарии могут быть разные, но обычно делают вот что:
1. Для исходящего звонка (в город) изменяют короткий внутренний Calling-номер на нужный длинный из плана провайдера. Также из номера Called удаляют код доступа к данному провайдеру (например, 9ка), если он набирался при звонке.
2. Для входящего звонка (из города) изменяют длинный Called-номер из плана провайдера на короткий соответствующий номер внутреннего абонента. При желании можно также подставить в Calling-номер код выхода к данному провайдеру (это необязательно, а нужно лишь для удобства, чтобы внутренний абонент мог перезвонить автоматически на номер пропущенного входящего вызова).
Описать в 2х словах все возможные варианты настроек невозможно, на это нужны отдельные посты, а в курсах циско в учебниках этому посвящены целые главы. Методы модификации номеров на шлюзах рассматриваются в курсе CVOICE, а методы изменения цифр на CUCM – в курсе CIPT1.
Доброго времени. Спасибо за статью.
Есть вопрос. Связка у меня такая: CUCM 6 – h323 – 2811 – sip – provider
настройка исходящего диалпира на 2811:
dial-peer voice 60002 voip
translation-profile outgoing 160002
destination-pattern 229T
session protocol sipv2
session target ipv4:192.168.130.1:5079
codec g711alaw
no vad
дебаг:
.Aug 29 05:03:42.886: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:27205@192.168.130.1:5079 SIP/2.0
Via: SIP/2.0/UDP 192.168.130.141:5060;branch=z9hG4bK16E9246F
From: ;tag=491892C-6D0
To:
Date: Thu, 29 Aug 2013 05:03:42 GMT
Call-ID: 35D82DFC-F9F11E3-8135DC75-B4C7F03E@192.168.130.141
Supported: 100rel,timer,replaces
Min-SE: 1800
Cisco-Guid: 2152760158-785834273-167805185-167800629
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO
gwvoice#, UPDATE, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Timestamp: 1377752622
Contact:
Expires: 180
Allow-Events: telephone-event
.Aug 29 05:03:42.906: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.130.141:5060;branch=z9hG4bK16E9246F;received=192.168.130.141
From: ;tag=491892C-6D0
To:
Call-ID: 35D82DFC-F9F11E3-8135DC75-B4C7F03E@192.168.130.141
CSeq: 101 INVITE
Content-Length: 0
gwvoice#
.Aug 29 05:03:44.430: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 415 No Media
Via: SIP/2.0/UDP 192.168.130.141:5060;branch=z9hG4bK16E9246F;received=192.168.130.141
From: ;tag=491892C-6D0
To: ;tag=y61nnujcn1
Call-ID: 35D82DFC-F9F11E3-8135DC75-B4C7F03E@192.168.130.141
CSeq: 101 INVITE
Contact:
Accept: application/sdp, application/dtmf, application/dtmf-relay
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, UPDATE, REGISTER
Supported: timer
Server: M-200 Motor 5.86.63 (MPB)
Content-Length: 0
gwvoice#
.Aug 29 05:03:44.438: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:27205@192.168.130.1:5079 SIP/2.0
Via: SIP/2.0/UDP 192.168.130.141:5060;branch=z9hG4bK16E9246F
From: ;tag=491892C-6D0
To: ;tag=y61nnujcn1
Date: Thu, 29 Aug 2013 05:03:42 GMT
Call-ID: 35D82DFC-F9F11E3-8135DC75-B4C7F03E@192.168.130.141
Max-Forwards: 70
CSeq: 101 ACK
Content-Length: 0
.Aug 29 04:58:44.629: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:27205@192.168.130.1:5079 SIP/2.0
Via: SIP/2.0/UDP 192.168.130.141:5060;branch=z9hG4bK16D517FF
From: ;tag=48CF634-BA4
To: ;tag=12xma6gnvs
Date: Thu, 29 Aug 2013 04:58:43 GMT
Call-ID: 832A6B65-F9E11E3-8134DC75-B4C7F03E@192.168.130.141
Max-Forwards: 70
CSeq: 101 ACK
Content-Length: 0
симптомы такие: набираю номер, на вызываемом телефоне идет вызов и тут же обрывается.
Куда копать?
Спасибо заранее.
Добрый день,
Первый вопрос, который я Вам задам – это новое подключение или оно уже ранее работало?
Ответ SIP 415 No Media связан, скорее всего с тем, что сторона провайдера не видит информации о кодеках в запросе INVITE с вашей стороны. Очевидно, что провайдер ожидает от вас режим работы SIP Early Offer (в INVITE должна отправляться информация о поддерживаемой вашей стороной кодеках – так называемое SDP). Обычно эта информация имеет вот такой вид (это пример, айпишники, естественно, не совпадают с вашими):
v=0
o=asmith 13015556789 IN IP4 cisco.com
s=Example2
t=0 0
c=IN IP4 10.234.1.1
m=audio 3456 RTP/AVP 18 0 8 (данная строчка говорит о том, что поддерживаются кодеки G729 (18), G711u (0) и G711a (8))
В вашем же INVITE такой информации нет. Стало быть, ваша циска работает по SIP не в режиме Early Offer, а в режиме Delayed Offer. Пров не получает инфу о кодеке и рвет соединение с ошибкой 415.
Предполагаю, что циска 2811, в свою очередь, может слать сообщения SIP в режиме Delayed Offer потому, что получает от CUCM сообщение H323 в режиме Slow Start, а надо бы в режиме Fast Start. Для Fast Start на CUCM в настройках шлюза или транка H323 есть соответствующие галочки. Надо проверить, включены ли они.
вот что происходит когда звонят из города:
.Aug 29 05:49:14.490: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:60002@192.168.130.141;transport=UDP;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.130.1:5079;rport;branch=z9hG4bKgnd7iy5kwtu8szypwj98
From: "Anonimous" ;tag=hic48q50x6
To:
Call-ID: wb9t1zj8usud92n8a0dw@192.168.130.1
CSeq: 15215 INVITE
Contact:
Max-Forwards: 70
User-Agent: M-200 Motor 5.86.63 (MPB)
Accept: application/sdp, application/dtmf, application/dtmf-relay
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, UPDATE, REGISTER
Supported: timer
Content-Type: application/sdp
Content-Length: 234
v=0
o=60002 2593520479 2593520479 IN IP4 192.168.130.1
s=m-200
c=IN IP4 192.168.130.1
t=0 0
m=audio 8010 RTP/AVP 8 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
.Aug 29 05:49:14.506: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.130.1:5079;rport;branch=z9hG4bKgnd7iy5kwtu8szypwj98
From: "Anonimous" ;tag=hic48q50x6
To: ;tag=4BB3754-B11
Date: Thu, 29 Aug 2013 05:49:14 GMT
Call-ID: wb9t1zj8usud92n8a0dw@192.168.130.1
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 15215 INVITE
Allow-Events: telephone-event
Content-Length: 0
.Aug 29 05:49:14.510: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 501 Not Implemented
Via: SIP/2.0/UDP 192.168.130.1:5079;rport;branch=z9hG4bKgnd7iy5kwtu8szypwj98
From: "Anonimous" ;tag=hic48q50x6
To: ;tag=4BB3754-B11
Date: Thu, 29 Aug 2013 05:49:14 GMT
Call-ID: wb9t1zj8usud92n8a0dw@192.168.130.1
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 15215 INVITE
Allow-Events: telephone-event
Content-Length: 0
gwvoice#
.Aug 29 05:49:14.534: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:60002@192.168.130.141;transport=UDP;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.130.1:5079;rport;branch=z9hG4bKgnd7iy5kwtu8szypwj98
From: "Anonimous" ;tag=hic48q50x6
To: ;tag=4BB3754-B11
Call-ID: wb9t1zj8usud92n8a0dw@192.168.130.1
CSeq: 15215 ACK
Contact:
Max-Forwards: 70
Content-Length: 0
и звонок так же отваливатеся, сразу занято…
Enable Outbound FastStart выключено.
Включил: http://gyazo.com/6d3fc2d8a40a049736e3fb05e81ad602
Все тоже самое, дебаг не изменился.
На входящем другая ошибка – 501.
Хотелось бы взглянуть на конфиг 2811. Напишите в комменте адрес почты, я отвечу Вам в почте. В настоящее время веду курс CVOICE в Москве, через 10 мин начинаем, посему смогу отвечать в перерывах или когда будет свободное время.
Жду от Вас коммент с адресом мыла.
Дмитрий, добрый день.
Спасибо за полезный материал.. Хочу задать вопрос по поводу TLS.
Провайдер предоставил сертификат своего СА, мой сертификат юзер-агента c зашифрованным приватным ключем. Все это добро в виде .рем файлов.
– Описан trustpoint
crypto pki trustpoint SIPTP
revocation-check none
rsakeypair SIPTP-IMPORT-RSA-KEY
– Сертификат СА – импртировался успешно через CLI
– командой cry key imp rsa SIPTP-IMPORT-RSA-KEY term
пытаюсь вставить свой сертификат и приватный ключ в результате получаю сообщение
—–END RSA PRIVATE KEY—–
quit
% Key pair import failed.
Отладка cry pki возвращает
CRYPTO_PKI: Can not select my full public key (SIPTP-IMPORT-RSA-KEY)
по этой ошибке ничего полезного прогуглить не удалось.
Помогите пожалуйста…
Добрый день,
Спасибо за Ваш отзыв. По Вашему вопросу – к сожалению, не смогу помочь. У меня нет опыта по внедрению TLS. Некоторые знания по безопасным кластерам, конечно же, имеются, но не настолько глубокие. Однако, на практике внедрять TLS не приходилось – крайне редко, пока еще, в проектах внедряется криптование голоса.
Можно тоже вопрос? Только по CUCME а не CUCM
телефония на 2901, телефоны cisco/linksys 502, которые для работы в режиме SCCP требуют полноценного CUCM, поэтому подключать телефоны пришлось как SIP:
==
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
sip
bind control source-interface Vlan640
bind media source-interface Vlan640
registrar server expires max 3600 min 1200
!
voice register global
mode cme
source-address 10.108.196.33 port 5060
max-dn 50
max-pool 36
authenticate register
timezone 32
time-format 24
date-format D/M/Y
user-locale RU
ntp-server 10.108.196.33 mode unicast
!
voice register dn 1
number 100
!
voice register dn 2
number 102
!
voice register pool 1
id mac A44C.119F.137A
number 1 dn 1
username 100 password pass
codec g711ulaw
!
voice register pool 2
id mac A44C.119F.11F0
number 1 dn 2
username 102 password pass
codec g711alaw
!
controller E1 0/1/0
framing NO-CRC4
ds0-group 0 timeslots 1 type r2-digital dtmf dnis
!
voice-port 0/1/0:0
connection plar 100
!
dial-peer voice 133 pots
destination-pattern 133
direct-inward-dial
port 0/1/0:0
forward-digits 0
!
====
При этом телефоны отлично звонят на внешнюю линию е1, но друг на друга отказываются – сразу отбой.
Но с большим удовольствием звонят сами на себя – поднимаем трубку, набираем собственный номер, и сам же и звонит.
И ещё: почему-то выдаёт вот так
#sh sip-ua register status
Registrar is not configured
Добрый день, Сергей!
Причину неуспешного звонка по SIP покажет, конечно же, дебаг (debug ccsip messages).
Однако, судя по вашей конфигурации, причиной неуспешного звонка МЕЖДУ телефонами могут быть неправильные установки кодеков. Посмотрите: для одного телефона Вы установили кодек G711a, а для другого – G711мю. Циска воспринимает их как разные кодеки, и, соответственно, звонок не возможен.
Установите одинаковые кодеки для обоих телефонов и попробуйте позвонить. Если не заработает, то включайте указанный дебаг, снова звоните, и присылайте результат дебага.
Добрый день, такой вопрос,
А что надо купить(лицензии,платы)
чтобы 2911 использовать в качестве cuba? для sip провайдера
Добрый день,
Нужно купить лицензии для 2911, поддерживающие войсовый функционал (иначе без лицензии, как Вы знаете, в IOS не будет войсовых команд). Платы покупать не надо.
Спасибо, с локальными звонками разобрался – действительно, кодеки. Включая ещё присоединение другой подобной циски – там оказывается надо было кодеки указывать в каждом dial-peer типа voip.
Теперь другая проблема: виснет порт е1, описанный в приведённом выше конфиге.
(dial-peer 133)
Задумка присоединяющей организации – связь по этой линии без набора номера, то есть чисто по занятию линии.
Оно работает, может и 10 и 20 раз позвонить в обе стороны, но в один момент раз – и на порту зависает состояние "clearbak", которое не сбрасывается ничем, кроме перезагрузки роутера.
Вот так сообщает sh voice port sum:
IN OUT
PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC
=============== == ============ ===== ==== ======== ======== ==
0/1/0:0 01 r2-digital up up clearbak idle y
И всё, больше ни одного вызова сделать на эту линию не удаётся до перезагрузки роутера.
Как уже писал выше, не помогает ни перезапуск контроллера Е1, ни перезапуск voice-port, ни "clear call voice causecode 103 id XXX".
Команда #sh call active voice показывает
Telephony call-legs: 1
То есть зависает call-leg со стороны voice-port на Е1.
Освободить порт удаётся только перезагрузкой роутера.
Это само собой не дело.
Как побороть эту ситуацию?
Можно ли как-то отбить зависший по непонятной причине voice-port из предыдущего примера? видимо из-за сбоя сигнализации R2-dtmf. Висит в состоянии "clearbak" и ничем кроме перезагрузки роутера не сбрасывается.
Странная ситуация, что не можете отбить зависший канал ничем, кроме как перезагрузкой. По идее, сброс voice port 0/1/0:0 (т.е. sh / no sh) должен помочь.
Возможно, это просто баг IOS.
Я тоже думал, что shu/no shu на voice-port должно отбить. Ничего подобного. Десятидневный диалог с индусом из техсуппорта Cisco привёл к его резюме:
==
There is no other option, this is a network problem and needs to be
taken care of on the network or the R2 switch side.
==
И никаких способов отбить эту линию, кроме перезагрузки, так и не посоветовал.
При этом раз перезагрузка линию всё же отбивает – значит, дело в нашей стороне, а не в АТС!
Кстати гуглением нашлось пяток аналогичных случаев ещё со времён IOS 12.0 (у меня 15.0(1r)M16), все без решения, так что баг древний.
Доброе утро, Сергей!
Я с Вами абсолютно согласен. Это проблема Cisco, а не АТС, так как помогает перезагрузка шлюза, а не АТС! Увы, от саппорта можно частенько услышать подобные ответы. 🙁
Работая ранее инженером по инсталляции АТС и сталкиваясь с нашими телекомами, мне подобный ответ (типа "проблема на вашей стороне) приходилось, увы, слышать неоднократно. Вооружался дебагами, трейсами, и доказывал им, что проблема все же у них. Иногда спасал звонок их начальству (если знал, кому звонить).
Да, но увы – делать-то что-то надо. Сменить сигнализацию на АТС – не вариант, там на одной плате ещё десятки абонентов и сигнализация настраивается на всю плату целиком. И никто, кроме нашего подключения, проблем не знает, что интересно.
И даже никаких таймаутов на отбой – так бы прописал безусловный таймаут на освобождение порта минут 10 и хоть как-то проблему закрыл бы 🙁
cas-custom тоже предлагает для этого типа сигнализации фактически один регулируемый параметр – длительность паузы между dtmf посылками.
Дмитрий, большое спасибо за статью. Недавно задался вопросом: а как чисто физически происходит подключение атс провайдера к магистральному оператору телефонии, если нужно например огромное количество линий? Неужели заводят кучу потоков Е1 в такой ситуации?
Доброе утро,
Для провайдерских сетей используется сигнализация ОКС-7 (SS7). В таких системах, используются все те же цифровые таймслоты (64кб/с). Голосовые таймслоты отделены от сигнальных. Но физически они объединяются в Е1, а потом несколько Е1 мультиплексируются в более сложные структуры – E2 (8,5 Mб/с), E3 (34Мб/с), E4 (139 Мб/с).
Получается, если магистральщик подает Е2 или выше, на приемной стороне нужно ставить мультиплектор и заводить в станцию отдельные E1, или может есть АТС, которые воспринимают потоки уровня иерархии выше единицы? Заранее спасибо.
Мне, к сожалению, очень мало довелось поработать на сетях провайдеров, поэтому точно ответить на Ваш вопрос я не смогу. Те провайдерские АТС, с которыми я сталкивался, имели интерфейсы Е1 и далее Е1 подавались в мультиплексоры (например, STM-1). Возможно, что есть и такие АТС, которые имеют и платы Е2.
Дмитрий, добрый день.
У нас такая проблема – два SABSCRIBER расположены в разных городах. Провайдер предоставляет не стабильный канал в результате у нас на серверах периодически появляется ошибка CCM_CALLMANAGER-CALLMANAGER-3-SDLLinkOOS. Т.е. как я понимаю контрольная TCP сессия между серверами рвется и сервер все звонки в направлении удаленного сервера аварийно отбивает (ошибки: (41) Temporary fallure, (21) Destination our of order). Улучшить канал провайдер не может. По этому видится два выхода: 1. Каким-то образом загрубить на CUCM 8.6.2. параметры ошибки CCM_CALLMANAGER-CALLMANAGER-3-SDLLinkOOS что бы CUCM на краткосрочные сбои в канале не реагировал (как правило на RTP трафик эти сбои не влияют и их не заметно) 2. Либо изменить параметры Announcement на CUCM что бы вместо аварийного отбоя пользователи слышали обычное BUZY, т.е. не пугались а просто перезванивали через несколько минут (обычно сбои в канале – 3-5 раз в час и длятся несколько секунд). Очень похоже что у провайдера ошибки на каком-то из интерфейсов в результате изредка пакеты отбрасываются. Извеняюсь что вопрос не по теме. Но он может быть актулен у кого подобные проблемы с SIP-провайдером. Буду благодарен за совет можно ли реализовать 1-ю или 2-ю идею.
Доброе утро,
К сожалению, с ходу вот так не отвечу на Ваш вопрос. Попробуйте поискать возможные настройки среди Enterprise Parameters (для 1 идеи) или среди Service Parameters для служб Cisco Call Manager и IP Voice Media Streaming Applications (идея 2).
В настоящий момент у меня нет под рукой ССМ, поэтому сам поискать не смогу 🙁
Спасибо за совет.
Дмитрий, а как в случае использования CUCME обходят ограничение в 15 правил, содержащихся в одном voice translation rules, если при звонке в город, т.е. при выходе с dial-peer voice voip в сторону провайдера нужно изменять 50 коротких внутренних номеров на 50 провайдерских?
Получится ли в этом случае использовать не voice translation rules, а voice class sip-profiles?
Еще задался вопросом, будет ли корректно отрабатывать для решения этой задачи добавление множества диалпиров к провайдеру, с clid network-number
на каждом(городской номер), и одинаковыми destination-pattern, с ограничением по COR-листам?
Да, это действительно проблема, если выходите к прову по VoIP, нумерация не совпадает совсем и необходимо преобразовать более 15 номеров.
Способ, предложенный Вами, в виде множества диал-пиров, COR-листов, и clid network-number работать, безусловно, будет. Но уж больно много диал-пиров придется создавать.
Я бы предложил вам попробовать создать voice-translation rule, далее voice translation-profile с этим правилом для calling-номера, а затем применить его в ephone-dn как incoming. Смысл тут вот какой: при создании ephone-dn CCME автоматически создает виртуальный POTS dial-peer, который выбирается как входящий при звонке с IP-телефона. Вот в этот момент мы и можем применить правило модификации номера.
Дожно быть так:
voice translation-rule 10
rule 1 /.*/ /требуемый номер/
!
voice translation-profile СLID1
translate calling 10
!
ephone-dn 1
translation-profile incoming CLID1
Делаете 50 нужных правил, 50 профилей и применяете на телефонах.
Дмитрий, а в этом случае номер будет транслироваться не только для внешних, но и для внутренних звонков?
Да, действительно… этот профиль ведь применится и для внутренних звонков тоже, что-то я об этом не подумал. 🙁
Тогда можно попробовать поэкспериментировать с voice class sip profile, меняя заголовки SIP. Иначе придется конфигурить кучу диалпиров. Других вариантов пока не вижу…
Наверное самым рациональным будет комплексный подход: voice translation rules с 15 правилами + corlist'ы. Таким образом число диалпиров сократится с 50 до 4.
Ну не соглашусь, что только 4 диалпира нужно будет. Да, их будет 4, если вы не будете разделять права доступа абонентов к тем или иным направлениям связи (город, межгород, международный). В противном случае, диал пиров будет минимум 16.
Здравствуйте, Дмитрий!
Огромное спасибо за статью! Опять я к вам с вопросом, никак не получается настроить SIP-транк с оператором МТТ. Наш маршрутизатор не регистрируется. Возможно, вы подскажете где стоит искать проблему.
Нам предоставили логин – 1111222233334444, пароль – 12345 и А-номер – 78888777777 (я не стал указывать реальные данные, в том числе ip-адреса, кроме МТТ – их ip общедоступная информация).
Часть конфига:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
h323
sip
bind control source-interface GigabitEthernet0/0
!
interface GigabitEthernet0/0
ip address 192.168.0.1 255.255.255.0
duplex auto
speed auto
!
dial-peer voice 1 voip
translation-profile outgoing 1
destination-pattern 8……….
session protocol sipv2
session target sip-server
codec g711ulaw
!
!
sip-ua
credentials username 1111222233334444 password 12345 realm sip.mtt.ru
authentication username 11112222333344444 password 12345
registrar dns:sip.mtt.ru:5060 expires 3600
sip-server dns:sip.mtt.ru:5060
CUBE находится за NAT, настроен проброс портов:
ip nat inside source static tcp 192.168.0.1 5060 1.1.1.1 5060 extendable
ip nat inside source static udp 192.168.0.1 5060 1.1.1.1 5060 extendable
В результате процесс регистрации выглядит так:
192.168.0.1 -> 80.75.130.134 Request: REGISTER sip:sip.mtt.ru:5060
80.75.130.134 -> 192.168.0.1 Status: 401 Unauthorized (0 bindings)
192.168.0.1 -> 80.75.130.134 Request: REGISTER sip:sip.mtt.ru:5060
80.75.130.134 -> 192.168.0.1 Status: 403 Forbidden (0 bindings)
Денис.
Добрый день, Денис!
Прошу извинить меня за задержку с ответом – большая загрузка слишком сейчас, поэтому отвечаю по возможности. Я бы хотел взглянуть на debug ccsip messages при регистрации. Напишите, пожалуйста, в форме для связи свой мейл, по почте общаться проще.
Здравствуйте, Дмитрий!
Спасибо за ответ. Проблема оказалась в том, что нам сообщили неверный пароль 🙂
Пользуясь моментом, хочу задать ещё один вопрос, правда не на тему SIP. Схема такая:
CUCM—h323—3925—E1—АТС
CUCM состоит из двух серверов publisher и subscriber. В сторону CUCM был всего один dial-peer, в session target которого указан IP publisher-а. И был dial-peer в сторону АТС. Всё работало.
Но случилось так, что сейчас телефоны зарегистрированы на subscriber-е и именно он устанавливает соединение с маршрутизатором, при этом publisher доступен. Звонки из АТС в CUCM продолжают ходить, но вот IP-телефоны звонить на АТС не могут. Помогло создание второго dial-peer но уже в session target которого указан IP subscriber.
Доступа к CUCM у меня нет, он принадлежит другой организации. Знаю, что в "Route list" стоит галочка "Run on all active unified cm nodes". IP publisher-а – 192.168.0.1, IP subscriber-а – 192.168.0.2. Конфигурация маршрутизатора:
dial-peer voice 1 voip
description ## publisher ##
preference 1
destination-pattern 3…
session target ipv4:192.168.0.1
!
dial-peer voice 2 voip
description ## subscriber ##
preference 2
destination-pattern 3…
session target ipv4:192.168.0.2
!
dial-peer voice 3 pots
description ##АТС##
destination-pattern 4…
port 0/0/0:15
Мне не понятно, почему при отсутствии dial-peer 2, не проходят входящие звонки из CUCM в АТС, при условии, что соединение устанавливает subscriber. Debug voice dialpeer показывает, что маршрутизатор принимает цифры 4…, выбирает dial-peer 3 и на этом всё.
Денис
denis_lisitsyn@mail.ru
Добрый вечер, Денис!
Я думаю, что причиной такого поведения шлюза является то, что шлюз не принимает VoIP вызовы от устройств с неизвестными ему IP-адресами. Эта фича появилась в релизе IOS 15.0. Скорее всего, если Вы посмотрите дебаги таких неуспешных звонков, Вы увидете cause 127…
Добавляя диал-пир 2, Вы указываете адрес встречной стороны, теперь этот айпишник известен шлюзу и он спокойно расценивает вызывающее устройство как известное и обрабатывает вызовы.
Добрый день, Дмитрий!
Спасибо, за статью очен полезная!
какие можно ли роутер 2811 использовать и как маршрутизатор и как CUBE? и какой IOS нужна для этого? с уважением. Рус
Здравствуйте,
Спасибо за Ваш отзыв. Конечно, можно использовать 2811 и как маршрутизатор, и как CUBE. По поводу IOS – можно использовать любой войсовый, который поддерживает функционал CUBE (посмотреть это можно с помощью Feature Navigator на cisco.com)
Как вариант, подойдет IOS, содержащий в своем названии буквы ivs.
Действительно в 3845 с IOS 12.0 такой проблемы не наблюдается. В таком случае как же разрешить входящие звонки от устройств, в направление которых dial-peer не нужны? Создавать access list?
Денис
Нет, ACL не нужен. Нужно сконфигурировать так называемый ip trusted list. Это, по сути, список доверенных айпишников, с которыми разрешается соединение по VoIP.
Более подробнее об этой функции тут:
http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080b3e123.shtml
Огромное спасибо!
Добрый день Дмитрий,
Спасибо за ответ.
у меня такая ситуация. 1 большое здание разделенное на 2 крыла. на одном крыле CUCM 7 развернут а на втором крыле развернут IP PBX. LAN между крылами идет через 2811 который стоит на 2м крыле. задача соеденить SIP абонентов IP PBX 2 го крыла с абонентами CUCM.
SIP абонент—–IP PBX —-2811—((облако сеть 1 го крыла)—CUCM7—–абоненты Cisco
для этого обязательно нужен CUBE? и если да то 2811 могу сделать CUBE?
Заранее спасибо
Рустам
Добрый день, Рустам!
Если речь идет об общей корпоративной сети, где нет проблем с маршрутизацией и не ставится задача обеспечения безопасности (т.е., например, скрытия IP-адресов одного крыла от другого), в принципе, можно обойтись и без CUBE. Он тогда не нужен.
CUBE обычно ставят на границе 2х разных IP-сетей, если одна из сетей вами не контролируется. Тогда да, CUBE нужен, однозначно. А если делать без CUBE, то нужно на ССМ создать SIP-транк, ну и настроить ту вторую АТСку, а также обеспечить IP маршрутизацию между ними для голоса и сигнализации.
Добрый день, Дмитрий!
Спасибо за скорый ответ!
Дело в том, что 2 крыла на разных подсетях и маршрутизация по IP настроена. конечно есть некоторые ограничения на некоторые подсети. IP АТС на базе виндоус 3сх и sip транк требует регистрации. а в CUCM не смог его зарегистрировать. если можно без CUBE настроить CCM с 3сх можете дать направление в какую сторону копать в CUCM?
С уважением,
Рустам
arus80@inbox.ru
Добрый день!
Если требуется регистрация транка, то тут без CUBE никак не обойтись, даже во внутренней сети. Придется ставить, ССМ сам региться не умеет, увы 🙁 Realm тут не поможет…
Добрый день, Дмитрий. Такой вопрос. Регистрируюсь у провайдера по SIP, дальше уходит на CUCM, все хорошо, но встает один вопрос – когда я регистрируюсь, то в таблице NAT появляется запись, пока она существует звонки входящие ко мне идут, как только запись пропадает, то все. Я понимаю что надо сделать обратный NAT, но можно ли как-то без обратного NAT-а, чтобы была отправка пакетов для обновлении этой записи трансляции. Сейчас вышел из положения путем уменьшением времени жизни регистрации, то есть до того как пропадет запись у меня клиент перерегистрируется у провайдера. Заранее спасибо.
Добрый день, Александр!
А что, если сделать статический NAT? Тогда такие записи будут в таблице постоянно. Или попробовать увеличить время хранения записей трансляции с помощью команды ip nat translation?
http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr/command/ipaddr-i4.html#wp3178213110
Добрый день, Дмитрий!
Спасибо за ответ! вопрос можно ли сперва настроить SIP транк между IP PBX и CUBE без ССМ. то есть чтобы CUBE зарегистрировался на SIP PBX?
С уважением,
Рустам
Добрый день, Рустам!
Да, так сделать можно. С этим нет проблем. Настраивайте и регистрируйте сначала CUBE, потом настраивайте ССМ. Порядок не имеет значения.
Спасибо за ответ. Про NAT то понятно. Просто на идею без статического NAT меня сподвигли строчки из статьи Андрея Погребенника –
"Проблема актуальна не только в период после регистрации пользователя: во время SIP-диалогов новые сообщения также могут не поступать в течение длительного промежутка времени, чего достаточно для того, чтобы запись из таблицы трансляции была удалена. Имеющиеся SIP-стеки решают эту проблему путём периодической посылки SIP-запросов re-INVITE, OPTIONS, INFO, NOTIFY или (при использовании UDP) дейтаграмм, не содержащих полезной нагрузки." (c) http://samag.ru/archive/article/2017
Вот и задался данным вопросом. Решил спросить у Вас.
Добрый день, Александр. NAT – это абсолютное зло для IP-телефонии. В случаях, если есть возможность взять "белый" айпишник, то надо использовать CUBE, а не NAT.
Спасибо за ссылку на статью, интересно. Почитаю на досуге. Сейчас веду курс в Алматы… 🙂
Добрый день, Дмитрий!
Спасибо, за ответ!
Я настроил следующим образом но пока не регистрируется, где моя ошибка пожалуйста укажите.
топология следующая:
IP PBX——–sip trunk——CUBE
ip адресс АТСки 10.21.3.150
адрес интерфейса CUBE 10.21.3.231
на АТСке создал SIP транк как мастер для прием запросов на регистрацию
внутренний номер (ID)10001 пароль 10001, SIP порт 5060
настроил CUBE след образом:
Current configuration : 1860 bytes
!
! Last configuration change at 11:29:14 UTC Wed Nov 20 2013
!
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
dot11 syslog
ip source-route
!
ip cef
!
!
!
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
voice service voip
allow-connections sip to sip
sip
bind control source-interface FastEthernet0/1
!
!
!
!
voice-card 0
!
crypto pki token default removal timeout 0
!
!
!
!
license udi pid CISCO2811
!
redundancy
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
description PBX
ip address 10.21.3.231 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1 этот интерфейс в дальнейшем для ССМ
ip address 10.200.3.5 255.255.255.0
duplex auto
speed auto
!
interface Async0/0/0
no ip address
encapsulation slip
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
!
logging esm config
!
!
!
!
!
control-plane
!
!
voice-port 0/1/0
!
voice-port 0/1/1
!
!
!
!
dial-peer voice 8 voip
description to PBX
destination-pattern 8….
session protocol sipv2
session target sip-server
voice-class sip outbound-proxy dns:10.21.3.150:5060
codec g711ulaw
!
dial-peer voice 847 voip
description To-CUCM
destination-pattern 9….
session protocol sipv2
session target ipv4:10.200.3.2
codec g711ulaw
!
!
sip-ua
credentials username 10001 password 7 06575F711C1F realm 10.21.3.150
authentication username 10001 password 7 00554356540A realm 10.21.3.150
registrar dns:10.21.3.150:5060 expires 360
sip-server dns:10.21.3.150:5060
!
!
!
line con 0
line aux 0
line 0/0/0
stopbits 1
speed 115200
flowcontrol hardware
line vty 0 4
– login
transport input all
!
scheduler allocate 20000 1000
end
Router#sh sip-ua register status
Line peer expires(sec) registered P-Associ-URI
================================ ========== ============ ========== ============
10001 -1 11 no
В логах PBX нет никаких сообщений. и debug ccsip messages ничего не дает.
Ping меду CUBE и PBX есть.
С уважением,
Рустам
arus80@inbox.ru
Думаю, что ошибка у Вас вот тут:
registrar dns:10.21.3.150:5060 expires 360
sip-server dns:10.21.3.150:5060
Вы указываете айпишники, а пишите тип адреса – dns. Правильно вот так:
registrar ipv4:10.21.3.150:5060 expires 360
sip-server ipv4:10.21.3.150:5060
Дмитрий, спасибо за ответ, что то начало двигаться но дебаг дает следующие:
Router#
*Nov 22 11:46:56.924: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:10.21.3.150:5060 SIP/2.0
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK347A72
From: ;tag=611C31C-400
To:
Date: Fri, 22 Nov 2013 11:46:56 GMT
Call-ID: 4F90F85D-529D11E3-80039B68-BC8F3581
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1385120816
CSeq: 21 REGISTER
Contact:
Expires: 360
Supported: path
Content-Length: 0
*Nov 22 11:46:57.028: //848/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK347A72
Proxy-Authenticate: Digest nonce="414d535c089fd2ea82:7db90dab5316d05e850e92b6058
f1d35",algorithm=MD5,realm="3CXPhoneSystem"
To: ;tag=3f75bc2e
From: ;tag=611C31C-400
Call-ID: 4F90F85D-529D11E3-80039B68-BC8F3581
CSeq: 21 REGISTER
User-Agent: 3CXPhoneSystem 12.0.32816.397 (32731)
Content-Length: 0
Регистрация не проходит
С уважением,
Рустам
Доброе утро, Рустам!
Попробуйте изменить realm. У вас он указан как realm 10.21.3.150, а станция ожидает realm="3CXPhoneSystem" (это видно из дебага).
Вам надо прописать в командах регистрации realm 3CXPhoneSystem
Добрый день.
Имеется 3925 с CUBE и E1 до УАТС LDK-300 предприятия. Появилась в др. офисе еще одна АТС LG, которая пока работает через первую АТС (в том числе так как единая внутренняя нумерация между офисами).
т.е. по схеме так: АТС новая ->АТС старая->3925 cube-> SIP провайдер
Решили подключить новую АТС напрямую через cube на 3925 по sip.
Т.е. задумка такая: Что выход в город с новой АТС гнать напрямую, а внутреннее номера пусть идут так же как было.
Текущий диал-пир для выхода в город (т.е. на sip провайдера), через 9:
dial-peer voice 9 voip
tone ringback alert-no-PI
translation-profile outgoing 63 – это просто заменяет caller ID на единый телефон
destination-pattern .T
progress_ind setup enable 3
progress_ind alert enable 8
modem passthrough protocol codec g711alaw
session protocol sipv2
session target ipv4:IP провайдера:5071
voice-class sip early-offer forced
voice-class sip bind control source-interface GigabitEthernet0/2.183
voice-class sip bind media source-interface GigabitEthernet0/2.183
dtmf-relay rtp-nte sip-notify sip-kpml
codec g711alaw
fax rate 14400
clid strip name
no vad
Создал новый диал-пир:
dial-peer voice 1400 voip
description ===== TEST=====
session protocol sipv2
session target ipv4:IP новой АТС:5060
session transport tcp
answer-address для тестов, вписал один из номеров в новом офисе (для того чтобы диал-пир отматчился по calling number) с которого тестируем звонки.
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
dtmf-relay rtp-nte sip-notify sip-kpml
codec g711alaw
no vad
Однако звонки идут по старому, а АТС новая не регистрируется на cisco. Ей требуется логин-пароль, т.е.регистрация на sip-сервере. cucm или cme у нас нет. Есть ли вариант прямого транка до cube без логина-пароля? Или я неверно диал-пир сделал?
Доброе утро,
СUBE поддерживает соединения по SIP и без регистрации. Поддерживает ли такой режим ваша новая АТС, или у нее есть только режим с регистрацией? Если только с регистрацией, то можно на вашем 3925 активировать СМЕ без проблем (думаю, что даже не потребуется дополнительная лицензия для этого),
В случае активации СМЕ транк с вашей АТСки будет регистрироваться как телефон. Посмотрите, пожалуйста, в моих более ранних постах статью о регистрации SIP-телефонов сторонних производителей, там все настройки приведены.
Если АТС поддерживает и транк без регистрации, то тогда нужно разбираться, почему не проходят звонки. Сначала нужно понять, какой диал-пир выбирается в качестве входящего (debug voip ccapi inout или debug voip dialpeer). Также нужно смотреть debug ccsip messages, чтобы увидеть причину отбоя.
Добрый день Дмитрий!
Спасибо огромное регистрация прошла успешно!
теперь возникли с bind интерфейсом в сторону ССM. так как ССM и IP PBX доступны через один и тот же интерфейс fa0/0 можно ли использовать в CUBE только 1 интерфейс? и еще проблемы с диал пирами. IP PBX имеет 4х значные номера и исходящие правила настроены через 8ку. Call manager тоже имеет 4х значные номера выход на IP PBX через 9ку. как настроить диал пиры чтобы при наборе с обеих сторон соответствующих префиксов CUBE направлял звонки в соответствующие порты.
dial-peer voice 8 voip
description to 3CX
destination-pattern 8….
session protocol sipv2
session target ipv4:10.21.3.150:5060
no voice-class sip outbound-proxy
codec g711ulaw
!
dial-peer voice 847 voip
description To-CUCM
destination-pattern 9….
session protocol sipv2
session target ipv4:10.200.3.2
codec g711ulaw
С уважением, Рустам
Добрый день, Рустам!
Думаю, что можно использовать 1 интерфейс, проблему это не должно вызывать, если его айпишник "виден" и со стороны ССМ, и со стороны IP PBX.
По поводу диал-пиров: здесь надо понимать, отправляется ли вместе четырьмя цифрами 9ка или 8ка. Если да, то, тогда destination-pattern верно прописана. Если нет, то тогда нужно в destination-pattern сделать изменения.
Дмитрий, спсибо за скорый ответ!
9ка и 8ка не должны отправляться! то есть абонент со стороны CCM выходит в сторону PBX через 9ку и наоборот абоненты PBXа в сторону CCM через 8ку. при этом чтобы они могли звонить на любой существующий номер друг друга .
С уважением,
Рустам
В таком случае и диалпиры должны содержать 4х значные destination-pattern. Только нельзя в обоих писать просто …. Тут все зависит от нумераций на АТС и на ССМ. Если они не пересекаются, то все просто. Ну а если пересекаются, т.е начинаются на одинаковую цифру, то тогда нужно пересылать и 9ку и 8ку. По-другому никак не получится.
Спасибо за ответ.
ВОт мне говорят что на CME вроде как нужна до лицензия…
Приведит,е пожалуйста, ссылку на это решение – регистрации SIP-телефонов сторонних производителей.
>Также нужно смотреть debug ccsip messages, чтобы увидеть причину отбоя.
В том и дело что пусто было просто в логах. Видимо потому что АТС пыталась зарегистрироваться, а такой функционал не включен (CME).
Доброе утро,
Ссылка на пост о регистрации SIP-телефонов на СМЕ:
http://dbenda.blogspot.com/2011/10/sip-call-manager-express.html
Добрый день, Дмитрий!
Нумерация на АТСке и CCM 4х значные. в dest-pattern для теста прописал существующие номера с обеих сторон. CCM настройках SIP транка указан IP аддресс роутера 10.21.3.151 порт 5060
для теста я хочу пока хотябы в одну сторону звонки пошли с АТСки в сторону CCM. проверьте пожалуйста правильно ли я иду?
interface FastEthernet0/0
description 3CX
ip address 10.21.3.151 255.255.255.0
dial-peer voice 8 voip
description to 3CX
destination-pattern 1001
session protocol sipv2
session target ipv4:10.21.3.150:5060
no voice-class sip outbound-proxy
codec g711ulaw
!
dial-peer voice 847 voip
description To-CUCM
destination-pattern 1126
session protocol sipv2
session target ipv4:10.200.3.2
codec g711ulaw
!
sip-ua
credentials username 10001 password 7 055A565F711D realm 3CXPhoneSystem
registrar ipv4:10.21.3.150:5060 expires 36
Пробую звонить с АТСки на номер ССМ 1126
debug ccsip message
SIP Call messages tracing is enabled
Router#
*Nov 27 11:45:46.895: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:1126@10.21.3.151:5060 SIP/2.0
Via: SIP/2.0/UDP 10.21.3.150:5060;branch=z9hG4bK-d8754z-ab6fed41e0427b04-1—d87
54z-;rport
Max-Forwards: 70
Contact:
To:
From: "test test";tag=dd61c11e
Call-ID: NjRiNGZlYWJiYTliOWVhZTAwNGI4ZWJmNTY5N2ZhNGQ.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, IN
FO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CXPhoneSystem 12.0.32816.397 (32731)
Content-Length: 315
Remote-Party-ID: "test test";party=calling
v=0
o=3cxPS 106635984896 114554830849 IN IP4 10.21.3.150
s=3cxPS Audio call
b=AS:84
t=0 0
a=X-nat:0
m=audio 42034 RTP/AVP 0 8 3 96
c=IN IP4 10.21.2.199
b=TIAS:64000
a=rtcp:42035
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
*Nov 27 11:45:46.915: //3504/4A0DE80B807E/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.21.3.150:5060;branch=z9hG4bK-d8754z-ab6fed41e0427b04-1—d87
54z-;rport
From: "test test";tag=dd61c11e
To:
Date: Wed, 27 Nov 2013 11:45:46 GMT
Call-ID: NjRiNGZlYWJiYTliOWVhZTAwNGI4ZWJmNTY5N2ZhNGQ.
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
*Nov 27 11:45:46.927: //3505/4A0DE80B807E/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:1126@10.200.3.2:5060 SIP/2.0
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK10038E1
Remote-Party-ID: "test test" ;party=calling;screen=no;priv
acy=off
From: "test test" ;tag=1FD07DC8-499
To:
Date: Wed, 27 Nov 2013 11:45:46 GMT
Call-ID: 4A122DBB-569011E3-80849B68-BC8F3581@10.21.3.151
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1242425355-1452282339-2155780968-3163501953
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIF
Y, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1385552746
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 212
v=0
o=CiscoSystemsSIP-GW-UserAgent 6659 9170 IN IP4 10.21.3.151
s=SIP Call
c=IN IP4 10.21.3.151
t=0 0
m=audio 17318 RTP/AVP 0 19
c=IN IP4 10.21.3.151
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
*Nov 27 11:46:50.435: //3504/4A0DE80B807E/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 10.21.3.150:5060;branch=z9hG4bK-d8754z-ab6fed41e0427b04-1—d87
54z-;rport
From: "test test";tag=dd61c11e
To: ;tag=1FD175DC-1BB7
Date: Wed, 27 Nov 2013 11:45:46 GMT
Call-ID: NjRiNGZlYWJiYTliOWVhZTAwNGI4ZWJmNTY5N2ZhNGQ.
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=102
Content-Length: 0
Как узнать CCM и CUBE видят друг друга или нет?
С уважением,
Рустам
Доброе утро, Рустам!
Диалпиры прописаны правильно, однако в приведенном дебаге не видно, что звонок проходит через CUBE к ССМ (должен быть отправлен INVITE в сторону ССМ).
Проверьте, прописаны ли в конфиге CUBE следующие команды:
voice service voip
allow-connections sip to sip
Дмитрий здравствуйте,
Спасибо за ответ, в конфиге CUBE прописаны след. команды
voice service voip
no ip address trusted authenticate
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
sip
bind control source-interface FastEthernet0/0
bind media source-interface FastEthernet0/0
и в приведенном выше дебаге INVITE в сторону CCM CUBE все таки отправляет.
Sent:
INVITE sip:1126@10.200.3.2:5060 SIP/2.0
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK10038E1
Remote-Party-ID: "test test" ;party=calling;screen=no;priv
acy=off
From: "test test" ;tag=1FD07DC8-499
To:
Date: Wed, 27 Nov 2013 11:45:46 GMT
Call-ID: 4A122DBB-569011E3-80849B68-BC8F3581@10.21.3.151
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1242425355-1452282339-2155780968-3163501953
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIF
Y, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1385552746
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 212
v=0
o=CiscoSystemsSIP-GW-UserAgent 6659 9170 IN IP4 10.21.3.151
s=SIP Call
c=IN IP4 10.21.3.151
t=0 0
m=audio 17318 RTP/AVP 0 19
c=IN IP4 10.21.3.151
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
на самом деле он эти инвайты много раз пробовал отправить, но так как здесь кол-во строк ограничено я дублирующие записи вырезал.
так значит у меня ИНВАЙТ в сторону CCM 10.200.3.2 отправляет. но CCM не отвечает так получается?
у меня задействован 1 интерфейс fa0/0 на обе стороны. и оба айпишника с CUBE пингуется.
С уважением,
Рустам
А да, действительно, инвайт уходит на ссм, прсмотрел я его, сори. Не проснулся еще, утро в Москве 🙂
Теперь нужно проверять настройки на ССМ. Я полагаю, что сип-транк на ССМ у вас настроен, верно? В первую очередь, надо сверить айпишник, установленный на сип-транке . Также нужно проверить транспорт (TCP/UDP), установленный на ССМ для SIP-сообщений. От CUBE они уходят с транспортом UDP. Нужно, чтобы такой же транспорт был и на ССМ.
А не подскажете, куда копать в таком случае: если я прописываю диалпир в сторону другой CUCM (CUCME) системы через туннель VPN (L2TP) – как заставить работать такое соединение?
У меня происходит отбой через (почему-то) 5 секунд ожидания с Cause Code 38 (Network Failure).
Диалпир вот:
=====
dial-peer voice 232 voip
destination-pattern 232
session target ipv4:10.108.196.201
voice-class codec 1
=====
Адрес на той стороне зарулен статическими маршрутами, пингуется в обе стороны именно от тех исходных адресов, которые указаны в диалпирах, и все равно – 5 секунд ожидаия и отбой, причём по туннелю не передаётся ни байта (проверял с помощью debug ip packet detailed на дальней стороне).
Добрый день, Сергей!
Проблема явно сетевая тут. А пинги в туннель уходят? Сам туннель-то работает (protocol is up)?
Да, конечно. Я же пишу, что всё поднято, адреса пингуются, и с явным указанием исходных тоже. Правда странно, что не работает tracert дальше дальнего конца туннеля, но пинги ходят на ура, ftp и ssh тоже проверено – по туннелю летает.
Не подскажу так, увы… 🙁 Топологию бы нужно знать, что там и как. А вслепую… ну только гадать на кофейной гуще. 🙁
Могу однозначно сказать, что по L2TP телефония работает. Мы часто используем L2TPv3 для удаленных лаб.
Топология простая:
2901 на которой поднят сервер VPN/L2TP включена в интернет езернетом, имеет реальник на интерфейсе.
Другая такая же 2901 воткнута в LTE роутер Youta, который как раз работает клиентом L2TP с указанием адреса сервера первого роутера.
Соответственно удалённые адреса зарулены друг на дуга через концы туннеля статическими маршрутами. Пинги летают, ssh соединяется, ftp передается.
именно по туннелю – проверено.
Я даже прописал на интерфейсах, с которых уходят пакеты друг на друга, команду (с двух сторон)
h323-gateway voip bind srcaddr 10.108.204.201
h323-gateway voip bind srcaddr 10.108.196.201
– не помогло.
Bind-команды используются только для телефонных функций, на маршрутизацию они никак не повлияют, поэтому их прописывание ничего не дало.
А диал-пиры Вы прописываете на этом же 2901, на котором поднят L2TP?
Нет, на соседнем.
То есть полная схема так:
2901 с телефонами и диалпирами
– 2901 коммуникационный, тут же реальный IP и L2TP,
затем туннель,
на дальнем конце туннеля клиент в LTE роутере,
дальше 2901 с телефонами.
Пинги ходят на ура.
В LTE роутере в фарйволе прописал на всякий случай пропускать через туннельный интерфейс всё и всюду.
Можно взглянуть на конфиг, отвечающий за L2TP на 2901?
L2TP по принципу "ничего лишнего"
======
vpdn-group ToRemotePhones
! Default L2TP VPDN group
accept-dialin
protocol l2tp
virtual-template 1
lcp renegotiation on-mismatch
no l2tp tunnel authentication
ip pmtu
ip mtu adjust
!
interface Virtual-Template1
ip address 10.108.195.1 255.255.255.252
peer default ip address pool MGTESPOOL
ppp authentication pap
!
======
и локальный юзер с уровнем 0 для авторизации клиента VPN
Работает на ура, клиентом LTE роутер Zyxel Kinetik 4G
Кстати может иметь значение, что на разнесённых площадках одинаковые внутренние номера? 100,101….115
А входящий номер который прописан диалпиром 332 назначен на удалённой площадке на hunt-group.
Для телефонной маршрутизации это, конечно, имеет значение, обычно это решается путем использования кодов внутренних АТС (например, на обоих сторонах нумерация 1ХХ, одна АТС имеет код 11, вторая 12, набираются при звонках между АТС 11-1ХХ и 12-1ХХ соответственно).
Но тут, видимо, проблема все же в маршрутизации сетевой (Вы же пишите, что телефонный трафик не попадает в туннель L2TP). ACL никаких, случайно, на пути телефонного трафика нет? Если это Н323, то открыты ли порты 1719, 1720 (TCP обычно)?
Дмитрий, спасибо за ответ.
настройки CCM проверил. Destination адрес правильный 10.21.3.151 транспорт исходящий UDP и incoming transport type TCP+UDP.
route pattern пробовал 7.1001 и discard digit: pre dot. пробую звонить тишина. и на CUBE debug ничего не регистрирует.
также пробовал паттерн 7.#! при этом сразу короткие гудки debug молчит.
такое ощущение что транка между ccm и CUBE нет.
истина где то рядом.
А пингуется ли 10.21.3.151 с ССМ? В командной строке ССМ для пинга нужно использовать utils network ping 10.21.3.151.
Здравствуйте!
Интересная ситуация, раньше с таким не сталкивался:
один и тот же абонент CUCM (на шлюзе VG224) несколько раз подряд набирает один и тот же городской номер, вызовы идут по одному и тому же маршруту, но CUCM к другой станции шлет INVITE иногда с SDP, иногда без. Маршрутизация по времени не используется. В трейсах 2 инвайта отличаются только наличием поля Message Body. С чем это может быть связано?
С уважением, Евгений.
Добрый день, Евгений!
Invite c SDP и без SDP означает разные режимы работы сигнализации SIP – Early Offer и Delayed Offer соответственно. Скажите, установлена ли на SIP-транке галочка MTP required (Media Termination Point Required)?
Разобрался. Оказывается, мало настроить маршрутизацию между цисками, надо ещё и между телефонами (!). Додумался до этого, только увидев в логе вместо адреса второго роутера адрес тамошнего телефона.
🙂 поздравляю 🙂 Однако, не совсем понятно. Да, маршрутизация между телефонами нужна, безусловно, иначе не будет ходить голосовой трафик. Но сигнализация то должна ходить между двумя телефонными 2901, и для нее маршрутизация между телефонами не нужна, по идее. Если бы не было маршрутизации между подсетями телефонов, вы бы получили отсутствие голосового трафика, но звонок бы проходил.
Если найдете время, был бы Вам признателен за пояснения. Интересный просто случай.
Спасибо за ответ.
Галка установлена, MRG-list выбран. Версия CUCM 7.
Такая же ситуация наблюдается при транзитном вызове через CUCM с MGCP-шлюза (там подключена по DSS1 другая станция) в SIP-транк: INVITE уходит то c Early Offer, то с Delayed Offer без всякой закономерности.
Может недостаточно МТР ресурсов? Посмотрите в RTMT (счетчики) сколько имеется МТР и какова их загрузка.
Дмитрий, добрый день,
debug ccsip error
выдает следующие сообщения во время звонка с АТСки. что это означает?
*Nov 29 08:33:42.780: //-1/xxxxxxxxxxxx/SIP/Error/debugPrintBranchList: via bran
ch list is:
*Nov 29 08:33:42.780: //-1/xxxxxxxxxxxx/SIP/Error/debugPrintBranchList: end
of list
*Nov 29 08:33:42.888: //-1/xxxxxxxxxxxx/SIP/Error/debugPrintBranchList: via bran
ch list is:
*Nov 29 08:33:42.888: //-1/xxxxxxxxxxxx/SIP/Error/debugPrintBranchList: end
of list
SIP: (4194) Attribute mid, level 1 instance 1 not found.
SIP: (4195) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: (4195) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: (4195) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: (4195) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: (4195) Group (a= group line) attribute, level 65535 instance 1 not found.
SIP: (4195) Group (a= group line) attribute, level 65535 instance 1 not found.
Добрый день, Дмитрий! Связь с CCM установилась но звонки не проходят с АТСКи и ССM. выдает следующее: Received:
INVITE sip:1001%23@10.21.3.151:5060 SIP/2.0
Date: Fri, 29 Nov 2013 10:54:49 GMT
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY
From: "ссm user" ;tag=f604371e-74d5-421b-b364-4a75e2a
f6cdd-21270040
Allow-Events: presence, kpml
P-Asserted-Identity: "ccm user"
Supported: timer,resource-priority,replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Min-SE: 1800
Remote-Party-ID: "ccm user" ;party=calling;screen=yes
;privacy=off
Content-Length: 208
User-Agent: Cisco-CUCM7.1
To:
Contact:
Expires: 180
Content-Type: application/sdp
Call-ID: a96d6800-29817279-31-203c80a@10.200.3.2
Via: SIP/2.0/UDP 10.200.3.2:5060;branch=z9hG4bK3011621e22
CSeq: 101 INVITE
Session-Expires: 1800
Max-Forwards: 70
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.200.3.2
s=SIP Call
c=IN IP4 10.200.3.2
t=0 0
m=audio 29348 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
*Nov 29 11:06:28.319: //4245/210BA6A68124/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.200.3.2:5060;branch=z9hG4bK3011621e22
From: "ccm user" ;tag=f604371e-74d5-421b-b364-4a75e2a
f6cdd-21270040
To:
Date: Fri, 29 Nov 2013 11:06:28 GMT
Call-ID: a96d6800-29817279-31-203c80a@10.200.3.2
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
*Nov 29 11:06:28.323: //4246/210BA6A68124/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:1001@10.21.3.150:5060 SIP/2.0
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK14BE257B
Remote-Party-ID: "ccm user" ;party=calling;screen=ye
s;privacy=off
From: "ccm user" ;tag=29F93884-1C37
To:
Date: Fri, 29 Nov 2013 11:06:28 GMT
Call-ID: 210EB406-581D11E3-812A9B68-BC8F3581@10.21.3.151
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0554411686-1478300131-2166659944-3163501953
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIF
Y, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1385723188
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 212
v=0
o=CiscoSystemsSIP-GW-UserAgent 4373 9334 IN IP4 10.21.3.151
s=SIP Call
c=IN IP4 10.21.3.151
t=0 0
m=audio 16676 RTP/AVP 0 19
c=IN IP4 10.21.3.151
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
*Nov 29 11:06:28.423: //4246/210BA6A68124/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK14BE257B
Proxy-Authenticate: Digest nonce="414d535c08a9040525:e7b15e4eb8c334c86feebf16488
6b4f5",algorithm=MD5,realm="3CXPhoneSystem"
To: ;tag=7b256c67
From: "ccm user";tag=29F93884-1C37
Call-ID: 210EB406-581D11E3-812A9B68-BC8F3581@10.21.3.151
CSeq: 101 INVITE
User-Agent: 3CXPhoneSystem 12.0.32816.397 (32731)
Content-Length: 0
кажется дело в Dial pattern? Атска тоже фиксирует запрос и пишет unidentified incoming call.
Добавление к предыдущему сообщению часть debug
*Nov 29 11:06:28.435: //4245/210BA6A68124/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 10.200.3.2:5060;branch=z9hG4bK3011621e22
From: "Eric Tabaldiev" ;tag=f604371e-74d5-421b-b364-4a75e2a
f6cdd-21270040
To: ;tag=29F938F8-1B70
Date: Fri, 29 Nov 2013 11:06:28 GMT
Call-ID: a96d6800-29817279-31-203c80a@10.200.3.2
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=47
Content-Length: 0
*Nov 29 11:06:28.439: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:1001%23@10.21.3.151:5060 SIP/2.0
Date: Fri, 29 Nov 2013 10:54:49 GMT
From: "Eric Tabaldiev" ;tag=f604371e-74d5-421b-b364-4a75e2a
f6cdd-21270040
Allow-Events: presence, kpml
Content-Length: 0
To: ;tag=29F938F8-1B70
Call-ID: a96d6800-29817279-31-203c80a@10.200.3.2
Via: SIP/2.0/UDP 10.200.3.2:5060;branch=z9hG4bK3011621e22
CSeq: 101 ACK
Max-Forwards: 70
А Вы в обоих строчках (credentials и auhentication) поменяли realm на правильный? Или сделали это только для строки credentials?
Realm должен быть правильный в обеих строках.
Да пингуется!
Дмитрий, спасибо за помощь!
Действительно не хватает ресурсов MTP.
Добрый день, Дмитрий!
реалм в обоих строках одинаковый
вот полная конфиг-я
voice service voip
ip address trusted list
ipv4 10.200.3.0 255.255.255.0
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
sip
bind control source-interface FastEthernet0/0
bind media source-interface FastEthernet0/0
interface FastEthernet0/0
description 3CX
ip address 10.21.3.151 255.255.255.0
duplex auto
speed auto
dial-peer voice 8 voip
description to 3CX
destination-pattern 1001
session protocol sipv2
session target ipv4:10.21.3.150:5060
no voice-class sip outbound-proxy
codec g711ulaw
!
dial-peer voice 847 voip
description To-CUCM
destination-pattern 1126
session protocol sipv2
session target ipv4:10.200.3.2:5060
codec g711ulaw
sip-ua
credentials username 10001 password 7 055A565F711D realm 3CXPhoneSystem
authentication username 10001 password 7 040A5B565F70 realm 3CXPhoneSystem
registrar ipv4:10.21.3.150:5060 expires 360
Вот дебаг в обратную сторону с АТСки в сторону CUCM
*Dec 2 09:17:12.730: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:1126@10.21.3.151:5060 SIP/2.0
Via: SIP/2.0/UDP 10.21.3.150:5060;branch=z9hG4bK-d8754z-5d11c748ea412f19-1—d87
54z-;rport
Max-Forwards: 70
Contact:
To:
From: "test test";tag=d201af51
Call-ID: NTczZWJiOWQxNmQ5MGIzMjAyNTRhMGRmODE4NjQ3NDk.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, IN
FO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CXPhoneSystem 12.0.32816.397 (32731)
Content-Length: 228
Remote-Party-ID: "test test";party=calling
v=0
o=3cxPS 29880221696 488737079297 IN IP4 10.21.3.150
s=3cxPS Audio call
c=IN IP4 10.21.3.150
t=0 0
m=audio 7256 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
*Dec 2 09:17:12.758: //5168/5CDD005E81C5/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.21.3.150:5060;branch=z9hG4bK-d8754z-5d11c748ea412f19-1—d87
54z-;rport
From: "test test";tag=d201af51
To:
Date: Mon, 02 Dec 2013 09:17:12 GMT
Call-ID: NTczZWJiOWQxNmQ5MGIzMjAyNTRhMGRmODE4NjQ3NDk.
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
*Dec 2 09:17:12.758: //5169/5CDD005E81C5/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:1126@10.200.3.2:5060 SIP/2.0
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK1BB4E8C
Remote-Party-ID: "test test" ;party=calling;screen=no;priv
acy=off
From: "test test" ;tag=390844EC-199A
To:
Date: Mon, 02 Dec 2013 09:17:12 GMT
Call-ID: 5CE00D25-5A6911E3-81CB9B68-BC8F3581@10.21.3.151
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1557987422-1516835299-2177211240-3163501953
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIF
Y, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1385975832
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 212
v=0
o=CiscoSystemsSIP-GW-UserAgent 9086 8768 IN IP4 10.21.3.151
s=SIP Call
c=IN IP4 10.21.3.151
t=0 0
m=audio 17710 RTP/AVP 0 19
c=IN IP4 10.21.3.151
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
*Dec 2 09:17:12.766: //5169/5CDD005E81C5/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Date: Mon, 02 Dec 2013 09:05:06 GMT
From: "test test" ;tag=390844EC-199A
Allow-Events: presence
Content-Length: 0
To:
Call-ID: 5CE00D25-5A6911E3-81CB9B68-BC8F3581@10.21.3.151
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK1BB4E8C
CSeq: 101 INVITE
*Dec 2 09:17:12.766: //5169/5CDD005E81C5/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 404 Not Found
Reason: Q.850;cause=1
Date: Mon, 02 Dec 2013 09:05:06 GMT
From: "test test" ;tag=390844EC-199A
Allow-Events: presence
Content-Length: 0
To: ;tag=f604371e-74d5-421b-b364-4a75e2af6cdd-21271044
Call-ID: 5CE00D25-5A6911E3-81CB9B68-BC8F3581@10.21.3.151
Via: SIP/2.0/UDP 10.21.3.151:5060;branch=z9hG4bK1BB4E8C
CSeq: 101 INVITE
Добрый вечер,
В этом дебаге видно, что звонок до ССМ все же доходит, он пытается его обработать, однако отвечает сообщением 404 с каузой 1 (несуществующий номер).
Проверьте на сип-транке в ССМ, правильный ли на нем установлен СSS. Этот CSS должен содержать в себе партицию телефона 1126.
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/order_guide_c07_462222.html
2.1.1 Pay-as-You-Grow License
This type of license covers the right to use the feature as well as the maximum session count allowed. An example is the FL-CUBE-25 license, which allows up to 25 sessions.
Например, вот эти лицензии…
FL-CUBE-25= Unified Border Element Feature License – 25 Sessions
FL-CUBE-4= Unified Border Element Feature License – 4 Sessions
Здравствуйте.
Возникла следующая проблема. На данной циске (UC-520-16) настроен выход в ГТС через сип-транк. Все работает, но время от времени, при входящих звонках (по моим наблюдениям только с городских номеров) происходит ошибка при согласовании кодеков и, соответственно, шипение и треск, вместо нормальной связи. В дебаге видно, что несовпадают negotiated и preferred кодеки.
в voice class codec пришлось прописать только ulaw, так как при добавлении любых других кодеков вообще все звонки превращались в шипение и шум.
Но, как я понимаю, для правильной работы согласования кодеков, там должны быть прописаны желаемые кодеки?
P.S. Сама циска очень древняя, досталась мне, так сказать, трофейной. Версия CME вообще архаичная.
show telephony-service
CONFIG (Version=4.2(0))
Может быть в этом проблема? Есть возможность купить новую, но, опять же, не знаю какую выбрать (офис небольшой).
Заранее спасибо.
Добрый день,
Если бы кодеки не совпадали, то звонок бы вообще не проходил, был бы отбой. Подскажите, а такое наблюдается при звонках на IP-телефоны или на аналоговые? Если на аналоговые, то я рискну предположить, что у вас какая-то проблема с DSP (плата PVDM2), установленной в UC520.
Не думаю, что проблема лежит в версии СМЕ, хотя, конечно же, IOS нужно обновить, уж очень он старый. Возможно, что проблема уйдет вместе с обновлением IOS.
Спасибо за ответ.
Судя по наблюдениям, проблемы возникают только при звонках на городские телефоны.
Внутри организации, а так же при звонках, например, на мобильные телефоны, слышимость отличная.
А по логам видно, что, например:
6079258: #011 Stream type : voice+dtmf
6079259: #011 Media line : 1
6079260: #011 State : STREAM_ADDING (2)
6079261: #011 Callid : -1
6079262: #011 Negotiated Codec : g711alaw, bytes :160
6079263: #011 Nego. Codec payload : 8 (tx), 8 (rx)
6079264: #011 Negotiated DTMF relay : rtp-nte
6079265: #011 Negotiated NTE payload : 97 (tx), 97 (rx)
6079266: #011 Negotiated CN payload : 0
6079267: #011 Media Srce Addr/Port :
6079268: #011 Media Dest Addr/Port :
1 6079269:
6079270: *Dec 16 07:17:22.871: //119610/F12646A396FA/SIP/Info/sipSPIHandleInviteMedia:
6079271: Negotiated Codec : g711alaw, bytes :160
6079272: Preferred Codec : g729r8, bytes :20
6079273: Preferred DTMF relay 1 : 6
6079274: Preferred DTMF relay 2 : 0
6079275: Negotiated DTMF relay : 6
6079276: Preferred and Negotiated NTE payloads: 101 97
6079277: Preferred and Negotiated NSE payloads: 100 0
6079278: Preferred and Negotiated Modem Relay: 0 0
6079279: Preferred and Negotiated Modem Relay GwXid: 1 0
negotiated и preferred все таки не совпадают. хотя звонок прошел, хоть и с треском.
Здравствуйте,
Я думаю, что такая ситуация с preferred и negotiated кодеками вполне может быть. Например, если с вашей стороны на диал-пире для городского звонка по SIP установлен список кодеков (voice class codec). В этом списке первым по счету может стоять кодек G729, он и будет preferred, а вторым по счету – G711. Но на стороне прова, возможно, установлен лишь один кодек – G711. Поэтому, стороны договариваются о кодеке G711, который и обозначен как negotiated.
В voice class codec прописан только g711ulaw
Стоит прописать туда что то еще (alaw,G729), ситуация с треском проявляется при всех звонках. уже даже не знаю, куда копать…
Странная ситуация. Давайте посмотрим на дебаг debug voip ccapi inout при проблемном звонке. Необходимо понимать, какой диалпир выбирается в качестве исходящего, далее проверим его настройки.
А так получаются чудеса – в диалпире прописан 711мю, приоритетный кодек – 729,а по итогу выбирается g711a. Что-то совершенно необъяснимое… Вот и увидим, что происходит.
Добрый день!
помогите решить проблему, пожалуйста.
подключено от SIP-провайдера два тел.номера. Под каждый номер выданы отдельные регистрационные данные (логин и пароль). Если по вашей схеме настраивать каждый номер отдельно все работает.
пытаюсь настроить на одновременную работу оба номера, пример моего конфига:
sip-ua
credentials number 3517786355 username 3517786355 password xxxxxxxxx realm 81.90.208.30
credentials number 3517786354 username 3517786354 password yyyyyyyyy realm 81.90.208.30
registrar ipv4:81.90.208.30 expires 240
sip-server ipv4:81.90.208.30
Провайдер говорит что подключение видит, а вот запросы регистрации не приходят. Лог вот что пишет:
Feb 4 10:16:17.411: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:81.90.208.30:5060 SIP/2.0
Via: SIP/2.0/UDP 81.90.220.26:5060;branch=z9hG4bK6A1306
From: ;tag=5D6060-1DEC
To:
Date: Tue, 04 Feb 2014 10:16:17 GMT
Call-ID: ACE8129D-8CB411E3-8010A057-5C75DA15
User-Agent: Cisco-SIPGateway/IOS-15.3.3.M
Max-Forwards: 70
Timestamp: 1391508977
CSeq: 29 REGISTER
Contact:
Expires: 240
Supported: path
Content-Length: 0
Feb 4 10:16:17.411: //108/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 81.90.220.26:5060;branch=z9hG4bK6A1306;received=81.90.220.26
From: ;tag=5D6060-1DEC
To: ;tag=as423238e4
Call-ID: ACE8129D-8CB411E3-8010A057-5C75DA15
CSeq: 29 REGISTER
Server: Hypernet, LLC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="hypernet.ru", nonce="71574435"
Content-Length: 0
Feb 4 10:16:17.415: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:81.90.208.30:5060 SIP/2.0
Via: SIP/2.0/UDP 81.90.220.26:5060;branch=z9hG4bK6B20B6
From: ;tag=5D6064-2028
To:
Date: Tue, 04 Feb 2014 10:16:17 GMT
Call-ID: ACE8AF5E-8CB411E3-8011A057-5C75DA15
User-Agent: Cisco-SIPGateway/IOS-15.3.3.M
Max-Forwards: 70
Timestamp: 1391508977
CSeq: 29 REGISTER
Contact:
Expires: 240
Supported: path
Content-Length: 0
Feb 4 10:16:17.415: //109/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 81.90.220.26:5060;branch=z9hG4bK6B20B6;received=81.90.220.26
From: ;tag=5D6064-2028
To: ;tag=as357fb0e3
Call-ID: ACE8AF5E-8CB411E3-8011A057-5C75DA15
CSeq: 29 REGISTER
Server: Hypernet, LLC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="hypernet.ru", nonce="20e9f677"
Content-Length: 0
Добавлю, что если настраивать каждый номер отдельно через authentication то все работает корректно.
вместе два номера работать не хотят.
как этого добиться с credentials?
пробовал такой вариант
sip-ua
credentials number 3517786355 username 3517786355 password xxxxxxxxxx realm 81.90.208.30
credentials number 3517786354 username 3517786354 password yyyyyyyyyy realm 81.90.208.30
registrar 1 ipv4:81.90.208.30 expire 240
registrar 2 ipv4:81.90.208.30 expire 240
sip-server ipv4:81.90.208.30
Результат такой:
sh sip-ua register st
——————— Registrar-Index 1 ———————
Line peer expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
3517786354 -1 28 no normal
3517786355 -1 28 no normal
——————— Registrar-Index 2 ———————
Line peer expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
3517786354 -1 28 no normal
3517786355 -1 28 no normal
в остальном все по прежнему
Доброе утро, Сергей!
Запросы на регистрацию уходят, это видно в логе. Но! Посмотрите, что циска отправляет:
REGISTER sip:81.90.208.30:5060
В сообщении не содержится регистрируемого номера. Должно быть так:
REGISTER sip:3517786354@81.90.208.30:5060
Почему так происходит, пока не ясно. Не пробовали ли Вы прописать команду credentials без параметра number? т.е у вас сейчас вот так:
credentials number 3517786355 username 3517786355 password xxxxxxxxx realm 81.90.208.30
credentials number 3517786354 username 3517786354 password yyyyyyyyy realm 81.90.208.30
А какой результат будет, если сделать так, как у меня описано:
credentials username 00044847 password ciscolab realm sip.telphin.com?
Для вашего случая:
credentials username 3517786355 password xxxxxxxxx realm 81.90.208.30
credentials username 3517786354 password yyyyyyyyy realm 81.90.208.30
попробовал. результат тот же:
Feb 5 10:21:37.172: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:81.90.208.30:5060 SIP/2.0
Via: SIP/2.0/UDP 81.90.220.26:5060;branch=z9hG4bK25B33C
From: ;tag=8B0F68-D6F
To:
Date: Wed, 05 Feb 2014 10:21:37 GMT
Call-ID: 2119E539-8D8611E3-803AFD49-D22BF0F5
User-Agent: Cisco-SIPGateway/IOS-15.3.3.M
Max-Forwards: 70
Timestamp: 1391595697
CSeq: 2 REGISTER
Contact:
Expires: 240
Supported: path
Content-Length: 0
Попробуйте поменять realm: вместо айпишника укажите имя hypernet.ru. Такой realm значится в ответах 401 от прова. Наличие DNS в топологии необязательно (только не ставьте hypernet.ru в командax registrar и sip-server, если у вас нет DNS)
Напишите, пожалуйста, помогло или нет. Конфиг с двумя строками credentials для одного и того же realm вполне работоспособен. Об этот написано тут:
http://www.cisco.com/en/US/docs/ios-xml/ios/voice/sip/configuration/15-mt/voi-sip-multi-trunks.html#GUID-66487B02-0EBC-4298-B9D4-392BDD5D1559
Приведу из этого документа выдержку:
Router> enable
Router# configure terminal
Router(config)# sip-ua
Router(config-sip-ua)# credentials number 1111 username MyUsername password MyPassword realm Realm.example1.com
Router(config-sip-ua)# credentials number 1111 username MyUsername2 password MyOtherPassword realm AnotherRealm.example1.com
Router(config-sip-ua)# credentials number 2222 username TheirUsername password TheirPassword realm Realm.example1.com
Router(config-sip-ua)# credentials number 2222 username TheirUsername2 password TheirOtherPassword realm AnotherRealm.example1.com
Router(config-sip-ua)# registrar 1 dns:example1.com expires 180
Router(config-sip-ua)# registrar 2 dns:example2.com expires 360
Как видите, номера 1111 и 2222 регистрируются на одном и том же realm. Значит, должно и у вас работать. Правда, не исключен баг IOS, но проверить это можно только опытным путем, т.е. сменив IOS на другой.
А можно вопрос почти в тему?
У меня задача: привязать 8 SIP абонентов к 8 исходящим FXO портам, каждый к своему.
Практически схема "проброса номеров" от аналоговой АТС.
Проброс входящих понятно:
!
voice-port 0/0/0
connection plar 125
!
А вот как заставить выбирать нужный порт при ИСХОДЯЩЕМ звонке, если destination-pattern на всех диалпирах одинаковый?
Вот такое по answer-address не срабатывает
!
dial-peer voice 125 pots
description ats 1xx
answer-address 125
destination-pattern 1..
port 0/0/0
forward-digits 3
!
что пишу answer-address что не пишу – диалпир все равно выбирается случайным образом из восьми аналогичных.
Доброе утро, Сергей!
Критерий answer-addres не работает при выборе ИСХОДЯЩЕГО диал-пира. Он применяется только для выбора ВХОДЯЩЕГО диал-пира.
Вашу задачу можно решить путем использования COR-листов. С их помощью можно разрешить или запретить доступ на тот или иной диал-пир. Вот и получится (при правильной их настройке, конечно), что телефон будет занимать при исходящем звонке нужный диал-пир, и, соответственно, нужный FXO-порт.
Спасибо за указание направления – часто именно этого не хватает, как Вы несомненно знаете 🙂
Вот незадача только – нашёл букварь
http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a008019d649.shtml
делаю по нему и сразу же после создания тегов и листов напарываюсь, что в SIPовских voice register dn нету слова cor !
Как из этого выпутаться? стандартный приём с заворачиванием вызова на loopback и превращение его во входящий voip?
Извиняюсь. нашёл. Оказывается для SIP оно в voice register pool находится.
Вы были правы! изменил Realm и все заработало!
Это, я как понимаю, параметр вообще не зависит от IP или DNS-имени sip-сервера (как я думал). потому как dns-имя сервера в моем случае pbx.hypernet.ru
Благодарю за помощь!
Пожалуйста! 🙂
Рад, что все заработало.
Так… исходящие звонки поборол, теперь нарисовалась проблема со входящими.
Оказывается, при конфигурации проброса
!
voice-port 0/0/0
connection plar 125
!
циска сразу при поступлении вызова на порт ПОДНИМАЕТ ТРУБКУ на этом порту, и дальше выдаёт свои сигналы КПВ и отбоя. Вот только проблема – если абонент не ответил и вызывающий абонент положил трубку, то циска не освободит порт и будет названивать внутреннему абоненту пока не истечёт таймаут.
Можно ли как-то заставить циску в такой конфигурации не снимать трубку на FXO порту, пока не поднимет трубку вызываемый абонент?
Я бы попробовал настроить так:
voice-port 0/0/0
connection plar opx 125
А вообще, отбой на FXO, когда абонент удаленной АТС положил трубу – это известный головняк (и не только Cisco, но и других АТС с портами FXO или, как их еще называют, Universal Trunk). Отчасти побороть это можно с помощью функции Busy Tone Detection (BTD), но это не всегда спасает.
Думаю, сильно помогло бы изменение логики работы – чтобы циска не поднимала трубку на порту FXO, пока не поднимет трубку вызываемый абонент.
Так по идее, когда настроен параметр opx (т.е connection plar opx 125), то трубка циской не снимается, пока не ответит абонент. Разве не так?
А можно ещё вопрос для случая с SIP телефонами и их привязкой к FXO портам?
Наметилась проблема, что при отсутствии какого-то SIP телефона в сети вызов, поступающий на FXO порт, тут же маршрутизируется циской, не находящей этот номер, на другой FXO порт.
Пример: SIP телефоны имеют номера 125-132. Соответственно на FXO портах прописано "connection plar 125" и далее до 132. Но если SIP телефона не оказывается в сети, то циска отправляет вызов по FXO порту обратно в АТС, поскольку на портах destination-pattern 1..
Пока придумал только, что SIP телефоны надо вынести за пределы нумерации АТС, скажем сделать в циске 4-значную нумерацию или 2.., а разруливать опять диал-пирами. Так?
Доброе утро, Сергей. Извините за задержку с ответом. Не до блога было в последние дни, если честно.
При такой конфигурации, как Вы описали, циска работает совершенно правильно. Так и должно быть. Попробуйте сделать вот что:
voice register dn 1
number 125
huntstop
По идее, такая конфига должна предотвратить переход звонка в диал-пир с пересекающейся нумерацией.
Хотя, конечно, лучше избегать таких пересекающихся номерных планов и дать ип-телефонам отдельную нумерацию (2хх, 3хх итп).
И ещё непонятный глюк: я использовал два FXS порта для проброса удалённой внешней линии на аналоговую АТС.
В посёлке, где стоит удалённый voip шлюз на cisco 1760, нумерация 5-значная, и импульсный набор, поэтому connection plar для исходящего соединения не работает – в таком режиме нет импульсного донабора в посёлок. Пришлось принимать номер на циску, маршрутизить звонки диалпирами, чтобы на выходе циска донабирала городской номер сама. Всё работало, пока не захотел привязать исходящую линии АТС к исходящегму порту на дальнем конце. Пошёл стандартным путём: translate rule на порту с приписыванием спереди одной цифры (6 или 7), затем маршрутизация на нужный порт диалпиром с паттерном 6….. или 7….. и обрезка 5 передаваемых цифр.
Так вот, тут почему-то на входе FXS перестал приниматься длинный номер, а стал отбиваться после второй (!) цифры. Почему именно второй – я так и не понял, все внутренние номера и паттерны трехзначные.
Если честно, то я пока не понял саму задачу 🙁 Неплохо бы от Вас получить картинку с описанием. Ну и конфиги, естественно (или куски конфигов). Потому, что я пока не совсем понимаю, о каких донаборах идет речь 🙁
Пришлите мне, пожалуйста, через форму связи свой мейл, я Вам отвечу, а потом уже через почту пришлете картинки.
Дмитрий добрый день!
Имеется следующая конфигурация
Ростелеком (Неофон SIP) – R2911 (CUBE) – CUCM 7.1.5
Исходящие звонки работают без проблем, а на входящем получаю
фаст бизи и SIP/2.0 500 Internal Server Error в дебаге.
voice service voip
allow-connections sip to sip
redirect ip2ip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none
sip
!
voice class codec 2
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
codec preference 4 g729br8
!
interface GigabitEthernet0/0
ip address 10.73.13.2 255.255.255.0
duplex auto
speed auto
!
!
interface GigabitEthernet0/2
ip address 212.20.63.125 255.255.255.248
duplex auto
speed auto
!
dial-peer voice 8 voip
description To_SIP_Provider
destination-pattern 8923…….
session protocol sipv2
session target sip-server
voice-class codec 2
no voice-class sip outbound-proxy
dtmf-relay rtp-nte
no vad
!
dial-peer voice 3 voip
description To_CUCM
destination-pattern 2689601
session protocol sipv2
session target ipv4:10.73.12.2
incoming called-number .
voice-class codec 2
voice-class sip early-offer forced
!
!
sip-ua
credentials username gazprom-neft password 7 ххххххх realm chel.media.usi.ru
authentication username gazprom-neft password 7 ххххххх
authentication username gazprom-neft password 7 ххххххх realm chel.media.usi.ru
no remote-party-id
registrar dns:chel.media.usi.ru expires 3600
sip-server dns:chel.media.usi.ru
connection-reuse
Received:
INVITE sip:gazprom-neft@212.20.63.125:5060;maddr=212.20.63.125 SIP/2.0
From: ;tag=-45026-3c4e6e5-5b3bab44-3c4e6e5
To: "gazprom-neft gazprom-neft"
Call-ID: bbf1baee44c171e920e85ea766ef869e296fc4@62.148.237.132
CSeq: 1 INVITE
Via: SIP/2.0/UDP 62.148.237.132:5060;branch=z9hG4bK-4808856-961491e7-3df48dc6
content-type: application/sdp
contact:
user-agent: CS2000_NGSS/9.0
max-forwards: 64
supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join
remote-party-id: ;screen=yes;party=calling;privacy=off
allow: ACK,REFER
allow: BYE
allow: CANCEL
allow: INVITE
allow: OPTIONS
allow: INFO
allow: SUBSCRIBE
allow: REFER
allow: NOTIFY
allow: PRACK
allow: UPDATE
x-nt-corr-id: 7bf1baee44421e7320e85e3483dab97a950456@62.148.237.132
x-nt-location: 193624
privacy: none
Content-Length: 234
v=0
o=PVG 1395571359140 1395571359140 IN IP4 62.148.237.194
s=-
p=+1 6135555555
t=0 0
m=audio 47256 RTP/AVP 8 18 101
c=IN IP4 62.148.237.194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=yes
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 62.148.237.132:5060;branch=z9hG4bK-4808856-961491e7-3df48dc6
From: ;tag=-45026-3c4e6e5-5b3bab44-3c4e6e5
To: "gazprom-neft gazprom-neft"
Date: Sun, 23 Mar 2014 11:19:56 GMT
Call-ID: bbf1baee44c171e920e85ea766ef869e296fc4@62.148.237.132
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Sent:
SIP/2.0 500 Internal Server Error
Via: SIP/2.0/UDP 62.148.237.132:5060;branch=z9hG4bK-4808856-961491e7-3df48dc6
From: ;tag=-45026-3c4e6e5-5b3bab44-3c4e6e5
To: "gazprom-neft gazprom-neft";tag=D53625C0-990
Date: Sun, 23 Mar 2014 11:19:56 GMT
Call-ID: bbf1baee44c171e920e85ea766ef869e296fc4@62.148.237.132
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=16
Content-Length: 0
Добрый день, Евгений!
Я так думаю, что "фаст-бизи" Вы слышите потому, что в INVITE приходит звонок не на телефонный номер, а на имя:
INVITE sip:gazprom-neft@212.20.63.125:5060
Шлюз не умеет обрабатывать входящие звонки по именам. 🙁 Нужно, чтобы пров слал входящий звонок на телефонный номер, если это возможно.
Единственное, что тут могу посоветовать – это попробовать поисследовать тему подмены заголовков SIP. Т.е заменить имя в инвайте на один из номеров циски. Я совершенно точно знаю, что подмена заголовков возможна в исходящих (от циски) сообщениях SIP.
Но вот можно ли сделать подмену заголовков во входящих сообщениях SIP, я ответить пока затрудняюсь/ Давненько это делал, и на память просто не помню.
Погуглите на эту тему, например, о voice class sip или sip header change cisco.
Если найдете решение, буду рад о нем узнать, поэтому, был бы благодарен за обратную связь.
У меня аналогичная, проблема.
SIP-(prov s reg) – R2921 (CUBE) – Asterisk(bez-reg)
Заметила у себя ту же штуку с буквами, попросила провайдера заменить буквы на цифры в username, – ничего не изменилось. Исходящие летают без проблем. Входящие – отказ.
Получаю отказ SIP/2.0 403 Forbidden
Циска отказывается пропускать входящий звонок в транк без регистрации.
Кстати можете уточнить, что означает "number" в настройках credentials?
credentials number XXXXX username user1 password pw1 realm a.b.c.d
Провайдер сказал когда я пыталась вписать number что циска начала его использовать для регистрации вместо username – когда я его добавила, почему?
Здравствуйте, Вас не Екатерина, случайно, зовут? Вы не писали мне через форму связи?
Если да, то я не забыл о Вашем вопросе. Я сегодня разговаривал с инженером Cisco TAC. Он мне сказал, что вроде как в новых релизах Cisco IOS появилась возможность принимать звонки и по именам тоже.
Сегодня вечером я разберусь, как это сделать и опишу/дам ссылки на материал.
По поводу параметра number – шлюз, действительно, будет использовать его для регистрации. Думаю, что в этом случае используется такая же схема регистрации, как и для SIP- телефона. Т.е номер, имя пользователя и пароль.
По такому же принципу на СМЕ/ССМ регятся сип-телефоны стороннего вендора (не циско)
По поводу 403 Forbidden – пришлите, пожалуйста, debug ccsip messages. Я хочу понимать, отправляет ли шлюз звонок на ССМ или нет.
Да, это я.
лог:
Mar 25 11:38:13.577: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:5946494@10.46.0.26:5060 SIP/2.0
Via: SIP/2.0/UDP 10.46.0.25:5060;branch=z9hG4bK2e290927;rport
Max-Forwards: 70
From: "675505222" ;tag=as65b918f0
To:
Contact:
Call-ID: 1d3e4d9a469de4d2624b8d5c04a8b37d@10.46.0.25:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 10.12.3
Date: Tue, 25 Mar 2014 11:38:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 279
v=0
o=root 1655676377 1655676377 IN IP4 10.46.0.25
s=Asterisk PBX 10.12.3
c=IN IP4 10.46.0.25
t=0 0
m=audio 18938 RTP/AVP 8 3 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
Mar 25 11:38:13.581: //66274/C899945D8DCF/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.46.0.25:5060;branch=z9hG4bK2e290927;rport
From: "675505222" ;tag=as65b918f0
To:
Date: Tue, 25 Mar 2014 11:38:13 GMT
Call-ID: 1d3e4d9a469de4d2624b8d5c04a8b37d@10.46.0.25:5060
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Content-Length: 0
Mar 25 11:38:13.581: //66274/C899945D8DCF/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.46.0.25:5060;branch=z9hG4bK2e290927;rport
From: "675505222" ;tag=as65b918f0
To: ;tag=22A4CD3C-1AFE
Date: Tue, 25 Mar 2014 11:38:13 GMT
Call-ID: 1d3e4d9a469de4d2624b8d5c04a8b37d@10.46.0.25:5060
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Reason: Q.850;cause=21
Content-Length: 0
Mar 25 11:38:13.761: //66274/C899945D8DCF/SIP/Msg/ccsipDisplayMsg:
Sent: SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.46.0.25:5060;branch=z9hG4bK2e290927;rport
From: "675505222" ;tag=as65b918f0
To: ;tag=22A4CD3C-1AFE
Date: Tue, 25 Mar 2014 11:38:13 GMT
Call-ID: 1d3e4d9a469de4d2624b8d5c04a8b37d@10.46.0.25:5060
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Reason: Q.850;cause=21
Content-Length: 0
Mar 25 11:38:14.653: //66274/C899945D8DCF/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.46.0.25:5060;branch=z9hG4bK2e290927;rport
From: "675505222" ;tag=as65b918f0
To: ;tag=22A4CD3C-1AFE
Date: Tue, 25 Mar 2014 11:38:13 GMT
Call-ID: 1d3e4d9a469de4d2624b8d5c04a8b37d@10.46.0.25:5060
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Reason: Q.850;cause=21
Content-Length: 0
Mar 25 11:38:14.661: //66274/C899945D8DCF/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.46.0.25:5060;branch=z9hG4bK2e290927;rport
From: "675505222" ;tag=as65b918f0
To: ;tag=22A4CD3C-1AFE
Date: Tue, 25 Mar 2014 11:38:13 GMT
Call-ID: 1d3e4d9a469de4d2624b8d5c04a8b37d@10.46.0.25:5060
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Reason: Q.850;cause=21
Content-Length: 0
По дебагу вижу, что шлюз звонок далее на ССМ не отправляет (нет второго инвайта в сторону ССМ). Поэтому, в первую очередь следует проверить следующее:
voice service voip
allow-connections sip to sip
Сконфигурировано ли это на шлюзе?
Конечно.
voice service voip
allow-connections sip to sip
redirect ip2ip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
rel1xx disable
min-se 180 session-expires 180
header-passing
error-passthru
asserted-id pai
privacy pstn
no update-callerid
midcall-signaling passthru
privacy-policy passthru
у меня через CUBE звонки работают, с другим провайдером, с Октелл, MS Lync и Asterisk, НО все эти транки без регистрации.
А тут возникла необходимость перенести транк, который с регистрацией и раньше приходил через 3750 в обход CUBE прямо в КЦ и этот единственный с регистрацией – не пропускает входящие ни в один из имеющихся транков без регистрации…
Я не думаю, что дело тут в регистрации. Шлюзы циско прекрасно пропускают входящие звонки и без регистрации. К тому же, если смотреть со стороны провайдера, его транк тоже не зарегистрированный.
Проблема может быть еще вот в чем. Начиная с релиза 15.0 шлюзы циско перестали по дефолту пропускать звонки с неизвестных айпи-адресов. Сделано это для того, чтобы избежать воровства трафика.
В связи с этим, вопрос следующий – прописан ли айпишник прова в ip trusted list?
Здравствуйте, Дмитрий. Слушал в Incom-е Ваш курс по CIPT-1, очень помогает, можно у Вас проконсультироваться по следующему вопросу:
Есть у нас подключение по SIP от Datagroup, несколько номеров регистрируются в одном транке с логином, например, 7021001.
Номера мапятся по последним 4-м цифрам во внутренние номера, например, 7021002 в 1002, 7021003 в 1003 и так далее с помощью Translation Profile.
Проблема вот в чем: при звонке на номер 7021002 в SIP в поле To: номер правильный, 7021002, а вот в Invite указан номер 7021001, соответственно вызов транслируется в 1001.
В инете пишут, что согласно RFC 3261, Request-URI должен совпадать с полем To, но в датагрупе нам сказали, что не могут эту проблему поправить. Я попробовал использовать sip-profile для копирования номера из To в Invite, как описано здесь:
http://tblog.cisco.be/2011/02/17/cube-conditional-sip-profiles/
voice class sip-profiles 1
request INVITE peer-header sip TO copy “sip:(.*)@” u01
request INVITE sip-header SIP-Req-URI modify “.*@(.*)” “INVITE sip:u01@1″
но чуда не произошло.
Здравствуйте,
Подмена заголовков вообще сложная тема, каждый сценарий нужно проверять. На данный момент я затрудняюсь сразу дать точный ответ, к сожалению . Попробую при случае смоделировать это в лабе, но ранее следующей недели сделать это не смогу, потому как нахожусь в Москве на курсах.
Вообще, идея, описанная в приведенной Вами ссылке, правильная. Важно только правильно применить сип-профиль. Он должен быть установлен на ИСХОДЯЩЕМ диал-пире, который отправляет звонки со шлюза на ССМ.
Доброго дня!
У меня такая проблема.
CUCM 8.6 (192.168.0.101) – SW – R1 – (NAT – 192.168.101-10.10.10.10) – SIP провайдер.
На аппарате айпи 192.168.1.2. Звоню через SIP провайдера. Сигнальный трафик натится нормально, но голосовой трафик идет от айпи 192.168.1.2 и поэтому голос не проходит.
Можно ли как-нибудь сделать так, чтобы RTP трафик шел через CUCM и соответственно NAT отрабатывал по айпи 192.168.0.101?
Здравствуйте!
А смысл делать так? Только, чтобы голосовой трафик "натился" тоже? Ну попробуйте включить в настройках SIP-транка галку MTP Required (см. о ее назначении в моем основном посте). Тогда голосовой трафик пойдет через ССМ, но это не решит проблему, я думаю, потому как в SDP будет все равно фигурировать адрес 192й сетки.
CUBE как раз и призван решать подобные проблемы с НАТ.
Я бы и сам на стенде попробовал собрать, а чем можно смоделировать такое поведение SIP-провайдера, чтобы подставить нужные поля в нужные заголовки SIP? asterisk-ом ?
Я не имел ввиду смоделировать именно поведение сип-провайдера. Я подразумевал именно проверить порядок подмены sip-заголовков. Насколько я помню и понимаю, это работает только на исходящем диалпире.
Если разобраться с подменой заголовков, тогда эта задача решаема.
Перегрузил MTP в Media resources и все заработало.
Теперь вопрос в другом, почему он вылетел? Проработал полгода и подвис.
Думаю, что ответ тут такой же, как и по всему остальному софту. 🙂 Такой же, как например, ответ на вопрос: "Почему завис Windows?"
А как быть если провайдер выдал 10 номеров и каждый номер требует отдельной регистрации и еще при совершении звонка требует проверку аутефикации?
Добрый день, Иван!
В этом случае в настройках sip-ua прописываете 10 строк credentials и 10 строк authentication (см. пример в статье). Тогда все 10 номеров будут регистрироваться и аутентифицироваться при звонке.
Здравствуйте.
Есть cucm 9.1.2, 2 телефона cisco, с номерами 1111 и 1112. Между собой звонят, все ок. Зацепил SIP-транк на CUBE 3925, хочется, чтобы можно было звонить с нашей атс через 3925 на CUCM и обратно. С IP-телефонов на нашу АТС звонки идут, а вот обратно – нет. АТС отправляет звонок через H323 на 3925.
Вот такое в логах:
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103384: From: "iPECS-LIK VOIP" ;tag=8B1121C8-723
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103385: To: sip:1112@10.100.20.19 – IP адрес сервера CUCM
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103386: Date: Mon, 19 May 2014 08:17:10 GMT
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103387: Call-ID: CEFB03FD-DE6411E3-B37FE565-183DC847@10.100.20.9
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103388: CSeq: 101 INVITE
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103389: Allow-Events: presence
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103390: Content-Length: 0
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103391:
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103392: May 19 08:17:10.197: //2053279/9F31CAE002FD/SIP/Msg/ccsipDisplayMsg:
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103393: Received:
2014-05-19 15:17:10 Local7.Debug 172.30.255.8 85103394: SIP/2.0 404 Not Found
На cube сделал такой dial-peer
dial-peer voice 91112 voip
description To_CUCM2
translation-profile outgoing 63
huntstop
destination-pattern 91112$
session protocol sipv2
session target ipv4:10.100.20.19
codec g711alaw
Т.е. на своем телефоне набираю 91112, он попадает под этот диал-пир, отрезается 9 и отправляется в CUCM.
Подскажите, пожалуйста. Что-то не могу найти косяк. Проверил несколько раз CSS, partition. Везде одна, мною созданная, partition и CSS. Они используются и для DN и для Route pattern, т.е. все должно работать…
Добрый день,
скорее всего неправильный CSS установлен в SIP-транке. Проверьте его, пожалуйста. Входящие звонки приходят с транка, далее попадают в таблицу маршрутизации, поэтому CSS транка очень важен.
Вопрос, а если номеров более 100, то АОН менять только на CUCM ? Ибо на шлюзе ограничение в 100 правил по трансляции…
Или есть другие варианты ?
Менять АОН можно и на CUCM, и на шлюзах. Что касается шлюзов:100 правил (vocie translation-rule) – это не так уж и мало. Ведь в каждом правиле можно написать до 15 формул преобразования (rule), а это уже до 1500 преобразований.
Можно АОН менять и в CUCM (External Phone Number Mask в настройках телефона, Calling Party Transformation Pattern и Calling Party Transformation CSS в настройках шлюза).
А если провайдер все же работает "не честно" и городские номера передает как National (ну то есть с кодом города). Можно ли как то отрезать код города?
Да, конечно можно, почему нет. Трансляциями это делается. Если шлюз SIP, то легче всего это сделать на самом шлюзе.
Пердположим, что вы живете, скажем, в С-Петербурге. Тогда при городских звонках провайдер вам будет слать CLID 812-ХХХХХХХ. Пишем правило трансляции на шлюзе:
voice translation-rule 1
rule 1 /^812/ //
Код города отрезается. Далее, как обычно, создаете voice translation-profile и применяете его на входящем диал-пире или на voice port.
У меня такая проблема… вернее Две… Есть SIP транк с Cisco // Далее E1 поток до оператора… Как правильно настроить VOIP параметры на Cisco для транзитивного передачи сигнализации, а также в случае исчерпания тайм-слотов на cisco/// у меня астериск получает сбой вызова…
Есть такая проблема… как передать транзитом ( (скорее как правильно настроить global vop параметры со стороны cisco sip peer) в случае если на e1 кончились таймслоты (емкость) .. на астериске идет сбой вызова… как правильно передавать сигнализацию со стороны Cisco?
Добрый день, Андрей! Я, если честно, не совсем понимаю вашу задачу. На вашем е1 заняты все тайм-слоты, и Вам нужно какой-то особый сигнал слать в сторону Астериска? Речь идет о какой-то специфичной call disconnect cause?
Распишите, пожалуйста, свою проблему детальнее. Очень мало информации, чтобы сказать что-то определенное.
Добрый день, Дмитрий,
у меня похожая задачка, только у меня всего 2 номера и 2 логина/пароля.
Нельзя написать 10 строк authentication для одного и того-же realm… Перезаписывает поверх.
Номера регистрируются. Входящая связь работает. А вот исходящая работает только с тем АОН, для которого прописана строка authentication.
А задача выпускать вызовы с одного телефона с одним АОН, а с другого – с другим.
Добрый день, Иван! Да, действительно, для одного и того же realm не получается написать 10 строк authentication.
Что, если попробовать обойтись вообще без команды authentication? По идее, шлюз в этом случае будет использовать параметры команды credentials (если я правильно понял вот этот документ: http://www.cisco.com/c/en/us/td/docs/ios/voice/sip/configuration/guide/15_1/sip_15_1_book/sip_cg-multi-registrars.html)
Добрый день Дмитрий! посещал ваш курс TVOICE в Микротесте в прошлом году. Знания полученные на курсе очень помогают, спасибо!
такой вопрос: в вашем примере указано что шлюз должен отправлять звонки на sip.telphin.com. как он узнает адрес? параметры DNS должны быть где-то прописаны или нет?
что-то я упустил этот момент.
Добрый день, Андрей!
На моем шлюзе был прописан адрес DNS. Без этого, конечно же, по доменному адресу никак не достучаться. Для экспериментов вполне подойдет Google DNS (8.8.8.8).
Или, как вариант, на интерфейсе, смотрящем в интернет, можно прописать ip address dhcp. Тогда автоматически получите и адрес, и dns.
Спасибо за ответ. можете написать, как на шлюзе в ручную указать dns?
ip name-server
http://www.cisco.com/c/en/us/support/docs/ip/domain-name-system-dns/24182-reversedns.html
Дмитрий, добрый день!
Можно ли зарегистрировать SIP от провайдера на CUCM c аутентификацией? Или без CUBE никак?
Спасибо!
Добрый день, я не совсем понял вопрос. Зарегистрировать транк на CUCM? Правильно?
Если да, то теоретически SIP-устройство можно зарегистрировать на CUCM как терминал, т.е. как телефон (SIP 3rd Party Phone). Оно должно уметь передавать, как и телефон, DN, Username, Password.
Не знаю, удалось ли мне ответить на ваш вопрос…
Подключение нового телефона к CUCM. Connect phone to the CUCM.
https://www.youtube.com/watch?v=rA-ipF_bdU0
4 дня уже трахаюсь, никак не могу победить Warning: 399 LABCUCM "Unable to find a device handler for the request received on port 56983 from 192.168.44.100" . Причем это с CUBE в сторону CUCM. А с CUCM на CUBE вообще тишина в дебаге. Может версия другая и еще что то надо добавить у меня 9.1? За 3 года работы с VOIP я подключал десятки SIP провайдеров на десятки различных устройств, чего я только и куда только не подключал, но вот такого ада я еще не помню. ЧЕТЫРЕ ДНЯ это же сума сойти надо. Я 4 дня на Addpack то не тратил когда его впервые увидел GSM SIP FXO/FXS все на нем настроил 7 линий. А тут как об стену долблюсь. Балдею просто.
Такое сообщение возникает, обычно, при ситуации, когда звонок идет с неизвестного IP. Пришлите мне, пожалуйста, через форму связи ваш адрес почты. Я отвечу, и на мой ящик нужно будет выслать конфигурации шлюза и скриншот конфигурации сип-транка.
Доброго времени суток. Прошу совета. Есть телефония на Elastix (абоненты – elastix – voip провайдер). Принесли cisco 1751-V и 10 телефонов cisco 7941 и 7911. Вижу всё это как: 7941-7911 > cisco 1751-v > elastix > voip провайдер. Как всё это связать? Спасибо)))
Скажите, чем была решена проблема?
Здравствуйте Дмитрий! Вот нашел Ваш блог и решил попробовать написать о своей проблеме интеграции CUBE. У меня CCNP RS, но в VOIP новичек. Руководство поставило задачу заменить телефонию на астере решением CUCM-CUBE. На данный момент, благодаря вашему блогу мне удалось на виртуальном CSR1000v поднять CUBE, зарегистрировать его в сети провайдера, настроить 2 диал пира (один в сторону провайдера, второй в сторону тестовой АТС, пока это астер). Транк между CUBE и астером поднялся. Исходящие звонки пошли. Но вот с входящими никак, я уже настраивал третий диал пир, но ситуация не изменилась. Через debug ccsip messages я вижу как провайдер присылает sip invite, но cube ничего с ним не делает, не ругается, не перенаправляет.. в дебаге есть только received.
Вот это сообщение:
Received:
INVITE sip:СИПАЙДИ@10.220.16.163:5060 SIP/2.0
Via: SIP/2.0/UDP 212.53.40.40:5060;branch=z9hG4bK296258-kmbdctr;cgp=etc.tario.ru;rport
Record-Route: sip:212.53.40.40:5060;lr
Record-Route: sip:c192.168.40.79.rev.9424128.call.cgatepro;lr
Max-Forwards: 67
From: sip:+номер звонящего@sipnet.ru;tag=BC7B7353-359978-A5D9C2DC_kmbdctr-A4C4
To: sip:СИПАЙДИ@sipnet.ru
Call-ID: IWF-kamN7ptOOEeQrJnE8J3PHk14dLdd6b@trusted
Contact: sip:signode-359978-A5D9C2DC_kmbdctr-A4C4@212.53.40.40
CSeq: 1 INVITE
Expires: 120
Supported: timer,replaces,histinfo,precondition
Allow: INVITE,OPTIONS,INFO,MESSAGE,PRACK,UPDATE,REFER
Remote-Party-Id: sip:+номер звонящего@sipnet.ru ;party=calling;privacy=off;screen=yes
Remote-Party-Id: tel:8набранный номер;id-type=subscriber;party=redirecting;screen=yes
User-Agent: CommuniGatePro-callLeg/6.1.16
Content-Type: application/sdp
Content-Length: 335
Подскажите в чем может быть "затык"? Диал пир в сторону астера с destination-pattern СИПАЙДИ.
И еще второй вопрос, зачем вообще нужен CUBE, вроде последние версии CUCM уже поддерживают авторизацию у провайдера(поправьте если не прав), да и за натом работать могут, в чем его необходимость вообще?
Спасибо!
Добрый день, скажите пожалуйста на виртуальном CUBE можно ли поднять полноценные возможности CUBE. Поднял виртуальный CUBE, за ним астер, а перед ним ISP, заработали вход и исход звонки с провайдером, но качество ужасное. Вот теперь думаю в чем может быть проблема…
Добрый день, как я понимаю, проблему со входящими звонками Вы уже решили. О виртуальном CUBE не подскажу ничего, к сожалению, не разворачивал никогда. Можно, конечно, попробовать включить режим media flow around (это когда RTP ходит мимо CUBE напрямую между участниками разговора). Однако, могут возникнуть некоторые проблемы, связанные с маршрутизацией трафика и имеющейся адресацией, а также вы должны понимать, что в этом случае возникает проблема с безопасностью, так как будет прямой доступ в вашу сеть извне.
Добрый день!
Возникает проблема, что sip-ua в принципе не регистрируется.
Дебаг показывает, что отправил пакет к провайдеру, но ответа не получил.
Подскажите с чем может быть связана данная проблема?
Добрый день! А вы сможете подсказать как настроить, чтобы SIP INVITE вылетал уже с данные авторизации?
Здравствуйте! Спасибо за прекрасную статью, очень давно читаю ваш блог!
Но вот возникла проблема и не могу понять, что я делаю неправильно. У меня есть CUBE и CUCM, между ними настроен sip-trunk. В CUCM настроены RouteGroup, RouteList, Route pattern, translation pattern, созданы DN и зарегистрированы телефоны.
От провайдера приходит номер 4951234567, на CUCM создан route pattern 4951234567 и Calling Party Transform Mask указан 4951234567, создан translation pattern 4951234567 и в нем Called Party Transform Mask указан 1225.
На CUBE создаю dial-peer:
dial-peer voice 1 voip
description ==From IPS==
destination-pattern 8……….
session target ipv4:1.1.1.1
voice-class codec 1
dtmf-relay rtp-nte
no vad
dial-peer voice 2 voip
description ==To CUCM==
destination-pattern 4951234567
session protocol sipv2
session target ipv4:10.11.4.7
voice-class codec 1
dtmf-relay rtp-nte
no vad
Теоретически должно работать, но звонок не ходит.
Подскажите, где я ошибся?