06-23-2020 05:30 PM
I have two CUSP that I send calls to using Dial-Peer Voip. I can send calls to either CUSP-A or CUSP-B, but preferably I would like to be able to send calls to the CUSP-A first and then in the event CUSP-A is unreachable send calls automatically to CUSP-B. The CUBE is an older 2821 that does not have the Voice Class Server Group feature, is it possible to still use SIP Options Ping in the dial peer and by using Preference in dial peers be able to send calls to CUSP-B if CUSP-A is down?
So two identical dial peers (lets say 101 and 102) with the same destination patterns but different session target for each CUSP. 101 will have Preference 1 with session target as CUSP-A and SIP Options Ping enabled, 102 will have Preference 2 with session target as CUSP-B. So if CUSP-A is unreachable, will dial-peer 101 busy out and hence calls will be routed to CUSP-B via dial peer 102?
06-23-2020 08:46 PM
Hi,
Yes that would be the way to do it.
Use preference to choose which cusp you prefer and then use OPTIONS ping go monitor it's state and when it's unreachable, CUBE won't bother sending calls to it. I would advise that you should enable OPTIONS ping on both dial peers
06-24-2020 08:34 AM
Thank you very much. I have a another question, on my 4431 CUBE I built a server group with both CUSP, and I built a sip-options-keepalive profile. However, when I show the keepalive the OOD SessID shows 3 and 4 instead of 1 and 2 (see below). Also, what should a basic SIP profile look like to be used to send the SIP Options message. Right now my SIP profile is 0, is that ok?
ALP-4431-VGW3#sho voice class sip-options-keepalive 45
Voice class sip-options-keepalive: 45 AdminStat: Up
Description: ping option to CUSP servers
Transport: tcp Sip Profiles: 0
Interval(seconds) Up: 30 Down: 40
Retry: 6
Peer Tag Server Group OOD SessID OOD Stat IfIndex
-------- ------------ ---------- -------- -------
7145 45 Active 428
Server Group: 45 OOD Stat: Active
OOD SessID OOD Stat
---------- --------
3 Active
4 Active
OOD SessID: 3 OOD Stat: Active
Target: ipv4:10.240.28.45
Transport: tcp Sip Profiles: 0
OOD SessID: 4 OOD Stat: Active
Target: ipv4:10.242.28.45
Transport: tcp Sip Profiles: 0
------------------------------------------------------
ALP-4431-VGW3#sho voice class server-group 45
Voice class server-group: 45
AdminStatus: Up OperStatus: Up
Hunt-Scheme: preference Last returned server:
Description: CUSP servers for Dialer Refer dial peers
Total server entries: 2
Pref Type IP Address IP Port
---- ---- ---------- -------
1 ipv4 10.240.28.45
2 ipv4 10.242.28.45
-------------------------------------
06-24-2020 09:41 AM
This is how it looks on one of the gateways that we have.
selurt-voip-01#sh voice class sip-options-keepalive 1 Voice class sip-options-keepalive: 1 AdminStat: Up Description: Used for Server Group SIP OPTIONS PING Transport: system Sip Profiles: 0 Interval(seconds) Up: 60 Down: 30 Retry: 5 Peer Tag Server Group OOD SessID OOD Stat IfIndex -------- ------------ ---------- -------- ------- 1010 1 Active 207 Server Group: 1 OOD Stat: Active OOD SessID OOD Stat ---------- -------- 1 Active 2 Active 3 Active OOD SessID: 1 OOD Stat: Active Target: ipv4:10.64.160.32 Transport: system Sip Profiles: 0 OOD SessID: 2 OOD Stat: Active Target: ipv4:10.64.160.33 Transport: system Sip Profiles: 0 OOD SessID: 3 OOD Stat: Active Target: ipv4:10.64.160.34 Transport: system Sip Profiles: 0 ------------------------------------------------------ selurt-voip-01#sh voice class server-group 1 Voice class server-group: 1 AdminStatus: Up OperStatus: Up Hunt-Scheme: preference Last returned server: Description: Inbound calls from PSTN to SELU CUCM Total server entries: 3 Pref Type IP Address IP Port ---- ---- ---------- ------- 1 ipv4 10.64.160.32 2 ipv4 10.64.160.33 3 ipv4 10.64.160.34 -------------------------------------
Your order with 3 and 4 looks odd, possibly a IOS defect or something. The SIP profile 0 is the same as for mine, so that looks okay.
06-24-2020 12:51 PM
@Roger KallbergSo we look pretty much the same except that order with 3 and 4. Will tinker around some more and see. Thanks for your response.
06-25-2020 07:37 AM
So this is strange or maybe it's normal. I deleted my previous keepalive profile and built a new one and new dial peer, now it shows 5 and 6
ALP-4431-VGW3# sho voice class sip-options-keepalive 500
Voice class sip-options-keepalive: 500 AdminStat: Up
Description: Heartbeat Failover for CUSP servers
Transport: tcp Sip Profiles: 0
Interval(seconds) Up: 30 Down: 40
Retry: 6
Peer Tag Server Group OOD SessID OOD Stat IfIndex
-------- ------------ ---------- -------- -------
500 500 Active 429
Server Group: 500 OOD Stat: Active
OOD SessID OOD Stat
---------- --------
5 Active
6 Active
OOD SessID: 5 OOD Stat: Active
Target: ipv4:10.240.28.45
Transport: tcp Sip Profiles: 0
OOD SessID: 6 OOD Stat: Active
Target: ipv4:10.242.28.45
Transport: tcp Sip Profiles: 0
06-26-2020 06:32 AM
I don't think those numbers indicate preferences, maybe just an index for each server, incremented when each server is defined. You might well find that after a reload it goes back to 1 and 2. Equally if you created another server group, maybe it will show 7 and 8.
By the way, I thought I'd already made this suggestion but if you have failover between two outbound ITSPs then I think it's worth tweaking the SIP retries and timers so if your preferred ITSP connection goes down you don't have too long a delay on outbound calls until the dial peer options time out. Defaults of six retries and 500 ms timeout amount to over 30 seconds delay.
06-26-2020 02:02 PM
Cisco TAC says no worries, these SessionID numbers are random and the configs will work as is.
Thank you all.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide