Здравствуйте!
Многих из наших читателей очень интересует вопрос подключения CUCM к провайдеру телефонных услуг с помощью SIP-транка. Тема эта очень актуальная, так как все больше провайдеров предлагают, помимо традиционного подключения по потоку Е1, еще и подключение к своей сети по протоколу SIP. Данный пост затронет базовые настройки подключения по SIP (т.е без настройки передачи DTMF, факсов, трансферов и т.п.).
Итак, начнем. Прежде всего, разберемся с топологией, которую нам предстоит настроить. Она показана на следующем рисунке. Тестировать подключение по SIP-транку будем на CUCM 8.0, в качестве CUBE используем роутер 2811 с IOS 12.4.24T.
Подключать лабораторный CUCM будем к провайдеру TelMe (http://tel-me.ru). Провайдер предоставил нам для подключения один номер 00044847. Параметры подключения к сети провайдера следующие:
Сначала настраиваем SIP-транк на CUCM. Как обычно, процесс проиллюстрирую скриншотами. Заходим в ССМ Administration, далее Device->Trunk->Add New и добавляем новый SIP-транк. Указываем имя, Description, Device Pool, а также не забываем поставить галочку MTP-Required. Она необходима прежде всего для того, чтобы включить режим сигнализации SIP Early Offer, а также решает множество дополнительных проблем (при передаче DTMF, при переводах звонка, при конвертации alaw/ulaw). Не забудьте, что для этой включенной галочки в системе уже должны быть настроенные и зарегистрированные МТР:
Далее в настройках транка указываем IP-адрес CUBE (в нашем примере это 10.10.100.11, обычно это адрес, к которому на шлюзе осуществлена "привязка" сигнализации" SIP - команда bind). Также выбираем для транка Destination Port (для CUBE можем использовать стандартный 5060), SIP Security Profile и SIP Profile (профили взяты дефолтные, однако, в зависимости от условий, может потребоваться корректировка их параметров).
Для исходящих звонков настраиваем Route Pattern. Проверку исходящих звонков будем осуществлять при помощи звонка на SIP-терминал, зарегистрированный в той же сети провайдера (его номер 00012345), можно также позвонить на номер технической поддержки 00010004. Поэтому, я покажу только настройку Route Pattern 9.00xxxxxx (принимаем, что к данному провайдеру мы выходим через 9ку). В реальной системе нужно будет настроить и дополнительные Route Pattern для звонков на остальные направления:
При звонке в SIP-сеть обязательно нужно передавать тот Calling-номер, который нам предоставил провайдер, иначе звонок не будет разрешен. Поэтому, в настройках Route Pattern делаем соответствующую модификацию номера вызывающего абонента. В нашем примере мы имеет только один номер от провайдера, поэтому я указываю его. В случае, если провайдер выдаст несколько номеров, то может потребоваться более сложная трансляция. Не забываем также удалить из Called-номера 9ку:
Для принятия входящих звонков на CUCM настраиваем Translation Pattern. Для того, чтобы позвонить на наш CUCM из SIP-сети, необходимо набрать номер 00044847. Данный номер должен быть преобразован в один из внутренних номеров CUCM, например, в 2002. В соответствии с этим, прописываем настройки Translation Pattern:
На этом базовая настройка CUCM закончена. Переходим к настройкам CUBE. Приведу настройки интерфейсов (подразумевается, что настройки маршрутизации уже выполнены):
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 звонки на шлюзах умолчанию запрещены. Поэтому, для начала разрешим такие звонки, а также сделаем "привязку" сигнализации SIP к одному из интерфейсов (к интерфейсу, адрес которого мы указали в настройках SIP-транка CUCM):
voice service voip
allow-connections sip to sip
sip
bind control source-interface FastEthernet0/0.100
Далее выполняем настройки SIP-агента шлюза (SIP-UA) для регистрации и аутентификации в провайдерской сети:
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 - адрес прокси-сервера, через который будем осуществлять исходящие звонки
Далее настраиваем диал-пиры: один или несколько в сторону провайдерской сети, и один в сторону CUCM для входящих звонков:
dial-peer voice 8 voip
description To_SIP_Provider
destination-pattern 000.....
session protocol sipv2
session target sip-server - звонки осуществляются через SIP-proxy, который мы описали в предыдущем шаге
codec g711ulaw
voice-class sip outbound-proxy dns:voice.telphin.com:5068 - наш CUBE находится во внутренней сети за NAT, поэтому для корректной работы звонков через NAT нужно указать адрес outbound-proxy сервера
!
dial-peer voice 847 voip
description To_CUCM
destination-pattern 00044847
session protocol sipv2
session target ipv4:10.1.1.1
codec g711ulaw
Вот, собственно, и все необходимые настройки. Теперь проверяем регистрацию номера 00044847 в сети провайдера с помощью команды show sip-ua register status и выполняем входящие и исходящие звонки из/в сеть провайдера с телефонов CUCM. При возникновении проблем пользуемся дебагом debug ccsip messages.
Удачи и хорошего дня! :)
Многих из наших читателей очень интересует вопрос подключения CUCM к провайдеру телефонных услуг с помощью SIP-транка. Тема эта очень актуальная, так как все больше провайдеров предлагают, помимо традиционного подключения по потоку Е1, еще и подключение к своей сети по протоколу SIP. Данный пост затронет базовые настройки подключения по SIP (т.е без настройки передачи DTMF, факсов, трансферов и т.п.).
Итак, начнем. Прежде всего, разберемся с топологией, которую нам предстоит настроить. Она показана на следующем рисунке. Тестировать подключение по SIP-транку будем на CUCM 8.0, в качестве CUBE используем роутер 2811 с IOS 12.4.24T.
Подключать лабораторный CUCM будем к провайдеру TelMe (http://tel-me.ru). Провайдер предоставил нам для подключения один номер 00044847. Параметры подключения к сети провайдера следующие:
Username: 00044847
Authorization user: 00044847
Password: ciscolab
Domain/Realm: sip.telphin.com
SIP proxy: sip.telphin.com:5068
Outbound Proxy: voice.telphin.com:5068
Register: Always
Register expires: 1800
Codecs supported: G711(a&u), G729.
Как видно из предоставленных параметров подключения, провайдер требует обязательной регистрации SIP-устройства в своей сети. Без регистрации совершение исходящих и входящих звонков невозможно. К большому сожалению, CUCM не поддерживает регистрацию SIP-транка, т.е он не может зарегистрироваться на Registrar-сервере как SIP-терминал (телефон). По этой причине, а также по ряду иных причин (для разделения сетей, обеспечения безопасности, решения проблемы с NAT), мы подключим наш CUCM к SIP-сети провайдера через IP-IP шлюз - Cisco Unified Border Element (CUBE). CUBE умеет регистрироваться в сети провайдера, поэтому на нем мы пропишем параметры регистрации и аутентификации. Таким образом, у нас будет, по сути, два SIP-транка:
1. SIP-транк между CUCM и CUBE.
2. SIP-транк между CUBE и провайдером.
Далее в настройках транка указываем IP-адрес CUBE (в нашем примере это 10.10.100.11, обычно это адрес, к которому на шлюзе осуществлена "привязка" сигнализации" SIP - команда bind). Также выбираем для транка Destination Port (для CUBE можем использовать стандартный 5060), SIP Security Profile и SIP Profile (профили взяты дефолтные, однако, в зависимости от условий, может потребоваться корректировка их параметров).
Для исходящих звонков настраиваем Route Pattern. Проверку исходящих звонков будем осуществлять при помощи звонка на SIP-терминал, зарегистрированный в той же сети провайдера (его номер 00012345), можно также позвонить на номер технической поддержки 00010004. Поэтому, я покажу только настройку Route Pattern 9.00xxxxxx (принимаем, что к данному провайдеру мы выходим через 9ку). В реальной системе нужно будет настроить и дополнительные Route Pattern для звонков на остальные направления:
При звонке в SIP-сеть обязательно нужно передавать тот Calling-номер, который нам предоставил провайдер, иначе звонок не будет разрешен. Поэтому, в настройках Route Pattern делаем соответствующую модификацию номера вызывающего абонента. В нашем примере мы имеет только один номер от провайдера, поэтому я указываю его. В случае, если провайдер выдаст несколько номеров, то может потребоваться более сложная трансляция. Не забываем также удалить из Called-номера 9ку:
Для принятия входящих звонков на CUCM настраиваем Translation Pattern. Для того, чтобы позвонить на наш CUCM из SIP-сети, необходимо набрать номер 00044847. Данный номер должен быть преобразован в один из внутренних номеров CUCM, например, в 2002. В соответствии с этим, прописываем настройки Translation Pattern:
На этом базовая настройка CUCM закончена. Переходим к настройкам CUBE. Приведу настройки интерфейсов (подразумевается, что настройки маршрутизации уже выполнены):
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 звонки на шлюзах умолчанию запрещены. Поэтому, для начала разрешим такие звонки, а также сделаем "привязку" сигнализации SIP к одному из интерфейсов (к интерфейсу, адрес которого мы указали в настройках SIP-транка CUCM):
voice service voip
allow-connections sip to sip
sip
bind control source-interface FastEthernet0/0.100
Далее выполняем настройки SIP-агента шлюза (SIP-UA) для регистрации и аутентификации в провайдерской сети:
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 - адрес прокси-сервера, через который будем осуществлять исходящие звонки
Далее настраиваем диал-пиры: один или несколько в сторону провайдерской сети, и один в сторону CUCM для входящих звонков:
dial-peer voice 8 voip
description To_SIP_Provider
destination-pattern 000.....
session protocol sipv2
session target sip-server - звонки осуществляются через SIP-proxy, который мы описали в предыдущем шаге
codec g711ulaw
voice-class sip outbound-proxy dns:voice.telphin.com:5068 - наш CUBE находится во внутренней сети за NAT, поэтому для корректной работы звонков через NAT нужно указать адрес outbound-proxy сервера
!
dial-peer voice 847 voip
description To_CUCM
destination-pattern 00044847
session protocol sipv2
session target ipv4:10.1.1.1
codec g711ulaw
Вот, собственно, и все необходимые настройки. Теперь проверяем регистрацию номера 00044847 в сети провайдера с помощью команды show sip-ua register status и выполняем входящие и исходящие звонки из/в сеть провайдера с телефонов CUCM. При возникновении проблем пользуемся дебагом debug ccsip messages.
Удачи и хорошего дня! :)
Огромное спасибо. Очень толково и по делу.
ОтветитьУдалитьЕсть небольшой вопрос. А как в таком сценарии реализовать донабор внутреннего номера? Т.е. звонят по номеру - слышат тон - набирают внутренний - дозваниваются.
Добрый день,
ОтветитьУдалитьСпасибо за отзыв :) Донабор можно реализовать, например, с помощью tcl или vxml скрипта на шлюзе (в нашем случае CUBE). О vxml скрипте можно прочитать тут:
http://alakinalexandr.blogspot.com/2013/02/vxml.html#more
Если у вас имеется голосовая почта, или IP IVR, или CVP, то донабор номера можно реализовать и средствами данных приложений.
НО! Не забудьте про настройку механизмов передачи DTMF (в посте я об этом не писал)
Добрый день! Спасибо большое за статью! Интересует вопрос больше идеологического взгляда - стоит ли разделять логику работы между 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х словах не рассказать. Может быть, если будет вдохновение, напишу об этом пост.
Добрый день, Дмитрий!
ОтветитьУдалитьСпасибо за полезную статью.
От себя хочу добавить, что CUCM 8.6 поддерживает отправку SIP INVITE с аутентификацией, таким образом можно делать исходящие звонки без отправки SIP REGISTER (во всяком случае, провайдер Задарма это поддерживает). Но входящие звонки принять уже не получится, хотя в большинстве случаев это и не нужно.
Добрый день, Денис!
ОтветитьУдалитьДа, верно, CUCM умеет совершать исходящие звонки без предварительной регистрации, отправляя звонки с аутентификацией. Если провайдер это поддерживает и не нужны входящие звонки, то можно обойтись и без регистрации.
Однако, не все провы поддерживают звонки (даже исходящие) без регистрации. В этом случае CUBE, или девайс ему подобный, спасает. TelMe как раз не поддерживает :(
Здравствуйте!
ОтветитьУдалитьА как же всё-таки быть если провайдер выдал несколько номеров и транслировать нужно их все?
Здравствуйте, Кирилл!
ОтветитьУдалитьУточните, пожалуйста, что Вы подразумеваете под трансляцией? Изменение 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 нужно тоже будет сделать.
УдалитьНу и также не забудьте про НАТ...
Здравствуйте Дмитрий!
УдалитьНа текущий момент момент в организации используется CME, все телефоны - программные. Сигнализация - SIP. Хотим подключить несколько SIP номеров от провайдера.
Если я правильно понимаю, то для того что бы наш ISR G2 выступил в роли голосового шлюза необходима покупка CUBE лицензии? Или можно обойтись без нее?
Спасибо!
Добрый день,
УдалитьТеоретически да - лицензия на функционал CUBE нужна. Мне, к сожалению, не доводилось настраивать и тестировать CUBE на 29х/39х роутерах - только на 28х/38х. Я задал Ваш вопрос инженерам одного из интеграторов, они ответили, что покупка лицензий - это чистая формальность (на честность, так сказать), и что все функции CUBE будут работать и без лицензий (как в свое время работал СМЕ). Попробуйте настроить, если не получится, то лицензии всегда можно купить.
Здравствуйте, Дмитрий! Огромное спасибо Вам за эти информативные статьи. Обращаюсь за помощью 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.
Все это, конечно, будет работать если провайдер у вас добросовестный, и все присылает "по-честному".
Дмитрий, а Type of Number (TON) передается по SIP ?
УдалитьДоброе утро,
УдалитьНет, к сожалению, TON по SIP не передается. Описанный выше пример будет работать для шлюзов H323 и MGCP.
Спасибо, Дмитрий. Получается, что для входящих по SIP логика обработки для добавления кода выхода должна основываться на длине входящего номера?
УдалитьДа, именно так, другое что-то в таком случае вряд-ли можно придумать.
УдалитьДень добрый, Дмитрий
ОтветитьУдалитьСпасибо за информативную статью.
У меня вопрос, поддерживает ли 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-транка на шлюзе циско.
Здравствуйте. Хотел бы попросить помощи в следующей ситуации: имеется Cisco 500 series UC-520-16, несколько цискофонов (7906 и 7940). Со внутренними телефонами я разобрался, но теперь стоит задача выпустить телефоны в ГТС.
ОтветитьУдалитьВыход в гтс выполнен в виде SIP-транка, похоже, не требующего авторизации (пользователь-пароль не даны, даны только адреса для оборудования, городской номер, и адрес сип-прокси). Как правильно подключить этот сип-транк на циске и как научить телефоны звонить наружу и принимать оттуда звонки? Попробовал на одном из портов настроить данный адрес, при звонке извне в дебаге, вроде как, виден входящий вызов.
Прошу прощения за масштабный вопрос, но ни с телефонией, ни с оборудованием cisco до этого случая не сталкивался. Хотелось бы получить хотя бы примерный порядок действий.
Заранее спасибо.
Добрый вечер,
УдалитьВопрос действительно очень масштабный и в двух словах его не описать, конечно же. Я бы посоветовал Вам почитать литературу или посмотреть видео по курсу CVOICE (например, те же CBT Nuggets). А еще лучше - пройти авторизованный тренинг циско, если есть возможность. (я, кстати, буду вести такой курс скоро в учебном центре Микротест в Москве 10.06.2013, могу Вам также предложить поучиться дистанционно, он-лайн ,если есть желание).
Если говорить о плане действий, то по минимуму нужно сделать следующее:
- настроить диал-пиры для входящего и исходящего звонков;
- настроить список доверенных внешних сторонних устройств, которым будут разрешены входящие звонки на ваш шлюз (если IOS версии 15 и новее);
- настроить правила преобразования Calling и Called номеров для ваших SIP-звонков.
Спасибо за ответ. Тренинг - это замечательно, но сроки не располагают. Нужно закончить эту работу буквально на днях.
УдалитьПочитав в интернете, поспрашивав на форуме, разобрался во всем:)
Последней проблемой было то, что я забыл указать в исходящем диал-пире использование сип-протокола.
Но на насчет курсов я уже задумался.
Здорово, что разобрались, не так это и сложно, на самом деле. Но курсы все же посетить стоит, если планируете поддерживать голосовые решения (у меня или у другого тренера, не суть важно). Главное понять и разобраться досконально, как это работает.
УдалитьБуду рад, если придете на курсы ко мне в Микротест (если Вы из России), или к моим воспитанникам - инструкторам Cisco Центра Знаний (если Вы из Украины).
Здравствуйте.
УдалитьВозникла следующая проблема. На данной циске (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. Что-то совершенно необъяснимое... Вот и увидим, что происходит.
Здравствуйте, Дмитрий! Подскажите решение: имеется телефон 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 (односторонняя слышимость, отсутствие разговора вообще).
Здравствуйте Дмитрий!
ОтветитьУдалитьПрежде всего хочу поблагодарить вас за ваш труд, он бесценен!
Теперь к делу, настроен 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 есть соответствующие галочки. Надо проверить, включены ли они.
Enable Outbound FastStart выключено.
ОтветитьУдалитьВключил: http://gyazo.com/6d3fc2d8a40a049736e3fb05e81ad602
Все тоже самое, дебаг не изменился.
вот что происходит когда звонят из города:
ОтветитьУдалить.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
и звонок так же отваливатеся, сразу занято...
На входящем другая ошибка - 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мю. Циска воспринимает их как разные кодеки, и, соответственно, звонок не возможен.
Установите одинаковые кодеки для обоих телефонов и попробуйте позвонить. Если не заработает, то включайте указанный дебаг, снова звоните, и присылайте результат дебага.
Спасибо, с локальными звонками разобрался - действительно, кодеки. Включая ещё присоединение другой подобной циски - там оказывается надо было кодеки указывать в каждом 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 посылками.
Добрый день, такой вопрос,
ОтветитьУдалитьА что надо купить(лицензии,платы)
чтобы 2911 использовать в качестве cuba? для sip провайдера
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
Добрый день,
ОтветитьУдалитьНужно купить лицензии для 2911, поддерживающие войсовый функционал (иначе без лицензии, как Вы знаете, в IOS не будет войсовых команд). Платы покупать не надо.
Дмитрий, большое спасибо за статью. Недавно задался вопросом: а как чисто физически происходит подключение атс провайдера к магистральному оператору телефонии, если нужно например огромное количество линий? Неужели заводят кучу потоков Е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 при регистрации. Напишите, пожалуйста, в форме для связи свой мейл, по почте общаться проще.
Добрый день, Дмитрий!
ОтветитьУдалитьСпасибо, за статью очен полезная!
какие можно ли роутер 2811 использовать и как маршрутизатор и как CUBE? и какой IOS нужна для этого? с уважением. Рус
Здравствуйте,
УдалитьСпасибо за Ваш отзыв. Конечно, можно использовать 2811 и как маршрутизатор, и как CUBE. По поводу IOS - можно использовать любой войсовый, который поддерживает функционал CUBE (посмотреть это можно с помощью Feature Navigator на cisco.com)
Как вариант, подойдет IOS, содержащий в своем названии буквы ivs.
Здравствуйте, Дмитрий!
ОтветитьУдалитьСпасибо за ответ. Проблема оказалась в том, что нам сообщили неверный пароль :)
Пользуясь моментом, хочу задать ещё один вопрос, правда не на тему 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, Вы указываете адрес встречной стороны, теперь этот айпишник известен шлюзу и он спокойно расценивает вызывающее устройство как известное и обрабатывает вызовы.
Действительно в 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
Спасибо за ответ. Про NAT то понятно. Просто на идею без статического NAT меня сподвигли строчки из статьи Андрея Погребенника -
Удалить"Проблема актуальна не только в период после регистрации пользователя: во время SIP-диалогов новые сообщения также могут не поступать в течение длительного промежутка времени, чего достаточно для того, чтобы запись из таблицы трансляции была удалена. Имеющиеся SIP-стеки решают эту проблему путём периодической посылки SIP-запросов re-INVITE, OPTIONS, INFO, NOTIFY или (при использовании UDP) дейтаграмм, не содержащих полезной нагрузки." (c) http://samag.ru/archive/article/2017
Вот и задался данным вопросом. Решил спросить у Вас.
Добрый день, Александр. NAT - это абсолютное зло для IP-телефонии. В случаях, если есть возможность взять "белый" айпишник, то надо использовать CUBE, а не NAT.
УдалитьСпасибо за ссылку на статью, интересно. Почитаю на досуге. Сейчас веду курс в Алматы... :)
Добрый день, Дмитрий!
ОтветитьУдалитьСпасибо за ответ! вопрос можно ли сперва настроить SIP транк между IP PBX и CUBE без ССМ. то есть чтобы CUBE зарегистрировался на SIP PBX?
С уважением,
Рустам
Добрый день, Рустам!
УдалитьДа, так сделать можно. С этим нет проблем. Настраивайте и регистрируйте сначала CUBE, потом настраивайте ССМ. Порядок не имеет значения.
Добрый день, Дмитрий!
ОтветитьУдалитьСпасибо, за ответ!
Я настроил следующим образом но пока не регистрируется, где моя ошибка пожалуйста укажите.
топология следующая:
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, чтобы увидеть причину отбоя.
Спасибо за ответ.
УдалитьВОт мне говорят что на CME вроде как нужна до лицензия...
Приведит,е пожалуйста, ссылку на это решение - регистрации SIP-телефонов сторонних производителей.
>Также нужно смотреть debug ccsip messages, чтобы увидеть причину отбоя.
В том и дело что пусто было просто в логах. Видимо потому что АТС пыталась зарегистрироваться, а такой функционал не включен (CME).
Доброе утро,
УдалитьСсылка на пост о регистрации SIP-телефонов на СМЕ:
http://dbenda.blogspot.com/2011/10/sip-call-manager-express.html
Добрый день Дмитрий!
ОтветитьУдалитьСпасибо огромное регистрация прошла успешно!
теперь возникли с 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ку. По-другому никак не получится.
УдалитьДобрый день, Дмитрий!
УдалитьНумерация на АТСке и 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. Нужно, чтобы такой же транспорт был и на ССМ.
Дмитрий, спасибо за ответ.
Удалитьнастройки 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.
УдалитьДа пингуется!
УдалитьДмитрий, добрый день,
Удалить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 должен быть правильный в обеих строках.
Добрый день, Дмитрий!
Удалитьреалм в обоих строках одинаковый
вот полная конфиг-я
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.
А не подскажете, куда копать в таком случае: если я прописываю диалпир в сторону другой 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 обычно)?
Разобрался. Оказывается, мало настроить маршрутизацию между цисками, надо ещё и между телефонами (!). Додумался до этого, только увидев в логе вместо адреса второго роутера адрес тамошнего телефона.
Удалить:) поздравляю :) Однако, не совсем понятно. Да, маршрутизация между телефонами нужна, безусловно, иначе не будет ходить голосовой трафик. Но сигнализация то должна ходить между двумя телефонными 2901, и для нее маршрутизация между телефонами не нужна, по идее. Если бы не было маршрутизации между подсетями телефонов, вы бы получили отсутствие голосового трафика, но звонок бы проходил.
УдалитьЕсли найдете время, был бы Вам признателен за пояснения. Интересный просто случай.
Здравствуйте!
ОтветитьУдалитьИнтересная ситуация, раньше с таким не сталкивался:
один и тот же абонент CUCM (на шлюзе VG224) несколько раз подряд набирает один и тот же городской номер, вызовы идут по одному и тому же маршруту, но CUCM к другой станции шлет INVITE иногда с SDP, иногда без. Маршрутизация по времени не используется. В трейсах 2 инвайта отличаются только наличием поля Message Body. С чем это может быть связано?
С уважением, Евгений.
Добрый день, Евгений!
УдалитьInvite c SDP и без SDP означает разные режимы работы сигнализации SIP - Early Offer и Delayed Offer соответственно. Скажите, установлена ли на SIP-транке галочка MTP required (Media Termination Point Required)?
Спасибо за ответ.
ОтветитьУдалитьГалка установлена, MRG-list выбран. Версия CUCM 7.
Такая же ситуация наблюдается при транзитном вызове через CUCM с MGCP-шлюза (там подключена по DSS1 другая станция) в SIP-транк: INVITE уходит то c Early Offer, то с Delayed Offer без всякой закономерности.
Может недостаточно МТР ресурсов? Посмотрите в RTMT (счетчики) сколько имеется МТР и какова их загрузка.
УдалитьДмитрий, спасибо за помощь!
УдалитьДействительно не хватает ресурсов MTP.
Добрый день!
ОтветитьУдалитьпомогите решить проблему, пожалуйста.
подключено от 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 на другой.
Вы были правы! изменил Realm и все заработало!
УдалитьЭто, я как понимаю, параметр вообще не зависит от IP или DNS-имени sip-сервера (как я думал). потому как dns-имя сервера в моем случае pbx.hypernet.ru
Благодарю за помощь!
Пожалуйста! :)
УдалитьРад, что все заработало.
А можно вопрос почти в тему?
ОтветитьУдалитьУ меня задача: привязать 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 находится.
УдалитьТак... исходящие звонки поборол, теперь нарисовалась проблема со входящими.
УдалитьОказывается, при конфигурации проброса
!
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″
но чуда не произошло.
Здравствуйте,
УдалитьПодмена заголовков вообще сложная тема, каждый сценарий нужно проверять. На данный момент я затрудняюсь сразу дать точный ответ, к сожалению . Попробую при случае смоделировать это в лабе, но ранее следующей недели сделать это не смогу, потому как нахожусь в Москве на курсах.
Вообще, идея, описанная в приведенной Вами ссылке, правильная. Важно только правильно применить сип-профиль. Он должен быть установлен на ИСХОДЯЩЕМ диал-пире, который отправляет звонки со шлюза на ССМ.
Я бы и сам на стенде попробовал собрать, а чем можно смоделировать такое поведение SIP-провайдера, чтобы подставить нужные поля в нужные заголовки SIP? asterisk-ом ?
УдалитьДоброго дня!
ОтветитьУдалитьУ меня такая проблема.
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?