Welcome Message

Hello my dear reader,

Welcome to my blog, which is dedicated to Cisco technologies. On its pages we will talk about the limitless world of telephony and networking.

We will focus mostly on Cisco collaboration solutions and technologies. These are IP PBX based on Cisco Unified Communications Manager and Cisco Unified Communications Manager Express, Cisco contact centers, Cisco Voice Gateways, etc. Also, I will introduce you the education news: Cisco authorized courses, my own developed training programs, our upcoming events, online learning.

If you have any questions regarding my posts, job or activities, please feel free to ask your questions. I will try to answer them when I have time.

If you are satisfied with the content of my blog, isn’t that worth a beer or coffee? Donations help me to continue supporting the blog and creating new posts here — things for which I spend hours of my free time! Thank you very much!

Sincerely, Dmytro Benda

Monday, March 11, 2013

CUCM SIP-trunk to ITSP (via CUBE) basic configuration

Good day,

Many of my readers and students are very interested in the topic of how to connect their CUCM to IP telephony service provider via SIP-trunk. This topic is very relevant, as more and more providers offer SIP services and connections, in addition to traditional E1 or BRI lines. This post will discuss the basic settings for SIP-trunks (i.e. without DTMF, fax settings, transfers, etc.).
So, here we go. First of all, let's see, which topology we will configure. It is shown in the figure below. A SIP trunk will be created on the CUCM 8.0, for CUBE we will use a 2811 router with 12.4.24T IOS.


In my example I will connect my lab CUCM to Russian ITSP Telme (http://tel-me.ru). I have created a basic account there and received one internal directory number for our test. The DN is 00044847. The connection parameters are as follows:

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.

As it can be seen from the connection settings, our ITSP requires mandatory registration of SIP devices in their network. Without registration neither incoming nor outgoing calls are possible. Unfortunately, CUCM does not support registration of SIP trunks, i.e., it can not register at SIP Registrar server as a SIP terminal (a SIP phone). For this reason, as well as for a number of other reasons (for the separation of networks, security, NAT overriding), we will connect our CUCM to SIP provider network through the IP-IP gateway - Cisco Unified Border Element (CUBE). CUBE is able to register at ITSP network, so it will be set with credentials and authentication parameters. Thus, we will have, in fact, two SIP legs:

1. SIP trunk between CUCM and CUBE.
2. SIP connection between the CUBE and the provider.

First, we set up SIP trunk on CUCM. As usual, screenshots illustrate the process. Go to the CM Administration, then select  Device -> Trunk -> Add New and add a new SIP trunk. Specify the trunk Name, Description, Device Pool, and do not forget to check Media Termination Point Required check box. It is necessary first of all to enable SIP Early Offer signaling, and also solves many other problems (DTMF in-band, problems with call transfer, alaw / ulaw conversion, etc). If you use this check box in your system, there must be preconfigured and registered MTP already (what MTPs are and their role you can find here):


Updated: I wrote this article a long time ago, and MTP Required check box was the only one solution to enable SIP Early Offer on the trunk in CUCM 8.0. However, in newer CUCM there are some other options for the Early Offer and you can read about them in my recent post - How to enable Early Offer in SIP Trunk CUCM?

Next, for your SIP trunk set the IP-address of CUBE (in this example it is 10.10.100.11, usually it must be the address to which SIP signaling is binded at the CUBE). Also, set Destination Port (for CUBE can use the standard 5060), SIP Security Profile and SIP Profile (default profiles are taken, however, depending on your task, they may require an adjustment of the parameters).


For outgoing calls create a Route Pattern. I will check outgoing calls by making call to a SIP terminal registered at the same provider (its number is 00012345). It is also possible to call provider's technical support number, which is 00010004. Therefore, I will configure Route Pattern 9.00xxxxxx (9 is an Access Code to this destination). In a real system you will need to set up additional Route Patterns for calls to other directions:


When calling to SIP provider network, it is required to send a correct Calling number (CLID), which is required by your provider. Otherwise the call will not be allowed. Therefore, in Route Pattern settings let's make appropriate Calling number manipulation. In our example we have only one number from the provider, so I use it. If the provider gives you a few directory numbers, a more complicated translation might be done. Do not forget to remove the Access code (9) from the Called Number:


For incoming calls to CUCM let's create a Translation Pattern. To reach our CUCM from SIP network we dial 00044847. This number must be converted to one of the CUCM's extensions, for example, to 2002:


Now, the basic CUCM setup is completed . It's time to continue with the CUBE. Here are the network interface settings (assuming the routing configuration has already been done):

interface FastEthernet0/0.100
 description WAN
 encapsulation dot1Q 100
 ip address 10.10.100.11 255.255.255.0
!         
interface FastEthernet0/0.111
 description HQ-1 Servers
 encapsulation dot1Q 111
 ip address 10.1.1.101 255.255.255.0
!
interface FastEthernet0/0.112
 description HQ-1 Phones
 encapsulation dot1Q 112
 ip address 10.1.2.101 255.255.255.0

IP-IP calls are prohibited at Cisco voice gateways by default. Therefore, let's allow such calls as well as make SIP signaling binding to one of the interfaces: to the interface, whose address we have configured at CUCM SIP trunk):

voice service voip 
 allow-connections sip to sip
 sip
  bind control source-interface FastEthernet0/0.100

Then configure SIP UA settings for registration and authentication at the ITSP network:

sip-ua 
 credentials username 00044847 password ciscolab realm sip.telphin.com - регистрирует номер 00044847 в сети провайдера
 authentication username 00044847 password ciscolab realm sip.telphin.com - указывает параметры аутентификации при исходящем звонке.
 registrar dns:sip.telphin.com:5068 expires 3600 - адрес сервера Registrar
 sip-server dns:sip.telphin.com:5068 - адрес прокси-сервера, через который будем осуществлять исходящие звонки

Now it is time to make voice dial-peers: one or more dial-peers to the provider network, and one dial-peer to our CUCM for incoming calls:

dial-peer voice 8 voip
 description To_SIP_Provider
 destination-pattern 000.....
 session protocol sipv2
 session target sip-serverour outgoing calls are done via SIP Proxy
  codec g711ulaw
 voice-class sip outbound-proxy dns:voice.telphin.com:5068as far as our CUBE is behind NAT, we need to use SIP outbound proxy. So set outbound proxy name\IP address and port here.
!
dial-peer voice 847 voip
 description To_CUCM
 destination-pattern 00044847
 session protocol sipv2
 session target ipv4:10.1.1.1
 codec g711ulaw

In fact, here are all the necessary settings. Now, check the registration of the directory number 00044847 at  the provider's network by using show sip-ua register status command. Then make incoming and outgoing calls from / to ITSP network. If you face some problems with SIP signaling, use debug ccsip messages command on CUBE for troubleshooting.

Good luck and have a nice day! :)

