Вы здесь

Главная › Форумы › VoIP

CUBE и SRST

вт, 15/09/2015 - 23:13 — Dronskiy
Форумы: 
VoIP

Возможно ли в режиме SRST, перенаправлять звонки на SIP провайдера (SIP-UA). Для ISDN все работает, а вот по SIP нет

ср, 16/09/2015 - 02:06 — vs

Да, конечно. По сути режим SRST это CME, работающий во время недоступности основного CUCM

чт, 24/09/2015 - 19:28 — Dronskiy

Не получается настроить входящие вызовы. Возможно ли прописать dial-peer для режима SRST не в секции call-manager-fallback, а как обычный dilal-peer с меньшим приоритетом

dial-peer voice 1 voip
session target ipv4:CUCM1

dial-peer voice 2 voip
preference 1
session target ipv4:CUCM2

dial-peer voice 3 voip
preference 2
session target ipv4:SRST-ROUTER

чт, 24/09/2015 - 19:35 — vs

Да, конечно это должны быть диалпиры
Обычно SRST-роутер и шлюз выхода в город совпадают. У вас нет?
И конфигурация может быть немного разная в случае использования MGCP + SRST, либо SIP + SRST

чт, 24/09/2015 - 22:00 — Dronskiy

Гейтвей и SRST роутер одно устройство
Вот так заработало

dial-peer voice 4 voip
translation-profile incoming INBOUND
preference 3
destination-pattern 6673
session target ipv4:10.15.20.250 (Loopback роутера c CUBE)
incoming called-number XXXXXXXXXXXX
voice-class codec 1
dtmf-relay rtp-nte
ip qos dscp cs3 signaling

пт, 25/09/2015 - 13:59 — vs

Не совсем верно. С таким конфигом вы получите лишнюю ногу.
У себя я делаю входящие так:

voice translation-profile ITSP_Incoming
 translate calling 2
 translate called 1
!
voice translation-rule 1
 rule 1 /^23035$/ /3357/
!
voice translation-rule 2
 rule 1 /\(^..........$\)/ /+7\1/
!
dial-peer voice 1 voip
 description Incoming-Dialplan
 translation-profile incoming ITSP_Incoming
 session protocol sipv2
 session target sip-server
 incoming called-number 23035
 voice-class codec 1  
 dtmf-relay rtp-nte
 ip qos dscp cs3 signaling
!
dial-peer voice 500114 voip
 description internal to CUCM
 preference 5
 destination-pattern [1-4]...
 session protocol sipv2
 session target ipv4:10.100.65.11
 voice-class codec 1  
 voice-class sip bind control source-interface Loopback0
 voice-class sip bind media source-interface Loopback0
 dtmf-relay rtp-nte
 ip qos dscp cs3 signaling
 no vad

Входящие звонки идут на номер 23035.
23035 сразу транслируется на внутренний 3357 и уходит на CUCM IVR через dial-peer 500114. При этом на самом CUCM 3357 в свою очередь транслируется на реальный номер IVR например 3300.
Зачем так сделано:
3357 - это номер местного секретаря.
В случае недоступности CUCM телефоны зарегаются на этот роутер, включая и тел секретаря. Поскольку теперь на роутере зареган 3357 как более точный шаблон, входящие звонки будут валиться непосредственно на секретаря. Таким образом SRST обеспечит и работу внутренней связи и приём входящих.

пн, 28/09/2015 - 16:08 — Dronskiy

Спасибо. У меня доступность CUCM проверяется keepalive на dialpeer и если связь падает то отрабатывает SRST dialpeeer с большим preference

dial-peer voice 1 voip
destination-pattern 883140776......
session protocol sipv2
session target ipv4:CUCM
voice-class codec 1
voice-class sip options-ping 60
voice-class sip options-keepalive

dial-peer voice 4 voip
translation-profile incoming INBOUND
preference 1
destination-pattern 6673
session protocol sipv2
session target dns:SIP-ISP
incoming called-number 883140776......

пн, 05/10/2015 - 21:03 — Dronskiy

Чтоб два раза не вставать )))
Пытаюсь настроить CUBE для работы внутри vrf. Есть два ISP, каждый из них убран в отдельную vrf, интерфейс в сторону пользователей тоже в своей vrf (все это сделано для корректной работы spoke-spoke dmvpn c 2мя isp).
Маршрут от провайдеров реплицируется в пользовательский vrf.

cube.jpg

Так как voice vrf может быть только один. Я биндю sip на внутрений интерфейс и пробрасываю 5060 внутрь. 

voice vrf Lan
!
voice service voip
 ip address trusted list
 sip
  bind control source-interface Port-channel1.20
  bind media source-interface Port-channel1.20
!
interface Port-channel1.20
 description VOICE
 ip address 10.15.20.250 255.255.255.0
 encapsulation dot1Q 20
 vrf forwarding Lan
!
sip-ua 
 credentials xxxxxxxxx
 registrar 1 xxxxxxxxx

