Cisco CUBE - Need to map 480 Temp Unavailable to Another response

[Jay Schulze]

Hello,

Have a problem where we are receiving 480 temporarily unavailable from provider on the SIP turnk on calls that are going to say a disconnected number. Normally not a big deal. However these responses go back to CVP. CVP sees the 480 and puts the CUBE in the unreachable table.

So question is how could I map any 480 response back to say a 404 not found. Something that wouldn't trigger CVP.

[Chris Deren]

You can map specific reasons to specific causes:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cause-code-mapping.html

[Slavik Bialik]

Had those issues before, not exactly with 480 but other issue. Anyway, in my opiniong the best way to aproach this is from the CVP itself, you can disable the Unreachable Destination Tables (that's what I did, too).

You can follow this guide to see how to disable it:

https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-customer-voice-portal/200912-Disable-the-CVP-Unreachable-Destination.html

Read the caution note, see if the solution suits you or not.

[Jay Schulze]

Thanks.

Yeah that is what I'm doing now. But ultimately we want the unreachable table there. For failover to work properly.

[Slavik Bialik]

I established a failover mechanism from my Ingress Gateway to the CVP based on a server-group and enabling SIP OPTIONS using "voice class sip-options-keepalive <group-id>" on the dial peer towards the CVPs.

For example:

voice class server-group 2
ipv4 <CVP-A ipv4 address> preference 1
ipv4 <CVP-B ipv4 address> preference 2

voice class sip-options-keepalive 2
description SIP OPTIONS to CVP Group
retry 1
transport tcp

dial-peer voice 3000 voip
description Main IVR numbers
preference 1
destination-pattern 79..
session protocol sipv2
session transport tcp
session server-group 2
voice-class codec 1 
voice-class sip options-keepalive profile 2
dtmf-relay rtp-nte
no vad

[Jay Schulze]

TY for help everyone. Wanted to update in case someone else has the issue.

Checked with TAC who in turn had to check with the BU. They confirmed even though the response codes are under 'heartbeat properties'. You can remove at adjust the codes there on when a element goes into the unreachable table.