235 comments:

  1. Огромное спасибо. Очень толково и по делу.
    Есть небольшой вопрос. А как в таком сценарии реализовать донабор внутреннего номера? Т.е. звонят по номеру - слышат тон - набирают внутренний - дозваниваются.

    ReplyDelete
  2. Добрый день,

    Спасибо за отзыв :) Донабор можно реализовать, например, с помощью tcl или vxml скрипта на шлюзе (в нашем случае CUBE). О vxml скрипте можно прочитать тут:

    http://alakinalexandr.blogspot.com/2013/02/vxml.html#more

    Если у вас имеется голосовая почта, или IP IVR, или CVP, то донабор номера можно реализовать и средствами данных приложений.

    НО! Не забудьте про настройку механизмов передачи DTMF (в посте я об этом не писал)

    ReplyDelete
  3. Добрый день! Спасибо большое за статью! Интересует вопрос больше идеологического взгляда - стоит ли разделять логику работы между 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-номером?

    ReplyDelete
    Replies
    1. Добрый день, Сергей!

      Попробую ответить на Ваши вопросы. По первому вопросу - нет абсолютно никаких рекомендаций по поводу того, где выполнять трансляции номеров: на шлюзе или в ССМ. И та, и другая методика являются абсолютно приемлемой. Где удобнее и понятнее настраивать трансляции - там их и делают. Если шлюз MGCP, то тогда, конечно, трансляции выполняются только на ССМ, а в случае CUBE оба варианта одинаково хороши.

      По второму вопросу - для модификации номера вызывающего абонента в зависимости от номера звонящего можно применить, например, External Phone Number Mask (параметр в блоке DN), или, что более прогрессивно, модификацию номера с помощью Transformation Pattern, которая применяется затем к шлюзу или транку (т.е прикрепляется к шлюзу или транку с помощью Calling Party Transformation CSS). Такая методика прекрасно работает и применяется в случаях подключения CUCM к разным провайдерам (как при Е1, так и при SIP).

      К сожалению, эта методика более сложная, и о ней в 2х словах не рассказать. Может быть, если будет вдохновение, напишу об этом пост.

      Delete
  4. Добрый день, Дмитрий!

    Спасибо за полезную статью.
    От себя хочу добавить, что CUCM 8.6 поддерживает отправку SIP INVITE с аутентификацией, таким образом можно делать исходящие звонки без отправки SIP REGISTER (во всяком случае, провайдер Задарма это поддерживает). Но входящие звонки принять уже не получится, хотя в большинстве случаев это и не нужно.

    ReplyDelete
  5. Добрый день, Денис!

    Да, верно, CUCM умеет совершать исходящие звонки без предварительной регистрации, отправляя звонки с аутентификацией. Если провайдер это поддерживает и не нужны входящие звонки, то можно обойтись и без регистрации.

    Однако, не все провы поддерживают звонки (даже исходящие) без регистрации. В этом случае CUBE, или девайс ему подобный, спасает. TelMe как раз не поддерживает :(

    ReplyDelete
  6. Здравствуйте!
    А как же всё-таки быть если провайдер выдал несколько номеров и транслировать нужно их все?

    ReplyDelete
  7. Здравствуйте, Кирилл!

    Уточните, пожалуйста, что Вы подразумеваете под трансляцией? Изменение Calling номера при исходящем звонке с ССМ в сторону прова или изменение Called номера при входящем звонке со стороны прова в ССМ?

    ReplyDelete
  8. Здравствуйте!
    Интересует именно изменение calling номера на один из выданных провайдером при исходящих с ССМ.

    ReplyDelete
    Replies
    1. Доброе утро,

      Тут могут быть варианты, все зависит от вашего плана нумерации, выданного провайдером. Если последние цифры нумерации, выданной провайдером, совпадает с номерами внутренних абонентов, то все просто - в Route Pattern настраиваем Calling Party Transform Mask. Например, провайдер дает вам 100 номеров (00055500 - 00055599), а внутренние номера у вас 100 - 199. Тогда Calling Party Transform Mask нужно задать как 000555ХХ.

      Если же более сложный случай, когда нет такого совпадения нумерации, нужно применять модификацию номера с помощью Transformation Pattern, которая применяется к транку (т.е прикрепляется к транку с помощью Calling Party Transformation CSS). К сожалению, кратко не получится рассказать, как она работает. Нужно писать отдельный пост с картинками и пояснениями.

      Delete
  9. Евгений28 March, 2013 11:50

    Добрый день.
    Спасибо за статью. Подскажите как будет выглядеть подключение к sip-провайдеру, в случае, когда у нас все-в-одном: на одном рутере и CME и CUBE?
    Достаточно ли будет в простейшем случае настроить dial-peer на sip-провайдера для исходящих звонков и translation rule для входящих?

    ReplyDelete
    Replies
    1. Добрый день, Евгений!

      В этом случае CUBE нет, как такового (разве что у вас телефоны Cisco используют SIP сигнализацию). Да, действительно, в таком случае достаточно будет настроить диал-пиры и трансляции номеров для входящих и исходящих звонков.

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

      Вот тут можете немного почитать о таких атаках и методах защиты:

      http://palavdin.blogspot.com/2012/10/achtung-ios-1512.html

      Delete
    2. Да, и еще хочу добавить - если подключаем СМЕ к прову, то не забываем про регистрацию SIP-UA у провайдера. Т.е настройки аутентификации, credentials нужно тоже будет сделать.

      Ну и также не забудьте про НАТ...

      Delete
    3. Здравствуйте Дмитрий!
      На текущий момент момент в организации используется CME, все телефоны - программные. Сигнализация - SIP. Хотим подключить несколько SIP номеров от провайдера.

      Если я правильно понимаю, то для того что бы наш ISR G2 выступил в роли голосового шлюза необходима покупка CUBE лицензии? Или можно обойтись без нее?

      Спасибо!

      Delete
    4. Добрый день,

      Теоретически да - лицензия на функционал CUBE нужна. Мне, к сожалению, не доводилось настраивать и тестировать CUBE на 29х/39х роутерах - только на 28х/38х. Я задал Ваш вопрос инженерам одного из интеграторов, они ответили, что покупка лицензий - это чистая формальность (на честность, так сказать), и что все функции CUBE будут работать и без лицензий (как в свое время работал СМЕ). Попробуйте настроить, если не получится, то лицензии всегда можно купить.

      Delete
  10. Здравствуйте, Дмитрий! Огромное спасибо Вам за эти информативные статьи. Обращаюсь за помощью 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, а остальные звонки не затрагивались?

    ReplyDelete
  11. Добрый день, Евгений!

    Я бы предложил Вам использовать на шлюзе настройки 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.

    Все это, конечно, будет работать если провайдер у вас добросовестный, и все присылает "по-честному".

    ReplyDelete
    Replies
    1. Дмитрий, а Type of Number (TON) передается по SIP ?

      Delete
    2. Доброе утро,

      Нет, к сожалению, TON по SIP не передается. Описанный выше пример будет работать для шлюзов H323 и MGCP.

      Delete
    3. Спасибо, Дмитрий. Получается, что для входящих по SIP логика обработки для добавления кода выхода должна основываться на длине входящего номера?

      Delete
    4. Да, именно так, другое что-то в таком случае вряд-ли можно придумать.

      Delete
  12. День добрый, Дмитрий
    Спасибо за информативную статью.
    У меня вопрос, поддерживает ли CUBE регистрацию по SIP у 2-х провайдеров? К примеру одно соединение основное, второе резервное. В моей случае в роли CUBE - Cisco 2901

    ReplyDelete
    Replies
    1. Добрый день,

      Благодарю Вас за отзыв :). Если я понимаю правильно, то с появлением 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х провов.

      Delete
    2. Добрый день, простите что вклиниваюсь..
      А как на диалпирах указывать на разных провайдеров?
      Есть какая то вариация команды session target sip-server ?

      Delete
    3. Добрый день,

      Думаю, что с этим не будет никаких проблем:

      session-target dns:sip.telphin.com:5068

      Аналогичным образом делаем для других провайдеров.

      Delete
    4. Не совсем понятно какой registrar будет использоваться с командой:
      session-target dns:sip.telphin.com:5068
      И соответственно какие будут использованы юзер и пароль

      Имеется в виду, как в диалпире указать что использовать скажем registrar 1 а не 2

      Delete
    5. Добрый день,

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

      По существу Вашего вопроса: будет использован 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

      Delete
  13. Дмитрий, подскажите пожалуйста, возможно ли на каком-нибудь цисковом железе/ПО организовать конвертор сигнализации SIP/H.323 trunk <-> MGCP (в качестве Call Agent выступает Huawei SoftX)? Вроде бы в Cisco IOS Software Version 15.1(4)M2 на 7301 есть все необходимое, однако я никак не могу найти подходящей документации с примерами, которая помогла бы мне это настроить.

    ReplyDelete
  14. Добрый день, Евгений!

    К сожалению, мне такого рода задачи (конвертировать SIP/H323 в MGCP не приходилось решать). Однако, скажу свое мнение - думаю, что это невозможно на циске. Поясню свою мысль - циско-шлюз регистрирует на Call Agent'е (CUCM) аналоговые или цифровые физические порты (FXO, E1, FXS). Для этой цели используется даже система обозначения и имен физических портов, которые содержат в себе номер слота, номер модуля и номер порта. А какие имена будут иметь транки H323/SIP, ведь физических портов ведь нет???

    Вы пишете про 7301, а подскажите, пожалуйста, что навело Вас на такую мысль (возможно, какая-то статья или форум)?

    ReplyDelete
  15. Конвертация 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?

    ReplyDelete
    Replies
    1. Так с Е1 и вопросов нет :) - MGCP прекрасно для управления шлюзом с портами Е1 подходит. 28я, 29я, 38я, 39я да и другие серии шлюзов Cisco абсолютно хорошо работают с MGCP.


      Delete
  16. Скажите, а сделать SIP Trunk из SIP c регистрацией на том же Cisco IOS Software Version 15.1(4)M2 на 7301 - это менее противоестественное желание? Что посоветуете почитать по этому поводу?

    ReplyDelete
    Replies
    1. Думаю, что SIP-транк - это более естественное желание. Почитать - да, собственно, любую литературу по настройке голосовых шлюзов циско. Погуглите книжки из серии Cisco Press по курсу CVOICE (Cisco Voice over IP).

      Да и в моей статье, в которой Вы сейчас комменты пишете, фактически приведен пример SIP-транка на шлюзе циско.

      Delete
  17. Здравствуйте. Хотел бы попросить помощи в следующей ситуации: имеется Cisco 500 series UC-520-16, несколько цискофонов (7906 и 7940). Со внутренними телефонами я разобрался, но теперь стоит задача выпустить телефоны в ГТС.
    Выход в гтс выполнен в виде SIP-транка, похоже, не требующего авторизации (пользователь-пароль не даны, даны только адреса для оборудования, городской номер, и адрес сип-прокси). Как правильно подключить этот сип-транк на циске и как научить телефоны звонить наружу и принимать оттуда звонки? Попробовал на одном из портов настроить данный адрес, при звонке извне в дебаге, вроде как, виден входящий вызов.
    Прошу прощения за масштабный вопрос, но ни с телефонией, ни с оборудованием cisco до этого случая не сталкивался. Хотелось бы получить хотя бы примерный порядок действий.
    Заранее спасибо.

    ReplyDelete
    Replies
    1. Добрый вечер,

      Вопрос действительно очень масштабный и в двух словах его не описать, конечно же. Я бы посоветовал Вам почитать литературу или посмотреть видео по курсу CVOICE (например, те же CBT Nuggets). А еще лучше - пройти авторизованный тренинг циско, если есть возможность. (я, кстати, буду вести такой курс скоро в учебном центре Микротест в Москве 10.06.2013, могу Вам также предложить поучиться дистанционно, он-лайн ,если есть желание).

      Если говорить о плане действий, то по минимуму нужно сделать следующее:

      - настроить диал-пиры для входящего и исходящего звонков;
      - настроить список доверенных внешних сторонних устройств, которым будут разрешены входящие звонки на ваш шлюз (если IOS версии 15 и новее);
      - настроить правила преобразования Calling и Called номеров для ваших SIP-звонков.

      Delete
    2. Спасибо за ответ. Тренинг - это замечательно, но сроки не располагают. Нужно закончить эту работу буквально на днях.
      Почитав в интернете, поспрашивав на форуме, разобрался во всем:)
      Последней проблемой было то, что я забыл указать в исходящем диал-пире использование сип-протокола.
      Но на насчет курсов я уже задумался.

      Delete
    3. Здорово, что разобрались, не так это и сложно, на самом деле. Но курсы все же посетить стоит, если планируете поддерживать голосовые решения (у меня или у другого тренера, не суть важно). Главное понять и разобраться досконально, как это работает.

      Буду рад, если придете на курсы ко мне в Микротест (если Вы из России), или к моим воспитанникам - инструкторам Cisco Центра Знаний (если Вы из Украины).

      Delete
    4. Здравствуйте.
      Возникла следующая проблема. На данной циске (UC-520-16) настроен выход в ГТС через сип-транк. Все работает, но время от времени, при входящих звонках (по моим наблюдениям только с городских номеров) происходит ошибка при согласовании кодеков и, соответственно, шипение и треск, вместо нормальной связи. В дебаге видно, что несовпадают negotiated и preferred кодеки.
      в voice class codec пришлось прописать только ulaw, так как при добавлении любых других кодеков вообще все звонки превращались в шипение и шум.
      Но, как я понимаю, для правильной работы согласования кодеков, там должны быть прописаны желаемые кодеки?
      P.S. Сама циска очень древняя, досталась мне, так сказать, трофейной. Версия CME вообще архаичная.
      show telephony-service
      CONFIG (Version=4.2(0))
      Может быть в этом проблема? Есть возможность купить новую, но, опять же, не знаю какую выбрать (офис небольшой).
      Заранее спасибо.

      Delete
    5. Добрый день,

      Если бы кодеки не совпадали, то звонок бы вообще не проходил, был бы отбой. Подскажите, а такое наблюдается при звонках на IP-телефоны или на аналоговые? Если на аналоговые, то я рискну предположить, что у вас какая-то проблема с DSP (плата PVDM2), установленной в UC520.

      Не думаю, что проблема лежит в версии СМЕ, хотя, конечно же, IOS нужно обновить, уж очень он старый. Возможно, что проблема уйдет вместе с обновлением IOS.

      Delete
    6. Спасибо за ответ.
      Судя по наблюдениям, проблемы возникают только при звонках на городские телефоны.
      Внутри организации, а так же при звонках, например, на мобильные телефоны, слышимость отличная.
      А по логам видно, что, например:

      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 все таки не совпадают. хотя звонок прошел, хоть и с треском.

      Delete
    7. Здравствуйте,

      Я думаю, что такая ситуация с preferred и negotiated кодеками вполне может быть. Например, если с вашей стороны на диал-пире для городского звонка по SIP установлен список кодеков (voice class codec). В этом списке первым по счету может стоять кодек G729, он и будет preferred, а вторым по счету - G711. Но на стороне прова, возможно, установлен лишь один кодек - G711. Поэтому, стороны договариваются о кодеке G711, который и обозначен как negotiated.

      Delete
    8. В voice class codec прописан только g711ulaw
      Стоит прописать туда что то еще (alaw,G729), ситуация с треском проявляется при всех звонках. уже даже не знаю, куда копать...

      Delete
    9. Странная ситуация. Давайте посмотрим на дебаг debug voip ccapi inout при проблемном звонке. Необходимо понимать, какой диалпир выбирается в качестве исходящего, далее проверим его настройки.

      А так получаются чудеса - в диалпире прописан 711мю, приоритетный кодек - 729,а по итогу выбирается g711a. Что-то совершенно необъяснимое... Вот и увидим, что происходит.

      Delete
  18. Здравствуйте, Дмитрий! Подскажите решение: имеется телефон cisco 9971, на консолях у которого занесены на Speed_Dial городские, сотовые, междугородние номера телефонов. Как этому списку из SD разрешить звонки на этот телефон 9971, а все остальные пересылать на другой номер (DN)? Или вообще остальные блокировать желательно средствами CUCM.

    ReplyDelete
    Replies
    1. Добрый день, Евгений!

      Я не совсем понял задачу Вашу. Правильно ли я понимаю, что на номер телефона 9971 должны приходить ВХОДЯЩИЕ звонки только с номеров кнопок SD? Звонки со всех других вызывающих номеров должны блокироваться или отправляться на другой DN? Так?

      Т.е должна быть фильтрация звонков по номеру вызывающего абонента?

      Delete
  19. Да, пропускать входящие звонки из SD, а остальное пересылать на другой номер или вообще блокировать. И если можно хотя бы в двух словах рассказать как происходит фильтрация входящего трафика на CUCM (проверка по caller ID например), можно ли создать COR-лист или это все организуется в Translation Pattern?

    ReplyDelete
    Replies
    1. Доброе утро, Евгений!

      В двух словах это, увы, не рассказать. Собираюсь написать в ближайшее время об этом пост в блоге. Может быть, к концу недели статья будет. Пока что могу привести Вам ссылки, где об этом можно почитать:

      http://palavdin.blogspot.sk/2012/10/ani.html
      https://supportforums.cisco.com/docs/DOC-18367

      Delete
  20. Спасибо Вам за ссылки. Также отдельное спасибо за ваш труд, эти посты и ответы на наши вопросы очень помогают осознать и понять все тонкости настройки CUCM. Будем ждать новых статей в вашем блоге!

    ReplyDelete
  21. Добрый день, Дмитрий!

    Спасибо за статьи!
    Когда планируете затронуть тему Transformation Pattern?

    Заранее благодарен,
    Денис.

    ReplyDelete
    Replies
    1. Здравствуйте, Денис!

      Статья по Transformation Pattern выйдет в ближайшее время (через неделя,может через две). В настоящий период у меня очень большая загрузка, посему пишу в блоге меньше.

      Delete
  22. Здравствуйте, Дмитрий!
    Хотел с Вами посоветоваться, правильно ли я собираюсь сделать или нет.
    При подключении по 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 "" ""

    ReplyDelete
    Replies
    1. Здравствуйте,

      Да, что именно использование подобных voice class sip-profiles поможет в данной проблеме.

      Delete
  23. Здравствуйте Димитрий!

    Хочу задать вопрос по дизайну решения с CUBE. Так, например, у маршрутизатора CISCO 881 есть WAN порт и LAN порт (-ы). CUBE сможет реализовать подключение к провайдеру только с WAN порта или сможет подключиться и с LAN порта? Вопрос в возможности работы на одном порту (LAN или WAN).

    Спасибо!

    ReplyDelete
    Replies
    1. Добрый день,

      Все зависит от того, какой тип подключения предоставляет провайдер. Если от прова приходит Ethernet, то можно и по LAN подключиться.

      CUBE - это возможность соединить между собой два VOIP звонка (VOIP Call Leg). Будет ли это работать с одним портом - можно сказать только, если глянуть на схему вашей топологии, чтобы понять как построена маршрутизация.

      Delete
    2. Здравствуйте Дмитрий!

      Например, такой случай. CUCM - 192.168.0.2, CUBE LAN port - 192.168.0.3 (маршрут по умолчанию - 192.168.0.1), шлюз в сети - 192.168.0.1. То есть CUCM подключается к CUME, а он в свою очередь подключается к SIP провайдеру выходя через шлюз по умолчанию. Таким образом все реализуется на одном порту.

      Спасибо!

      Delete
    3. Доброе утро,

      Думаю, что такая схема вполне будет работать. Однако, учитывайте, что могут быть проблемы, связанные с NAT (односторонняя слышимость, отсутствие разговора вообще).

      Delete
  24. Здравствуйте Дмитрий!
    Прежде всего хочу поблагодарить вас за ваш труд, он бесценен!

    Теперь к делу, настроен SIP Trunk, исходящие звонки проходят удачно, а вот со входящим проблема, короткие гудки, и в дебагах ошибки 1. SIP/2.0 407 Proxy Authentication Required 2. SIP/2.0 503 Service Unavailable, не подскажите в чем может быть проблема?

    ReplyDelete
    Replies
    1. Добрый вечер,

      Спасибо за Ваш отзыв. Чтобы ответить на Ваш вопрос, нужны дополнительные данные. Для начала объясните, пожалуйста, свою топологию (подключены с CUBE/без CUBE, на каком устройстве снимаете дебаг).

      В ближайшие 2 недели я смогу Вам отвечать и помогать только по вечерам. Так что заранее приношу извинения за задержки с ответами.

      Delete
    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. Не дождавшись ответа был запостен еще один пост по теме, прошу удалить его что бы не дублировать посты:)

      Delete
    3. Добрый день, Вусал!

      Проверьте, не включен ли у вас на роутере sip registrar (voice service voip -> sip -> registrar). Если включен, то это может быть причиной того, что запрашивается аутентификация.

      Для точной диагностики мне нужна конфигурация маршрутизатора, и снятый с него дебаг debug ccsip messages при входящем звонке. Напишите, пожалуйста, комент с адресом Вашей почты. Вечером я перешлю Вам свой адрес почты, и потом вышлете мне на него конфиг и дебаг.

      Хорошего дня!

      Delete
  25. день добрый, Дмитрий
    Очень надеюсь на Вашу консультацию.
    в связке ССМ -(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 ?

    ReplyDelete
    Replies
    1. Доброе утро,

      Думаю, что такое поведение 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 сеть.

      Delete
  26. утро доброе, спасибо за ответ.
    Дело в том, что на CUCM настроен MTP и на шлюзе он указан, так же на шлюзе указаны inbound и outbound faststart (g711ulaw, как раз из за этого и использовался именно pcmu). После указания 711alaw звонки пошли, но есть подозрение что попадись при вызове шлюз без поддержки alaw, звонок не пройдет. Посему вопрос, за что отвечает faststart ? насколько я понимаю, это команда заменяет sip early media в cisco ios. При этом, если снять галки faststart, но звонки часть звонков перестает ходить, а часть не передает RTP.

    ReplyDelete
    Replies
    1. Доброе утро,

      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.

      Delete
  27. Здравствуйте ,Дмитрий!Сможете подсказать , по Corporate directory почему телефоны 6941, 7941-7961 отображают только 31 элемент по поиску без условий , например по фамилии выводит найдено 31 из 535 , при нажатии далее , возможен только новый поиск сначала и снова список из первых 31 фамилии .Проверено на 2 разных кластерах CUCM 8.6 22900
    Хотелось бы что бы они выводили весь список сразу , либо при нажатии кнопки далее хотябы следующие по списку фамилии и так до конца

    ReplyDelete
    Replies
    1. Добрый день,

      К сожалению, не подскажу ничего с ходу по данной проблеме - еще с таким не сталкивался. Вполне возможно (это предположение), что за количество выводимых контактов на дисплей отвечает какой-то из сервисных параметров (Service Parameters) в настройках ССМ. Посмотрите, пожалуйста, сервисные параметры, может что-то удастся найти.

      Delete
  28. Дмитрий,добрый день.

    Спасибо за Ваш блог.
    У нас такая топология: CUCM 8.6.2-SIP-CUBE 2951-SIP-провайдер. В последнее время возникла необходимость расширить диапазон городских номеров, но наш провайдер этого обеспечить не может. Т.е. возникла необходимость подключиться к ещё одному провайдеру. Понятна схема с покупкой ещё одного CUBE 2921 и настроикой CUCM со звонками части абонетнов через одного провайдера, части через другого. Но денег жалко, не подскажите есть ли типовые решения для подключения двух SIP провайдеров к одному CUBE и как в этом случае заставить часть телефонов на CUCM звонить через одного определенного провайдера а части телефонов через другого?

    ReplyDelete
    Replies
    1. Доброе утро,

      Спасибо за Ваш отзыв. Я думаю, что нет необходимости покупать второй CUBE, все можно сделать и на одном, если, конечно, нет проблемы с IP-маршрутизацией и адресацией. CUBE может работать одновременно с шестью провайдерами.

      Для того, чтобы одни абоненты выходили через одного провайдера, а другие - через другого, необходимо сделать на CUCM 2 разных Rout Pattern и 2 разных сип-транка. Одна группа абонентов звонит через один роутпаттерн, вторая - через второй. Доступ у роутпаттернам ограничиваем с помощью CSS и Partition. Или же, вместо всего этого можно использовать Local Route Group.

      На CUBE нужно будет сконфигурировать 2 разных диал-пира - один в сторону одного провайдера, второй - в сторону другого.

      Я, конечно, описал все это в общих чертах. Чтобы описать более детально, нужно знать точнее ваши исходные данные. Система достаточно гибкая, и такие вещи, безусловно, позволяет реализовать.

      Delete
  29. Ну да я забыл упомянуть главную проблему. Провайдеры равнозначные и получается что диал пиры должны быть одинаковые как в сторону одного провайдера так и в стороны другого. Т.е. на CUCM все настраиваем как Вы описали, в итоге вызов попадают на шлюз и оба провайдера могут этот вызов обработать теоретически, но вызов от определенного Calling номера должен уйти через определенного провайдера. Т.е. необходимо некую фильтрацию на шлюзе по Calling номерам осуществлять в сторону провайдера или как-то задать жесткое соответствие что из SIP ТРАНКА 1 от CUCM вызовы уходят только на SIP транк к ПРОВАЙДЕРУ 1, а из SIP транка 2 от CUCM - на SIP транк к ПРОВАЙДЕРУ 2. Напрашивается вариант с введением кода выбора провайдера при наборе городского номера, но тогда прийдется объяснять людям что у одних код такой у других такой в итоге будет неразбериха.

    ReplyDelete
    Replies
    1. Можно предложить такой вариант - подставить код провайдера в СUCM (путем модификации Called-номера любым известным Вам способом: в роутпаттерн, в роутгруппе, в настройках шлюза или даже с помощью Translation Pattern).

      Т.е. пользователь как набирал, так и набирает себе номер, CUCM подставляет нужный код прова, далее на шлюзе делаем 2 разных диалпира, и при отправке вызова к прову код прова удаляем с помощью voice translation-profile.

      Другой вариант - это использование COR-листов на шлюзе. Однако, тут нужно точно знать, какой входящий диалпир выбирается на шлюзе при звонке с того или иного абонента (по критерию, например, answer-address). Такая конфигурация более сложна и требует четкого понимания выбора входящих диал-пиров.

      Delete
  30. Спасибо за совет. Попробуем реализовать первый вариант.

    ReplyDelete
  31. Здравствуйте Дмитрий!
    Скажите пожалуйста, если мы берем с провайдера по SIP-Trunk-у 10 номеров, как можно реализовать отдельные номера для каждого пользователя? Что бы каждый пользователь использовал свой номер при выходе в город и наоборот!?

    ReplyDelete
    Replies
    1. Доброе утро, Вусал!

      Такая штука реализуется с помощью модификаций вызывающего (Calling) и вызываемого (Called) номеров. Модификации номеров можно делать как в CUCM, так и на шлюзе в зависимости от того, где удобнее.

      Сценарии могут быть разные, но обычно делают вот что:

      1. Для исходящего звонка (в город) изменяют короткий внутренний Calling-номер на нужный длинный из плана провайдера. Также из номера Called удаляют код доступа к данному провайдеру (например, 9ка), если он набирался при звонке.

      2. Для входящего звонка (из города) изменяют длинный Called-номер из плана провайдера на короткий соответствующий номер внутреннего абонента. При желании можно также подставить в Calling-номер код выхода к данному провайдеру (это необязательно, а нужно лишь для удобства, чтобы внутренний абонент мог перезвонить автоматически на номер пропущенного входящего вызова).

      Описать в 2х словах все возможные варианты настроек невозможно, на это нужны отдельные посты, а в курсах циско в учебниках этому посвящены целые главы. Методы модификации номеров на шлюзах рассматриваются в курсе CVOICE, а методы изменения цифр на CUCM - в курсе CIPT1.

      Delete
  32. Доброго времени. Спасибо за статью.
    Есть вопрос. Связка у меня такая: 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

    симптомы такие: набираю номер, на вызываемом телефоне идет вызов и тут же обрывается.

    Куда копать?
    Спасибо заранее.

    ReplyDelete
    Replies
    1. Добрый день,

      Первый вопрос, который я Вам задам - это новое подключение или оно уже ранее работало?

      Ответ 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 есть соответствующие галочки. Надо проверить, включены ли они.

      Delete
  33. Enable Outbound FastStart выключено.
    Включил: http://gyazo.com/6d3fc2d8a40a049736e3fb05e81ad602

    Все тоже самое, дебаг не изменился.

    ReplyDelete
  34. вот что происходит когда звонят из города:


    .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


    и звонок так же отваливатеся, сразу занято...

    ReplyDelete
    Replies
    1. На входящем другая ошибка - 501.

      Хотелось бы взглянуть на конфиг 2811. Напишите в комменте адрес почты, я отвечу Вам в почте. В настоящее время веду курс CVOICE в Москве, через 10 мин начинаем, посему смогу отвечать в перерывах или когда будет свободное время.

      Жду от Вас коммент с адресом мыла.

      Delete
  35. Дмитрий, добрый день.
    Спасибо за полезный материал.. Хочу задать вопрос по поводу 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)
    по этой ошибке ничего полезного прогуглить не удалось.
    Помогите пожалуйста...

    ReplyDelete
    Replies
    1. Добрый день,

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

      Delete
  36. Можно тоже вопрос? Только по 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

    ReplyDelete
    Replies
    1. Добрый день, Сергей!

      Причину неуспешного звонка по SIP покажет, конечно же, дебаг (debug ccsip messages).

      Однако, судя по вашей конфигурации, причиной неуспешного звонка МЕЖДУ телефонами могут быть неправильные установки кодеков. Посмотрите: для одного телефона Вы установили кодек G711a, а для другого - G711мю. Циска воспринимает их как разные кодеки, и, соответственно, звонок не возможен.

      Установите одинаковые кодеки для обоих телефонов и попробуйте позвонить. Если не заработает, то включайте указанный дебаг, снова звоните, и присылайте результат дебага.

      Delete
    2. Спасибо, с локальными звонками разобрался - действительно, кодеки. Включая ещё присоединение другой подобной циски - там оказывается надо было кодеки указывать в каждом 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.

      Освободить порт удаётся только перезагрузкой роутера.
      Это само собой не дело.

      Как побороть эту ситуацию?

      Delete
    3. Можно ли как-то отбить зависший по непонятной причине voice-port из предыдущего примера? видимо из-за сбоя сигнализации R2-dtmf. Висит в состоянии "clearbak" и ничем кроме перезагрузки роутера не сбрасывается.

      Delete
    4. Странная ситуация, что не можете отбить зависший канал ничем, кроме как перезагрузкой. По идее, сброс voice port 0/1/0:0 (т.е. sh / no sh) должен помочь.

      Возможно, это просто баг IOS.

      Delete
    5. Я тоже думал, что 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), все без решения, так что баг древний.

      Delete
    6. Доброе утро, Сергей!

      Я с Вами абсолютно согласен. Это проблема Cisco, а не АТС, так как помогает перезагрузка шлюза, а не АТС! Увы, от саппорта можно частенько услышать подобные ответы. :(

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

      Delete
    7. Да, но увы - делать-то что-то надо. Сменить сигнализацию на АТС - не вариант, там на одной плате ещё десятки абонентов и сигнализация настраивается на всю плату целиком. И никто, кроме нашего подключения, проблем не знает, что интересно.
      И даже никаких таймаутов на отбой - так бы прописал безусловный таймаут на освобождение порта минут 10 и хоть как-то проблему закрыл бы :-(
      cas-custom тоже предлагает для этого типа сигнализации фактически один регулируемый параметр - длительность паузы между dtmf посылками.

      Delete
  37. Добрый день, такой вопрос,
    А что надо купить(лицензии,платы)
    чтобы 2911 использовать в качестве cuba? для sip провайдера

    ReplyDelete
    Replies
    1. 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

      Delete
  38. Добрый день,

    Нужно купить лицензии для 2911, поддерживающие войсовый функционал (иначе без лицензии, как Вы знаете, в IOS не будет войсовых команд). Платы покупать не надо.

    ReplyDelete
  39. Дмитрий, большое спасибо за статью. Недавно задался вопросом: а как чисто физически происходит подключение атс провайдера к магистральному оператору телефонии, если нужно например огромное количество линий? Неужели заводят кучу потоков Е1 в такой ситуации?

    ReplyDelete
    Replies
    1. Доброе утро,

      Для провайдерских сетей используется сигнализация ОКС-7 (SS7). В таких системах, используются все те же цифровые таймслоты (64кб/с). Голосовые таймслоты отделены от сигнальных. Но физически они объединяются в Е1, а потом несколько Е1 мультиплексируются в более сложные структуры - E2 (8,5 Mб/с), E3 (34Мб/с), E4 (139 Мб/с).

      Delete
    2. Получается, если магистральщик подает Е2 или выше, на приемной стороне нужно ставить мультиплектор и заводить в станцию отдельные E1, или может есть АТС, которые воспринимают потоки уровня иерархии выше единицы? Заранее спасибо.

      Delete
    3. Мне, к сожалению, очень мало довелось поработать на сетях провайдеров, поэтому точно ответить на Ваш вопрос я не смогу. Те провайдерские АТС, с которыми я сталкивался, имели интерфейсы Е1 и далее Е1 подавались в мультиплексоры (например, STM-1). Возможно, что есть и такие АТС, которые имеют и платы Е2.

      Delete
  40. Дмитрий, добрый день.

    У нас такая проблема - два 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-ю идею.

    ReplyDelete
    Replies
    1. Доброе утро,

      К сожалению, с ходу вот так не отвечу на Ваш вопрос. Попробуйте поискать возможные настройки среди Enterprise Parameters (для 1 идеи) или среди Service Parameters для служб Cisco Call Manager и IP Voice Media Streaming Applications (идея 2).

      В настоящий момент у меня нет под рукой ССМ, поэтому сам поискать не смогу :(

      Delete
  41. Спасибо за совет.

    ReplyDelete
  42. Дмитрий, а как в случае использования CUCME обходят ограничение в 15 правил, содержащихся в одном voice translation rules, если при звонке в город, т.е. при выходе с dial-peer voice voip в сторону провайдера нужно изменять 50 коротких внутренних номеров на 50 провайдерских?
    Получится ли в этом случае использовать не voice translation rules, а voice class sip-profiles?
    Еще задался вопросом, будет ли корректно отрабатывать для решения этой задачи добавление множества диалпиров к провайдеру, с clid network-number
    на каждом(городской номер), и одинаковыми destination-pattern, с ограничением по COR-листам?

    ReplyDelete
    Replies
    1. Да, это действительно проблема, если выходите к прову по 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 профилей и применяете на телефонах.

      Delete
    2. Дмитрий, а в этом случае номер будет транслироваться не только для внешних, но и для внутренних звонков?

      Delete
    3. Да, действительно... этот профиль ведь применится и для внутренних звонков тоже, что-то я об этом не подумал. :(

      Тогда можно попробовать поэкспериментировать с voice class sip profile, меняя заголовки SIP. Иначе придется конфигурить кучу диалпиров. Других вариантов пока не вижу...

      Delete
    4. Наверное самым рациональным будет комплексный подход: voice translation rules с 15 правилами + corlist'ы. Таким образом число диалпиров сократится с 50 до 4.

      Delete
    5. Ну не соглашусь, что только 4 диалпира нужно будет. Да, их будет 4, если вы не будете разделять права доступа абонентов к тем или иным направлениям связи (город, межгород, международный). В противном случае, диал пиров будет минимум 16.

      Delete
  43. Здравствуйте, Дмитрий!

    Огромное спасибо за статью! Опять я к вам с вопросом, никак не получается настроить 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)

    Денис.

    ReplyDelete
  44. Добрый день, Денис!

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

    ReplyDelete
  45. Добрый день, Дмитрий!
    Спасибо, за статью очен полезная!
    какие можно ли роутер 2811 использовать и как маршрутизатор и как CUBE? и какой IOS нужна для этого? с уважением. Рус

    ReplyDelete
    Replies
    1. Здравствуйте,

      Спасибо за Ваш отзыв. Конечно, можно использовать 2811 и как маршрутизатор, и как CUBE. По поводу IOS - можно использовать любой войсовый, который поддерживает функционал CUBE (посмотреть это можно с помощью Feature Navigator на cisco.com)

      Как вариант, подойдет IOS, содержащий в своем названии буквы ivs.

      Delete
  46. Здравствуйте, Дмитрий!

    Спасибо за ответ. Проблема оказалась в том, что нам сообщили неверный пароль :)

    Пользуясь моментом, хочу задать ещё один вопрос, правда не на тему 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

    ReplyDelete
    Replies
    1. Добрый вечер, Денис!

      Я думаю, что причиной такого поведения шлюза является то, что шлюз не принимает VoIP вызовы от устройств с неизвестными ему IP-адресами. Эта фича появилась в релизе IOS 15.0. Скорее всего, если Вы посмотрите дебаги таких неуспешных звонков, Вы увидете cause 127...

      Добавляя диал-пир 2, Вы указываете адрес встречной стороны, теперь этот айпишник известен шлюзу и он спокойно расценивает вызывающее устройство как известное и обрабатывает вызовы.

      Delete
    2. Действительно в 3845 с IOS 12.0 такой проблемы не наблюдается. В таком случае как же разрешить входящие звонки от устройств, в направление которых dial-peer не нужны? Создавать access list?

      Денис

      Delete
    3. Нет, ACL не нужен. Нужно сконфигурировать так называемый ip trusted list. Это, по сути, список доверенных айпишников, с которыми разрешается соединение по VoIP.

      Delete
    4. Более подробнее об этой функции тут:

      http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080b3e123.shtml

      Delete
    5. Огромное спасибо!

      Delete
  47. Добрый день Дмитрий,
    Спасибо за ответ.
    у меня такая ситуация. 1 большое здание разделенное на 2 крыла. на одном крыле CUCM 7 развернут а на втором крыле развернут IP PBX. LAN между крылами идет через 2811 который стоит на 2м крыле. задача соеденить SIP абонентов IP PBX 2 го крыла с абонентами CUCM.
    SIP абонент-----IP PBX ----2811---((облако сеть 1 го крыла)---CUCM7-----абоненты Cisco
    для этого обязательно нужен CUBE? и если да то 2811 могу сделать CUBE?
    Заранее спасибо
    Рустам

    ReplyDelete
    Replies
    1. Добрый день, Рустам!

      Если речь идет об общей корпоративной сети, где нет проблем с маршрутизацией и не ставится задача обеспечения безопасности (т.е., например, скрытия IP-адресов одного крыла от другого), в принципе, можно обойтись и без CUBE. Он тогда не нужен.

      CUBE обычно ставят на границе 2х разных IP-сетей, если одна из сетей вами не контролируется. Тогда да, CUBE нужен, однозначно. А если делать без CUBE, то нужно на ССМ создать SIP-транк, ну и настроить ту вторую АТСку, а также обеспечить IP маршрутизацию между ними для голоса и сигнализации.

      Delete
  48. Добрый день, Дмитрий!
    Спасибо за скорый ответ!
    Дело в том, что 2 крыла на разных подсетях и маршрутизация по IP настроена. конечно есть некоторые ограничения на некоторые подсети. IP АТС на базе виндоус 3сх и sip транк требует регистрации. а в CUCM не смог его зарегистрировать. если можно без CUBE настроить CCM с 3сх можете дать направление в какую сторону копать в CUCM?
    С уважением,
    Рустам
    arus80@inbox.ru

    ReplyDelete
    Replies
    1. Добрый день!

      Если требуется регистрация транка, то тут без CUBE никак не обойтись, даже во внутренней сети. Придется ставить, ССМ сам региться не умеет, увы :( Realm тут не поможет...

      Delete
  49. Добрый день, Дмитрий. Такой вопрос. Регистрируюсь у провайдера по SIP, дальше уходит на CUCM, все хорошо, но встает один вопрос - когда я регистрируюсь, то в таблице NAT появляется запись, пока она существует звонки входящие ко мне идут, как только запись пропадает, то все. Я понимаю что надо сделать обратный NAT, но можно ли как-то без обратного NAT-а, чтобы была отправка пакетов для обновлении этой записи трансляции. Сейчас вышел из положения путем уменьшением времени жизни регистрации, то есть до того как пропадет запись у меня клиент перерегистрируется у провайдера. Заранее спасибо.

    ReplyDelete
    Replies
    1. Добрый день, Александр!

      А что, если сделать статический NAT? Тогда такие записи будут в таблице постоянно. Или попробовать увеличить время хранения записей трансляции с помощью команды ip nat translation?

      http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr/command/ipaddr-i4.html#wp3178213110

      Delete
    2. Спасибо за ответ. Про NAT то понятно. Просто на идею без статического NAT меня сподвигли строчки из статьи Андрея Погребенника -
      "Проблема актуальна не только в период после регистрации пользователя: во время SIP-диалогов новые сообщения также могут не поступать в течение длительного промежутка времени, чего достаточно для того, чтобы запись из таблицы трансляции была удалена. Имеющиеся SIP-стеки решают эту проблему путём периодической посылки SIP-запросов re-INVITE, OPTIONS, INFO, NOTIFY или (при использовании UDP) дейтаграмм, не содержащих полезной нагрузки." (c) http://samag.ru/archive/article/2017
      Вот и задался данным вопросом. Решил спросить у Вас.

      Delete
    3. Добрый день, Александр. NAT - это абсолютное зло для IP-телефонии. В случаях, если есть возможность взять "белый" айпишник, то надо использовать CUBE, а не NAT.

      Спасибо за ссылку на статью, интересно. Почитаю на досуге. Сейчас веду курс в Алматы... :)

      Delete
  50. Добрый день, Дмитрий!
    Спасибо за ответ! вопрос можно ли сперва настроить SIP транк между IP PBX и CUBE без ССМ. то есть чтобы CUBE зарегистрировался на SIP PBX?
    С уважением,
    Рустам

    ReplyDelete
    Replies
    1. Добрый день, Рустам!

      Да, так сделать можно. С этим нет проблем. Настраивайте и регистрируйте сначала CUBE, потом настраивайте ССМ. Порядок не имеет значения.

      Delete
  51. Добрый день, Дмитрий!
    Спасибо, за ответ!
    Я настроил следующим образом но пока не регистрируется, где моя ошибка пожалуйста укажите.
    топология следующая:
    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

    ReplyDelete
  52. Думаю, что ошибка у Вас вот тут:

    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

    ReplyDelete
    Replies
    1. Дмитрий, спасибо за ответ, что то начало двигаться но дебаг дает следующие:
      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


      Регистрация не проходит
      С уважением,
      Рустам

      Delete
    2. Доброе утро, Рустам!

      Попробуйте изменить realm. У вас он указан как realm 10.21.3.150, а станция ожидает realm="3CXPhoneSystem" (это видно из дебага).

      Вам надо прописать в командах регистрации realm 3CXPhoneSystem

      Delete
  53. Добрый день.

    Имеется 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 без логина-пароля? Или я неверно диал-пир сделал?

    ReplyDelete
    Replies
    1. Доброе утро,

      СUBE поддерживает соединения по SIP и без регистрации. Поддерживает ли такой режим ваша новая АТС, или у нее есть только режим с регистрацией? Если только с регистрацией, то можно на вашем 3925 активировать СМЕ без проблем (думаю, что даже не потребуется дополнительная лицензия для этого),

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

      Если АТС поддерживает и транк без регистрации, то тогда нужно разбираться, почему не проходят звонки. Сначала нужно понять, какой диал-пир выбирается в качестве входящего (debug voip ccapi inout или debug voip dialpeer). Также нужно смотреть debug ccsip messages, чтобы увидеть причину отбоя.

      Delete
    2. Спасибо за ответ.

      ВОт мне говорят что на CME вроде как нужна до лицензия...

      Приведит,е пожалуйста, ссылку на это решение - регистрации SIP-телефонов сторонних производителей.

      >Также нужно смотреть debug ccsip messages, чтобы увидеть причину отбоя.
      В том и дело что пусто было просто в логах. Видимо потому что АТС пыталась зарегистрироваться, а такой функционал не включен (CME).

      Delete
    3. Доброе утро,

      Ссылка на пост о регистрации SIP-телефонов на СМЕ:

      http://dbenda.blogspot.com/2011/10/sip-call-manager-express.html

      Delete
  54. Добрый день Дмитрий!
    Спасибо огромное регистрация прошла успешно!
    теперь возникли с 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
    С уважением, Рустам

    ReplyDelete
    Replies
    1. Добрый день, Рустам!

      Думаю, что можно использовать 1 интерфейс, проблему это не должно вызывать, если его айпишник "виден" и со стороны ССМ, и со стороны IP PBX.

      По поводу диал-пиров: здесь надо понимать, отправляется ли вместе четырьмя цифрами 9ка или 8ка. Если да, то, тогда destination-pattern верно прописана. Если нет, то тогда нужно в destination-pattern сделать изменения.

      Delete
  55. Дмитрий, спсибо за скорый ответ!
    9ка и 8ка не должны отправляться! то есть абонент со стороны CCM выходит в сторону PBX через 9ку и наоборот абоненты PBXа в сторону CCM через 8ку. при этом чтобы они могли звонить на любой существующий номер друг друга .
    С уважением,
    Рустам

    ReplyDelete
    Replies
    1. В таком случае и диалпиры должны содержать 4х значные destination-pattern. Только нельзя в обоих писать просто .... Тут все зависит от нумераций на АТС и на ССМ. Если они не пересекаются, то все просто. Ну а если пересекаются, т.е начинаются на одинаковую цифру, то тогда нужно пересылать и 9ку и 8ку. По-другому никак не получится.

      Delete
    2. Добрый день, Дмитрий!
      Нумерация на АТСке и 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 видят друг друга или нет?
      С уважением,
      Рустам

      Delete
    3. Доброе утро, Рустам!

      Диалпиры прописаны правильно, однако в приведенном дебаге не видно, что звонок проходит через CUBE к ССМ (должен быть отправлен INVITE в сторону ССМ).

      Проверьте, прописаны ли в конфиге CUBE следующие команды:

      voice service voip
      allow-connections sip to sip

      Delete
    4. Дмитрий здравствуйте,
      Спасибо за ответ, в конфиге 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 пингуется.
      С уважением,
      Рустам

      Delete
    5. А да, действительно, инвайт уходит на ссм, прсмотрел я его, сори. Не проснулся еще, утро в Москве :)

      Теперь нужно проверять настройки на ССМ. Я полагаю, что сип-транк на ССМ у вас настроен, верно? В первую очередь, надо сверить айпишник, установленный на сип-транке . Также нужно проверить транспорт (TCP/UDP), установленный на ССМ для SIP-сообщений. От CUBE они уходят с транспортом UDP. Нужно, чтобы такой же транспорт был и на ССМ.

      Delete
    6. Дмитрий, спасибо за ответ.
      настройки 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 нет.
      истина где то рядом.

      Delete
    7. А пингуется ли 10.21.3.151 с ССМ? В командной строке ССМ для пинга нужно использовать utils network ping 10.21.3.151.

      Delete
    8. Да пингуется!

      Delete
    9. Дмитрий, добрый день,
      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.

      Delete
    10. Добрый день, Дмитрий! Связь с 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.

      Delete
    11. Добавление к предыдущему сообщению часть 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

      Delete
    12. А Вы в обоих строчках (credentials и auhentication) поменяли realm на правильный? Или сделали это только для строки credentials?

      Realm должен быть правильный в обеих строках.

      Delete
    13. Добрый день, Дмитрий!
      реалм в обоих строках одинаковый
      вот полная конфиг-я
      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

      Delete
    14. Вот дебаг в обратную сторону с АТСки в сторону 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

      Delete
    15. Добрый вечер,

      В этом дебаге видно, что звонок до ССМ все же доходит, он пытается его обработать, однако отвечает сообщением 404 с каузой 1 (несуществующий номер).

      Проверьте на сип-транке в ССМ, правильный ли на нем установлен СSS. Этот CSS должен содержать в себе партицию телефона 1126.

      Delete
  56. А не подскажете, куда копать в таком случае: если я прописываю диалпир в сторону другой 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 на дальней стороне).

    ReplyDelete
    Replies
    1. Добрый день, Сергей!

      Проблема явно сетевая тут. А пинги в туннель уходят? Сам туннель-то работает (protocol is up)?

      Delete
    2. Да, конечно. Я же пишу, что всё поднято, адреса пингуются, и с явным указанием исходных тоже. Правда странно, что не работает tracert дальше дальнего конца туннеля, но пинги ходят на ура, ftp и ssh тоже проверено - по туннелю летает.

      Delete
    3. Не подскажу так, увы... :( Топологию бы нужно знать, что там и как. А вслепую... ну только гадать на кофейной гуще. :(

      Могу однозначно сказать, что по L2TP телефония работает. Мы часто используем L2TPv3 для удаленных лаб.

      Delete
    4. Топология простая:
      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
      - не помогло.

      Delete
    5. Bind-команды используются только для телефонных функций, на маршрутизацию они никак не повлияют, поэтому их прописывание ничего не дало.

      А диал-пиры Вы прописываете на этом же 2901, на котором поднят L2TP?

      Delete
    6. Нет, на соседнем.
      То есть полная схема так:
      2901 с телефонами и диалпирами
      - 2901 коммуникационный, тут же реальный IP и L2TP,
      затем туннель,
      на дальнем конце туннеля клиент в LTE роутере,
      дальше 2901 с телефонами.
      Пинги ходят на ура.
      В LTE роутере в фарйволе прописал на всякий случай пропускать через туннельный интерфейс всё и всюду.

      Delete
    7. Можно взглянуть на конфиг, отвечающий за L2TP на 2901?

      Delete
    8. 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

      Delete
  57. Кстати может иметь значение, что на разнесённых площадках одинаковые внутренние номера? 100,101....115
    А входящий номер который прописан диалпиром 332 назначен на удалённой площадке на hunt-group.

    ReplyDelete
    Replies
    1. Для телефонной маршрутизации это, конечно, имеет значение, обычно это решается путем использования кодов внутренних АТС (например, на обоих сторонах нумерация 1ХХ, одна АТС имеет код 11, вторая 12, набираются при звонках между АТС 11-1ХХ и 12-1ХХ соответственно).

      Но тут, видимо, проблема все же в маршрутизации сетевой (Вы же пишите, что телефонный трафик не попадает в туннель L2TP). ACL никаких, случайно, на пути телефонного трафика нет? Если это Н323, то открыты ли порты 1719, 1720 (TCP обычно)?

      Delete
    2. Разобрался. Оказывается, мало настроить маршрутизацию между цисками, надо ещё и между телефонами (!). Додумался до этого, только увидев в логе вместо адреса второго роутера адрес тамошнего телефона.

      Delete
    3. :) поздравляю :) Однако, не совсем понятно. Да, маршрутизация между телефонами нужна, безусловно, иначе не будет ходить голосовой трафик. Но сигнализация то должна ходить между двумя телефонными 2901, и для нее маршрутизация между телефонами не нужна, по идее. Если бы не было маршрутизации между подсетями телефонов, вы бы получили отсутствие голосового трафика, но звонок бы проходил.

      Если найдете время, был бы Вам признателен за пояснения. Интересный просто случай.

      Delete
  58. Здравствуйте!
    Интересная ситуация, раньше с таким не сталкивался:
    один и тот же абонент CUCM (на шлюзе VG224) несколько раз подряд набирает один и тот же городской номер, вызовы идут по одному и тому же маршруту, но CUCM к другой станции шлет INVITE иногда с SDP, иногда без. Маршрутизация по времени не используется. В трейсах 2 инвайта отличаются только наличием поля Message Body. С чем это может быть связано?
    С уважением, Евгений.

    ReplyDelete
    Replies
    1. Добрый день, Евгений!

      Invite c SDP и без SDP означает разные режимы работы сигнализации SIP - Early Offer и Delayed Offer соответственно. Скажите, установлена ли на SIP-транке галочка MTP required (Media Termination Point Required)?

      Delete
  59. Спасибо за ответ.
    Галка установлена, MRG-list выбран. Версия CUCM 7.
    Такая же ситуация наблюдается при транзитном вызове через CUCM с MGCP-шлюза (там подключена по DSS1 другая станция) в SIP-транк: INVITE уходит то c Early Offer, то с Delayed Offer без всякой закономерности.

    ReplyDelete
    Replies
    1. Может недостаточно МТР ресурсов? Посмотрите в RTMT (счетчики) сколько имеется МТР и какова их загрузка.

      Delete
    2. Дмитрий, спасибо за помощь!
      Действительно не хватает ресурсов MTP.

      Delete
  60. Добрый день!

    помогите решить проблему, пожалуйста.

    подключено от 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

    в остальном все по прежнему

    ReplyDelete
  61. Доброе утро, Сергей!

    Запросы на регистрацию уходят, это видно в логе. Но! Посмотрите, что циска отправляет:

    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

    ReplyDelete
    Replies
    1. попробовал. результат тот же:

      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

      Delete
    2. Попробуйте поменять 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 на другой.

      Delete
    3. Вы были правы! изменил Realm и все заработало!

      Это, я как понимаю, параметр вообще не зависит от IP или DNS-имени sip-сервера (как я думал). потому как dns-имя сервера в моем случае pbx.hypernet.ru

      Благодарю за помощь!

      Delete
    4. Пожалуйста! :)

      Рад, что все заработало.

      Delete
  62. А можно вопрос почти в тему?
    У меня задача: привязать 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 что не пишу - диалпир все равно выбирается случайным образом из восьми аналогичных.

    ReplyDelete
    Replies
    1. Доброе утро, Сергей!

      Критерий answer-addres не работает при выборе ИСХОДЯЩЕГО диал-пира. Он применяется только для выбора ВХОДЯЩЕГО диал-пира.

      Вашу задачу можно решить путем использования COR-листов. С их помощью можно разрешить или запретить доступ на тот или иной диал-пир. Вот и получится (при правильной их настройке, конечно), что телефон будет занимать при исходящем звонке нужный диал-пир, и, соответственно, нужный FXO-порт.

      Delete
    2. Спасибо за указание направления - часто именно этого не хватает, как Вы несомненно знаете :-)
      Вот незадача только - нашёл букварь
      http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a008019d649.shtml
      делаю по нему и сразу же после создания тегов и листов напарываюсь, что в SIPовских voice register dn нету слова cor !
      Как из этого выпутаться? стандартный приём с заворачиванием вызова на loopback и превращение его во входящий voip?

      Delete
    3. Извиняюсь. нашёл. Оказывается для SIP оно в voice register pool находится.

      Delete
    4. Так... исходящие звонки поборол, теперь нарисовалась проблема со входящими.
      Оказывается, при конфигурации проброса
      !
      voice-port 0/0/0
      connection plar 125
      !
      циска сразу при поступлении вызова на порт ПОДНИМАЕТ ТРУБКУ на этом порту, и дальше выдаёт свои сигналы КПВ и отбоя. Вот только проблема - если абонент не ответил и вызывающий абонент положил трубку, то циска не освободит порт и будет названивать внутреннему абоненту пока не истечёт таймаут.
      Можно ли как-то заставить циску в такой конфигурации не снимать трубку на FXO порту, пока не поднимет трубку вызываемый абонент?

      Delete
  63. Я бы попробовал настроить так:

    voice-port 0/0/0
    connection plar opx 125

    А вообще, отбой на FXO, когда абонент удаленной АТС положил трубу - это известный головняк (и не только Cisco, но и других АТС с портами FXO или, как их еще называют, Universal Trunk). Отчасти побороть это можно с помощью функции Busy Tone Detection (BTD), но это не всегда спасает.

    ReplyDelete
    Replies
    1. Думаю, сильно помогло бы изменение логики работы - чтобы циска не поднимала трубку на порту FXO, пока не поднимет трубку вызываемый абонент.

      Delete
    2. Так по идее, когда настроен параметр opx (т.е connection plar opx 125), то трубка циской не снимается, пока не ответит абонент. Разве не так?

      Delete
  64. А можно ещё вопрос для случая с SIP телефонами и их привязкой к FXO портам?
    Наметилась проблема, что при отсутствии какого-то SIP телефона в сети вызов, поступающий на FXO порт, тут же маршрутизируется циской, не находящей этот номер, на другой FXO порт.
    Пример: SIP телефоны имеют номера 125-132. Соответственно на FXO портах прописано "connection plar 125" и далее до 132. Но если SIP телефона не оказывается в сети, то циска отправляет вызов по FXO порту обратно в АТС, поскольку на портах destination-pattern 1..
    Пока придумал только, что SIP телефоны надо вынести за пределы нумерации АТС, скажем сделать в циске 4-значную нумерацию или 2.., а разруливать опять диал-пирами. Так?

    ReplyDelete
    Replies
    1. Доброе утро, Сергей. Извините за задержку с ответом. Не до блога было в последние дни, если честно.

      При такой конфигурации, как Вы описали, циска работает совершенно правильно. Так и должно быть. Попробуйте сделать вот что:

      voice register dn 1
      number 125
      huntstop

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

      Хотя, конечно, лучше избегать таких пересекающихся номерных планов и дать ип-телефонам отдельную нумерацию (2хх, 3хх итп).

      Delete
  65. И ещё непонятный глюк: я использовал два FXS порта для проброса удалённой внешней линии на аналоговую АТС.
    В посёлке, где стоит удалённый voip шлюз на cisco 1760, нумерация 5-значная, и импульсный набор, поэтому connection plar для исходящего соединения не работает - в таком режиме нет импульсного донабора в посёлок. Пришлось принимать номер на циску, маршрутизить звонки диалпирами, чтобы на выходе циска донабирала городской номер сама. Всё работало, пока не захотел привязать исходящую линии АТС к исходящегму порту на дальнем конце. Пошёл стандартным путём: translate rule на порту с приписыванием спереди одной цифры (6 или 7), затем маршрутизация на нужный порт диалпиром с паттерном 6..... или 7..... и обрезка 5 передаваемых цифр.
    Так вот, тут почему-то на входе FXS перестал приниматься длинный номер, а стал отбиваться после второй (!) цифры. Почему именно второй - я так и не понял, все внутренние номера и паттерны трехзначные.

    ReplyDelete
    Replies
    1. Если честно, то я пока не понял саму задачу :( Неплохо бы от Вас получить картинку с описанием. Ну и конфиги, естественно (или куски конфигов). Потому, что я пока не совсем понимаю, о каких донаборах идет речь :(

      Пришлите мне, пожалуйста, через форму связи свой мейл, я Вам отвечу, а потом уже через почту пришлете картинки.

      Delete
  66. Дмитрий добрый день!
    Имеется следующая конфигурация
    Ростелеком (Неофон 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

    ReplyDelete
    Replies
    1. Добрый день, Евгений!

      Я так думаю, что "фаст-бизи" Вы слышите потому, что в INVITE приходит звонок не на телефонный номер, а на имя:

      INVITE sip:gazprom-neft@212.20.63.125:5060

      Шлюз не умеет обрабатывать входящие звонки по именам. :( Нужно, чтобы пров слал входящий звонок на телефонный номер, если это возможно.

      Delete
    2. Единственное, что тут могу посоветовать - это попробовать поисследовать тему подмены заголовков SIP. Т.е заменить имя в инвайте на один из номеров циски. Я совершенно точно знаю, что подмена заголовков возможна в исходящих (от циски) сообщениях SIP.

      Но вот можно ли сделать подмену заголовков во входящих сообщениях SIP, я ответить пока затрудняюсь/ Давненько это делал, и на память просто не помню.

      Погуглите на эту тему, например, о voice class sip или sip header change cisco.

      Если найдете решение, буду рад о нем узнать, поэтому, был бы благодарен за обратную связь.

      Delete
    3. У меня аналогичная, проблема.
      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 - когда я его добавила, почему?

      Delete
    4. Здравствуйте, Вас не Екатерина, случайно, зовут? Вы не писали мне через форму связи?

      Если да, то я не забыл о Вашем вопросе. Я сегодня разговаривал с инженером Cisco TAC. Он мне сказал, что вроде как в новых релизах Cisco IOS появилась возможность принимать звонки и по именам тоже.

      Сегодня вечером я разберусь, как это сделать и опишу/дам ссылки на материал.

      Delete
    5. По поводу параметра number - шлюз, действительно, будет использовать его для регистрации. Думаю, что в этом случае используется такая же схема регистрации, как и для SIP- телефона. Т.е номер, имя пользователя и пароль.

      По такому же принципу на СМЕ/ССМ регятся сип-телефоны стороннего вендора (не циско)

      По поводу 403 Forbidden - пришлите, пожалуйста, debug ccsip messages. Я хочу понимать, отправляет ли шлюз звонок на ССМ или нет.

      Delete
  67. Да, это я.

    лог:
    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

    ReplyDelete
    Replies
    1. По дебагу вижу, что шлюз звонок далее на ССМ не отправляет (нет второго инвайта в сторону ССМ). Поэтому, в первую очередь следует проверить следующее:

      voice service voip
      allow-connections sip to sip

      Сконфигурировано ли это на шлюзе?

      Delete
    2. Конечно.
      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 прямо в КЦ и этот единственный с регистрацией - не пропускает входящие ни в один из имеющихся транков без регистрации...

      Delete
    3. Я не думаю, что дело тут в регистрации. Шлюзы циско прекрасно пропускают входящие звонки и без регистрации. К тому же, если смотреть со стороны провайдера, его транк тоже не зарегистрированный.

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

      В связи с этим, вопрос следующий - прописан ли айпишник прова в ip trusted list?

      Delete
  68. Здравствуйте, Дмитрий. Слушал в 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″

    но чуда не произошло.

    ReplyDelete
    Replies
    1. Здравствуйте,

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

      Вообще, идея, описанная в приведенной Вами ссылке, правильная. Важно только правильно применить сип-профиль. Он должен быть установлен на ИСХОДЯЩЕМ диал-пире, который отправляет звонки со шлюза на ССМ.

      Delete
    2. Я бы и сам на стенде попробовал собрать, а чем можно смоделировать такое поведение SIP-провайдера, чтобы подставить нужные поля в нужные заголовки SIP? asterisk-ом ?

      Delete
  69. Доброго дня!
    У меня такая проблема.
    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?

    ReplyDelete