#show sip-ua connections udp detail 
-------------- SIP Transport Layer Listen Sockets ---------------
  Conn-Id               Local-Address             
 ===========    ============================= 
   2            [10.15.20.250]:5060:Lan
пт, 09/10/2015 - 16:55 — vs

Если не секрет, можно поподробней, почему вы выбрали путь именно с vrf для работы с двумя ISP?
И как реализовано переключение на резервный (интернет, туннели).

пн, 03/10/2016 - 04:24 — Eterm (не проверено)

Пытаюсь сейчас настроить такую же схему, когда 2 врф на 2 провайдер. Телефоны заставил звонить и разговаривать друг с другом. Но вот проблема в том, что не могу заставить звонить и принимать звонки от сип провайдера. не подскажите, куда смотреть?

пн, 03/10/2016 - 16:56 — Нкк (не проверено)

ИМХО с цискиным SIP-ом и так хватает причуд и гемора. Всё это ещё помножить на 2ВРФ имеет смысл разве что ради академического интереса.

пт, 09/10/2015 - 17:46 — Dronskiy

При в взаимодействии с другим споком у которого тоже 2 ISP, когда падает один из провайдеров на одном, а у второго спока default route и активный туннель остается в то же облако dmvpn,то не строится isakmp через 2 второго провайдера от первого спока, т.к второй спок отвечает через default маршруту, команда tunnel route-via xxx mandatory не влияет на isakmp. Можно решить прописыванием дефолтов до вторых ISP или vrf. Я в итоге сделал через ip local policy route-map

вт, 13/10/2015 - 03:15 — toxa (не проверено)

А переключать через IP SLA не пробовал?
Хотя главное чтоб работало

вт, 13/10/2015 - 15:28 — Dronskiy

Под ip local policy не попадает esp и соответственно туннель поднимается а трафик не идет.
Думаю уже отказаться от Phase2-3 на этой площадке.

По умолчанию на всех споках default-route через облако red. Допустим на споке 1 падает основной провайдер. При связи со споком 2 , спок 1 инициирует isakmp через провайдера blue, но так как на спок 2 default по прежнему через red нечего не работает
Можно побороть 2 мя способами:
1. Прописыванием статики до всех внешних адресов резервного провайдера (не всегда возможно и геморой)
2. Через VRF - http://www.cisco.com/c/en/us/support/docs/security-vpn/dynamic-multi-poi...

Второй вариант хорош но не учитывает ситуации если в инет выходят прямо через спок (борется 3им vrf) и route-replicate в него. Но при таком варианте не работает CUBE

To toxa
Как мне поможет ip-sla?))

вт, 13/10/2015 - 16:08 — toxa (не проверено)

"По умолчанию на всех споках default-route через облако red. Допустим на споке 1 падает основной провайдер. При связи со споком 2 , спок 1 инициирует isakmp через провайдера blue, но так как на спок 2 default по прежнему через red нечего не работает"

Через IP-SLA мы можем точно отслеживать состояние провайдера RED, и менять шлюз на резервный при падении основного. Это будет третий способ как побороть проблему переключения. У меня именно так и работает

Хотя решение через VRF очень интересно.

вт, 13/10/2015 - 16:20 — toxa (не проверено)

Да, и ситуация, когда один из филиалов работает на резерве (BLUE): в этом случае общение филиала с другими идет через центральные роутеры, где через EIGRP контактируют два облака RED и BLUE

вт, 13/10/2015 - 15:29 — Dronskiy

вт, 13/10/2015 - 15:29 — Dronskiy

dmvpn.jpg

вт, 13/10/2015 - 16:37 — Dronskiy

На каждом споке все правильно есть sla и floating route. На спок1 провайдер red упал,default роут переключился на blue, а на втором споке по прежнему default red. И если у тебя работает то только через hub и то если сессию начнет устанавливать спок2, а если спок1 то вообще нечего не поднимется

вт, 13/10/2015 - 21:23 — toxa (не проверено)

Почему на спок1 ничего не поднимется? Маршруты сделаны на динамике EIGRP. Если умер основной провайдер, то маршруты через RED умрут через 15с (Hold). Далее маршруты пойдут только через резервный туннель blue. Если хочешь могу сделать эксперимент. только подробно опиши откуда и куда протестить пакеты.

Я лично обнаружил другую проблему: Изначально я вообще не планировал использовать IP SLA, и в филиале прописать два разных IP центра через разные статические маршруты. Но получилась следующая беда - если умирал основной, то по резервному оставался только статический на HUB, а вот связь до филиалов пыталась идти напрямую и умирала, а т.к. до белых IP филиалов маршрутов не было, то реально доступен был лишь центр. В итоге пока единственным рабочим решением стало смена дефолта через IP SLA.
Очень бы хотелось отказаться от смены дефолта, поскольку от этого зависит и провайдер для интернета юзеров, - а в идеале бы юзеров пустить по одному ISP, а туннели по другому.
Решает ли эту проблему использование vrf-lite?

Добавить комментарий

Более подробная информация о текстовых форматах

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Допустимые HTML-теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и абзацы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и абзацы переносятся автоматически.
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.
Target Image