Cube Redundant Dial-Peer

[extremum]

Hello ,

We have two different ISP Sip Trunk on the cube . ı want to force all  outbound calls to first ISP then if first ısp's dial-peer goes out of state ı want to use second ISP for outbound calls .

Does these dial-peers configuration is enough to prevent to use second ISP until first ISP become out of state ? Do we need to add someting more like "hunt stop"  to first dial-peer  ?

dial-peer voice 1 voip
description ""first isp""
destination-pattern 12T
rtp payload-type cisco-fax-relay 98
rtp payload-type cisco-codec-fax-ack 99
session protocol sipv2
session target ipv4:x.x.x.x
voice-class sip rel1xx supported "100rel"
voice-class sip options-ping 60
voice-class sip options-keepalive retry 3
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte 
codec g711alaw
preference 1
no vad

dial-peer voice 2 voip
description ""second isp""
destination-pattern 12T
rtp payload-type cisco-fax-relay 98
rtp payload-type cisco-codec-fax-ack 99
session protocol sipv2
session target ipv4:x.x.x.x
voice-class sip rel1xx supported "100rel"
voice-class sip options-ping 60
voice-class sip options-keepalive retry 3
voice-class sip bind control source-interface GigabitEthernet0/0/2
voice-class sip bind media source-interface GigabitEthernet0/0/2
dtmf-relay rtp-nte 
codec g711alaw
preference 2
no vad

[b.winter]

Should be enough.
And no, you don't want to have "huntstop" on the primary dial-peer. This would prevent the failover to a different dial-peer.
Normally, you configure "huntstop" on the lowest preference dial-peer.

[extremum]

hello ,

ı see. just consider both dial-peers are " active " and we configured preference ;

cube always try first ISP but if first ISP returns sip messages like "404 not found" "503 service unavailable" ..etc then will cube try second ISP ?

in my opinion it will try to second dial-peer  but i just want to use second ISP when first dial-peer state is "busy"

[b.winter · Accepted solution]

With "voice hunt <cause code number>" or "no "voice hunt <cause code number>" you can define, based on which cause code (not the same as the SIP message number!!) CUBE stops hunting and or not.

E.g. if you want the CUBE to stop on a SIP 404 Not found with cause code 1 "unallocated / unassigned number", you would configure "no voice hunt unassigned number"
Because it doesn't make sense to try a different provider, if the number just doesn't exist.

And if a dial-peer is "busy", it wouldn't be considered anyway for routing.

[extremum]

Hello ,

if I configure "no voice hunt all" command , I understand second dial-peer won't be used , call will be routed based on the preference and if we get any reason code from first isp&dial-peer cube never tries second dial-peer . But if the first dial-peer state is out of service cube will use second dial-peer .

[Roger Kallberg]

The best way to know for sure is for you to try it out. To do this set the destination IP on dial peer one so something that is not an accurate IP of your service provider, this will get the dial peer to go into a none operational state and then make a call to see if it uses the second dial peer.

[extremum]

Hi ,

I have just tried and it works ! 

But if I just confire "no voice hunt all" it does not cover all cause codes ; when I check I can see ;

gwTes#sh run | s voice hun
no voice hunt 0
no voice hunt unassigned-number
no voice hunt transit-net-unroutable
no voice hunt dest-unroutable
no voice hunt send-infotone
no voice hunt misdialled-trunk-prefix
no voice hunt channel-unacceptable
no voice hunt call-awarded
no voice hunt preempt
no voice hunt preempt-reserved
no voice hunt 10
no voice hunt 11
no voice hunt 12
no voice hunt 13
no voice hunt 14
no voice hunt glare
no voice hunt normal-call-clear

So I am going to configure appropriate codes .

[Jonathan Schulenberg]

One other comment here, especially if you are based in the US. If these are two different ITSPs instead of redundant trunks to the same provider trunk group the ANI sent on an outbound call must be a DID assigned to that provider‘s trunk group for STIR/SHAKEN attestation to succeed, ie your call to not be flagged as spam. If that’s your situation I suggest adding a voice translation-profile to match and allow the TN inventory on that provider and then overwrite anything else to one of those numbers, typically a main line number.