Outbound calls to the appropriate trunk on the CUBE for CLI display

[levandinh8894@gmail.com]

We have a CUBE with multi interface of E1 ports. To display the correct CLID for outbound, the call must be routed to correct trunk line

The current setting on the CUBE doesn't work as expected. Call from 1XXX is displayed correct but from 2XXX show wrong. 

What is the relationship between setting  the corlist on CUBE and the extension on Call Manager to ensure that calls are routed correctly?

dial-peer cor custom

 name TRUNK_1

 name TRUNK_2

dial-peer cor list TRK-1XXX

 member TRUNK_1

dial-peer cor list TRK-2XXX

 member TRUNK_2

Dial-peer voice 100 pots

corlist outgoing TRK-1XXX

description ** Outbound Call  **

preference 1

destination-pattern 9..T

port 0/1/0:15

forward-digits all

Dial-peer voice 200 pots

corlist outgoing TRK-2XXX

description ** Outbound Call  **

preference 1

destination-pattern 9..T

port 0/1/1:15

forward-digits all

[Roger Kallberg]

There is no relationship between these. COR is locally relevant in the router, your CM doesn’t know anything about this.

If you want to send calls to different dial peers based on calling numbers you can do that in a few ways.

The legacy option is to use voice translation rules/profile in the inbound direction from CM, this requires that you have different inbound dial peers that matches on calling numbers and add a route string to the called number. Then use the route string on the egress dial peers to route and also remove the string by another voice translation before sending the call to your service provider(s).

The second option that comes to mind that are using a bit more current technology is to use Dial Peer Groups, DPG in short. With that you still need to use different inbound dial peers, but instead of using translations and route strings you’ll define by DPG configuration what the outbound dial peer should be based on which inbound dial peer that is matched.

Either way if possible it would be advisable to use different E.164 number groups to match the inbound dial peers as that gives you more flexibility.

For more information on this see this document. Explain Cisco IOS and IOS XE Call Routing 

[levandinh8894@gmail.com]

Thank you @Roger Kallberg for your support. I will test in lab follow your instruction. 

If there are multiple dial-peers with the same 'destination-pattern' and preference settings, how does the cube route the call?  Prioritize the dial-peer with the smallest number, or does it choose randomly? In my lab tests, it appears to pick randomly

[Roger Kallberg]

Your observation is correct, if the dial peers have equal preference and the exact same destination pattern it picks the dial peers randomly.

[levandinh8894@gmail.com]

@Roger Kallberg : Could you please help to check if below script can be fit with the requirement?

(My understanding: Calling number 1XXX first go to Dialpeer 100 then go to dialpeer 102 because same corlist setting.  Calling number 2XXX go to Dialpeer 200 then go to dialpeer 202 because matching of the corlist )

dial-peer cor custom

 name TRUNK_1

 name TRUNK_2

 name TRUNK_3

!

dial-peer cor list TRK-1XXX

 member TRUNK_1

!

dial-peer cor list TRK-2XXX

 member TRUNK_2

!

dial-peer voice 100 voip

 corlist incoming TRK-1XXX

 description ** Outbound Call - VoIP inbound call leg **

 answer-address 1...

 session protocol sipv2

 voice-class codec 1

 dtmf-relay sip-kpml rtp-nte

 ip qos dscp cs4 signaling

 no vad

!

dial-peer voice 200 voip

 corlist incoming TRK-2XXX

 description ** Outbound Call - VoIP inbound call leg **

 answer-address 2…

 session protocol sipv2

 voice-class codec 1

 dtmf-relay sip-kpml rtp-nte

 ip qos dscp cs4 signaling

 no vad

!

Dial-peer voice 101 pots

 corlist outgoing TRK-1XXX

 description ** Outbound Call - POTS Outbound call leg **

 preference 1

 destination-pattern 9..T

 port 0/0/0:15

 forward-digits all

!

dial-peer voice 201 pots

 corlist outgoing TRK-2XXX

 description ** Outbound Call - POTS Outbound call leg **

 preference 1

 destination-pattern 9..T

 port 0/0/1:15

 forward-digits all

I searched and tested with E164 for number calling matching, but it doesn't work. Could you please provide me with some examples so that I can follow along? Thank you so much

[Roger Kallberg · Accepted solution]

Remove all COR related items, you don’t need them. Also remove the answer-address on your inbound dial peers and replace that with this.

voice class e164-pattern-map 1
 description E164 Pattern Map for 1XXX calling numbers
 e164 1...
!
voice class e164-pattern-map 2
 description E164 Pattern Map for 2XXX calling numbers
 e164 2...
!
dial-peer voice 100 voip
 incoming calling e164-pattern-map 1
!
dial-peer voice 200 voip
incoming calling e164-pattern-map 2

Then add this to use DPG for outbound dial peer selection.

voice class dpg 1
 description Dial-peer Group for calling number 1XXX
 dial-peer 101
!
voice class dpg 2
 description Dial-peer Group for calling number 2XXX
 dial-peer 201
!
dial-peer voice 100 voip
 destination dpg 1
!
dial-peer voice 200 voip
 destination dpg 2

[Roger Kallberg]

How did it go with this, where you able to get it working with the configuration I provided?

[levandinh8894@gmail.com]

Sorry for late reply. I followed your instruction and it worked. Thank you so much for your support.

[Roger Kallberg]

Glad to hear that.

[levandinh8894@gmail.com]

It seems that the destination-pattern of outbound dial-peer is ignored when using DPG? 

For example, the system randomly selects a dial-peer without checking destination-pattern when configured as follows:

voice class dpg 1
 dial-peer 101
 dial-peer 102
dial-peer voice 101 pots
  preference 1
  destination-pattern 9..T
  port 0/0/0:15
dial-peer voice 102 pots
  preference 1
  destination-pattern 999[1-2]
  port 0/0/0:15
  prefix 012345678


   

[Roger Kallberg]

If you would’ve read the document that I referenced in my first response you’d seen that the destination pattern on the outbound dial peer is not used when you use DPG.

”A dial-peer group allows administrators to specify an exact dial-peer for outbound routing based on the inbound dial-peer matched. Once an inbound dial-peer with a dial-peer group configured is matched, the call uses the dial-peer defined in the dial-peer group even if the destination-pattern does not match. The only prerequisite is the outbound dial-peer must be Up so an outbound matching method must be configured, however, this is not actually used to route the call.”