Solved: Re: Cisco CUBE dial peer - incoming calls matching outgoing dial peers

Lazarus_telecomTech · ‎09-28-2021

Hello all.

I have a CUBE serving a CUCM that's connected to the service provider's SBC. For outgoing calls, I've created two dial peers, one incoming for the CUCM to CUBE leg and one outgoing for the CUBE to SBC leg. These dial peers match everything [0-9]T because anything sent from the CUCM to the CUBE should be sent to the provider's SBC.

Now for incoming calls from the provider, I have configured several dial peers for the specific DIDs that have been assigned to the enterprise. Because the DIDs are not contiguous, I've created a separate dial peer for each number.

For example, for number 153 I've created an incoming dial-peer (SBC to CUBE) matching the incoming called number 5551234153, and a corresponding outgoing dial-peer (CUBE to CUCM) with a destination pattern of 5551234153 pointing to the CUCM.

The problem I am facing is that the provider has erroneously sent calls to DIDs that do not belong to the enterprise. Thus, they are not matching any incoming dial-peer. What's happening is that these calls are matching the outgoing dial-peer from CUBE to SBC using the [0-9]T resulting in a ping pong back and forth routing of the call between the CUBE and SBC. This is saturating the SIP trunk and causing call failures.

To solve the problem temporarily, I've created a dial peer to match that incorrect DID and send it to the CUCM. The CUCM has no such number, and simply drops the call. However, over time, the telco has made more such call routing mistakes, and the problem persists...

Of course, the provider should not be doing this, however, it is still happening. My question is, is there a way to block all such calls? Can I create a "catch all" dial-peer that will then reject calls that don't match a more specific configured dial peer? What is the best practice to apply in this case?

Thanks, and looking forward to hearing the wisdom of others on this topic!

Laz

Roger Kallberg · ‎09-28-2021

I would advice you to use a different method to match your inbound dial peers. My preferred option for this is to use VIA header information. See the below example.

voice class uri CUCM sip
 host ipv4:<CM CPE 1 IP address>
 host ipv4:<CM CPE 2 IP address>
 host ipv4:<CM CPE 3 IP address>
!
dial-peer voice 1000 voip
 description Incoming Dial-Peer from CUCM
 session protocol sipv2
 incoming uri via CUCM
 voice-class codec 1  
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte sip-kpml
 fax-relay sg3-to-g3
 no vad
!
dial-peer voice 1010 voip
 description Inbound calls from PSTN to CUCM (Server group 1)
 session protocol sipv2
 session server-group 1
 destination e164-pattern-map 1
 voice-class codec 1  
 voice-class sip options-keepalive profile 1
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte sip-kpml
 fax-relay sg3-to-g3
 no vad
!
voice class uri PSTN sip
 host ipv4:<ITSP SIP server IP>
!
dial-peer voice 100 voip
 description Incoming Dial Peer from PSTN
 redirect ip2ip
 session protocol sipv2
 incoming uri via PSTN
 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
 fax-relay sg3-to-g3
 no vad
!
dial-peer voice 110 voip
 description Outgoing Dial Peer to PSTN
 translation-profile outgoing PSTN-OUT
 session protocol sipv2
 session server-group 2000
 destination e164-pattern-map 2000
 voice-class codec 1  
 voice-class sip profiles 10
 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
 voice-class sip audio forced
 dtmf-relay rtp-nte
 fax-relay sg3-to-g3
 no vad

For detailed information on this topic have a look at this fantastic document. https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html

Apart from this I would also recommend you to look into using DPG for outbound dial peer selection. This makes the path predictable based on the inbound dial peer matched. See the document for details on this and the below short example.

voice class dpg 2
 dial-peer 110 preference 1
!
voice class dpg 1
 dial-peer 1010
!
dial-peer voice 100 voip
 destination dpg 1
!
dial-peer voice 1000 voip
 destination dpg 2

With this you can likely drastically simplify and reduce your setup of dial peers.

View solution in original post

Steven L · ‎09-28-2021

First, i agree with Roger's response. another way to handle this is to use e164 pattern maps for the inbound dial peer..

If you add all of your "known" DIDs to the pattern map and assign to an inbound dial peer, the CUBE will essentially block anything else.

If you want to manipulate the specific SIP response you can add a second dial peer that rejects everything with a specific response using header manipulation.

This is useful if you want calls to fail to a different site. This is useful when carriers only send to alternate routes when they receive something other than a 404.

I dont have a config example handy but can dig one up if needed.