CUBE - Calls from NXX to NXX that were ported timeout Issue

[AnthonyGreene64131]

The title may be somewhat misleading, but I am running into an issue with our CUBE.  We own an entire NXX, originally on PRIs and slowly moving it over to ATT IP Flex.  Some of our numbers from our NXX have been ported to our corporate phone system separate from us.  Calls across the PRI gateways go through no issue, but calls across the CUBE to ISTP timeout after around 20 seconds and the provider is getting a Q.850;cause=102 as the reason for disconnect.

When the call originally goes through, I can hear the recorded greeting and after about 20 seconds I get a busy signal and then am disconnected.  From looking at the traces on the CUBE it seems as if it goes through and then the CUBE is trying to send INVITEs to each of the Call Manager servers in the middle of the call, which receives 404s as it is no longer built on the Call Manager side.  I can then see the reason code that the provider sent me as well.  Below is a call flow example and the current applicable CUBE config.  What am I missing here?

Call Example: 2055556789 dials 92055551515, call routes and hear the recording greeting, call gets busy signal after 20 seconds and drops after about 30 second total duration.

voice service voip
 no ip address trusted authenticate
 address-hiding
 mode border-element license capacity 160
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 no supplementary-service sip handle-replaces
 redirect ip2ip
 signaling forward unconditional
 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
 no fax-relay sg3-to-g3
 sip
  bind control source-interface Loopback1
  bind media source-interface Loopback1
  header-passing
  error-passthru
  asserted-id pai
  early-offer forced
  no silent-discard untrusted
  midcall-signaling passthru
  privacy-policy passthru
  g729 annexb-all
!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8 bytes 30
 codec preference 3 g711alaw
!
voice class e164-pattern-map 100
 description Incoming Call Pattern Map 100
  e164 205XXXXXX
  e164 205XXXXXX
  e164 205XXXXXX
  e164 205XXXXXX
  e164 205XXXXXX
  e164 205XXXXXX
  e164 205XXXXXX
  e164 205XXXXXX
  e164 205XXXXX[0-2]
  e164 205XXXXX[01]
  e164 601XXXXX[2-6]
  e164 205555....
 !
!
voice class e164-pattern-map 200
 description Outgoing Call Pattern Map to ATT-SBC 200
  e164 1205[2-9]......
  e164 011T
  e164 205[2-9]......
  e164 1[2-9]..[2-9]......
  e164 [2-9]..[2-9]......
 !
!
voice class server-group 1
 ipv4 X.X.X.76
 ipv4 X.X.X.77
 ipv4 X.X.X.78
 description CUCM Servers
!
voice class server-group 2
 ipv4 IP-1
 ipv4 IP-2
 description ATT-SBC
!
voice class sip-options-keepalive 1
 description OPTIONS PING to ATT-SBC
 transport udp

dial-peer voice 100 voip
 description INBOUND SIP from ATT-SBC
 call-block translation-profile incoming Block-Incoming
 call-block disconnect-cause incoming call-reject
 session protocol sipv2
 session transport udp
 incoming called e164-pattern-map 100
 voice-class codec 1  
 voice-class sip bind control source-interface GigabitEthernet0/0/1
 voice-class sip bind media source-interface GigabitEthernet0/0/1
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 101 voip
 description OUTBOUND SIP FROM CUBE TO CUCM
 session protocol sipv2
 session transport udp
 session server-group 1
 destination e164-pattern-map 100
 voice-class codec 1  
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 200 voip
 description OUTBDOUND SIP to ATT-SBC
 session protocol sipv2
 session transport udp
 session server-group 2
 destination e164-pattern-map 200
 voice-class codec 1  
 voice-class sip options-keepalive profile 1
 voice-class sip bind control source-interface GigabitEthernet0/0/1
 voice-class sip bind media source-interface GigabitEthernet0/0/1
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 1 voip
 description Incoming VOIP Dial-Peer
 incoming called-number .
 voice-class codec 1  
 dtmf-relay rtp-nte h245-alphanumeric
 no vad

gateway 
 timer receive-rtp 1200
!
sip-ua 
 no remote-party-id
 timers options 1000
 connection-reuse

[Roger Kallberg]

Not related to the issue you have, but you are strongly advised to not use this setting. 

no ip address trusted authenticate

This opens up your system to be used for toll fraud. 

[AnthonyGreene64131]

Roger,

Noted!  Thank you.

[Scott Leport · Accepted solution]

Hi there,

The disconnect is being sent from CUCM:

Check that your SIP trunk from CUCM is configured and is shown as in service or that the DN is configured correctly in CUCM or can be dialled from external.

In addition to that, I would also suggest a few other changes:

1. Configure a voice class URI with the ATT SIP Signaling endpoints and attach it to Dial-Peer 100 using the incoming uri via config (removing the incoming E164 pattern map)

2. Change Dial-Peer 1 to be SIP and use it as an incoming dial-peer for calls from CUCM to your CUBE. Without it, your calls will match dial-peer 0 which is bad. Configure a separate voice class URI with your CUCM nodes and attach it to Dial-Peer 1.

[AnthonyGreene64131]

Scott,

The example number of 2055551515 no longer lives on our CUCM as it was ported and why CUCM servers were sending the 404 and the bye to the carrier.  Everything between CUCM and the CUBE is fine and has been in full service. 

Not sure if your suggestions we also to try and combat my issue, but I went ahead and took the advice of changing it for dial-peer 100.  From testing with CUBE DNA on Cisco's website these calls were matching both incoming and outgoing dial-peers.  I created the voice class uri and matched it to that incoming dial-peer and began making test calls and so far it seems to have corrected the issue as it no longer matches those incoming and outgoing peers.  It's also a huge relief for porting so that I do not have to go in and add different patterns. 

Thank you for getting me along the right track.

[Scott Leport]

Hi Anthony,

Thanks for getting back to me. No worries, glad I could help.

Remember and take Roger's advice re the trusted list. Toll fraud is very expensive and SIP trunks are subject to the same attacks that a data network could be without the appropriate security measures in place. This config here should be all you need:

Router(conf-voi-serv)# ip address trusted authenticate

Some engineers might also populate the IP addresses of the providers SIP Signaling endpoints in this list too, but it's not really required as long as the IPs are attached to a dial-peer in some shape or form. Link below with some info on that. CME related, but the procedure is the same:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/manual/cmeadm/cmetoll.html#concept_28F29B1505FD48078869F41226C55629

Good luck with the remainder of the porting!

Scott

[AnthonyGreene64131]

Scott,

Thank you!  And I did go ahead and populate that trust list.  It is setup in my lab, unsure as to why I did not have that set here.