Destination-pattern BAD.BAD

[dgonzalez1]

Hello, I'm configuring a cisco cube to route calls between webex calling and the pstn. Originally it was configured with an incoming and an outgoing dial-peer linked with destination-pattern BAD.BAD and he use of dpg. I understand that this config always links these two dp disregarding the digits dialed. Now the customer requests that outgoing calls to cell phones are routed to specific ports towards the psnt. How could I make that distinttion if digital are not being considered?

Thank you.

[TechLvr]

If I understood correctly, you are trying to get the CUBE to route outbound calls to cell phone numbers out of a certain dial peer to the PSTN. The CUBE cannot make that distinction without user intervention. 

AFAIK, it is only possible to achieve this goal if you ask the users to dial cell phone numbers differently from other numbers. For example, #9XXX XXX XXXX. Webex should then be configured to send these digits to the CUBE without any digit manipulation. In the CUBE, you can create a dial peer for 9# patterns and a translation rule that drops #9 before sending the call to the ITSP. Any other changes to this dial peer, including port number, will then only apply to outgoing calls to cell phone numbers. See example below which sends 9# calls to the ITSP on port 5062. 

voice class e164-pattern-map 1000
description CellToPSTN
e164 #9[2-9]..[2-9]......
e164 #91[2-9]..[2-9]......

voice translation-rule 1000
rule 1 /^#9\([2-9]..[2-9]......\)/ /\1/
rule 2 /^#9\(1[2-9]..[2-9]......\)/ /\1/

voice translation-profile OutgoingCell
translate called 1000

voice class server-group 1000
description ***To_ITSP***
ipv4 1.1.1.1 port 5062 preference 1

dial-peer voice 1000 voip
description ** Inbound calls to CUCM **
destination e164-pattern-map 1000
session server-group 1000
session protocol sipv2
voice translation-profile OutgoingCell
codec g711ulaw
dtmf-relay rtp-nte

[dgonzalez1]

Thank you. The way of dialing to cell phones in my country is different form regular lines, so there is no need to manipulate digits. By port I meant voice ports, we reach the psnt through fxo ports (I'm sorry I was unclear), but for the case it would be the same. The problem is that as I have destination-pattern BAD.BAD in incoming and outgoing dial-peers I think it would disregard any digits. According to a document I found this is the description of destination-pattern BAD.BAD: "Digit pattern that allows selection of this dial-peer. However, this will invoke the outgoing dial-peer directly from the incoming dial-peer using DPG statements and that bypasses the digit pattern match criteria".

So, it seems that the dial-peer present in DPG is the only one that it would use, no matter which digits I put in another dial-peer.

Thanks.

[TechLvr]

Yes. You are right. The destination dpg method does not care about the dialed digits. It sends all incoming calls that hits this dial peer to the outbound dial-peers defined in its destination dpg. 

But you can still define a separate set of inbound/outbound dial peers for your cell phone numbers without the dpg method. Since you said the cell phone numbers are dialed differently, then you can easily achieve this, and route these calls out of a specific FXO port. 

If you share your gateway config, I can create a template that works for your scenario. You can sensor the Public IP addresses and other private information before sharing your config.  

[Roger Kallberg · Accepted solution]

As DPG makes the connection to what dial peer(s) to use in the outbound direction on the inbound dial peer you’ll need to create a different dial peer to be used in the inbound direction that matches your cell phone calls. My advice would be to use different incoming called e164-pattern-map <pattern-map-number> on two inbound dial peers that uses separate DPGs to steer the calls to different outbound dial peers/lines. For details on how call routing works in IOS please see this excellent document. In Depth Explanation of Cisco IOS and IOS-XE Call Routing 

[dgonzalez1]

That sounds good. Thank you, Roger!