CUBE/CME Question - E164 Pattern Maps with Dial Peer Hunt Mode

[edwardforgacs]

Am I missing something, or is there a bug (IOS 15.7(3)M8) which would seem to make the following combination of commands totally incompatible?

I have tried with separate inbound/outbound dial peers, and even wiping the whole config down to a single dial peer. As soon as the dial-peer hunt mode is changed from the default 0, inbound calls fail.

voice class e164-pattern-map 1
   e164 +.T

dial-peer voice 8 voip
  incoming called e164-pattern-map 3
  destination e164-pattern-map 1
!
dial-peer hunt 2

Note I have obviously simplified the config and there are other E164 patterns and commands in the dial peer, but I am showing the critical sections which through hours of testing I have verified replicate the issue.

The error is:

%CALL_CONTROL-6-CALL_LOOP: The incoming call has a global identifier already present in the list of currently handled calls. It is being refused.

It would appear that every inbound call hitting the dial peer tries to initiate a dial-out to the calling number because of the +.T E164 pattern. Obviously this pattern overlaps with other E.164 numbers assigned to internal dns. But how are you supposed to make E.164 outbound dialing work, given this limitation, as quite clearly it's not possible to have patterns for the entire worldwide dial plan? It seems the E.164 support is a bit half-baked.

Using preferences on the dial peers seemed to be totally ignored, even when the incoming and outgoing dial peers are split, and attempting to force permissions on the dial peers (orig / term) also did not work.

[b.winter]

"But how are you supposed to make E.164 outbound dialing work" --> In the way, that you match incoming calls from the PSTN only based on your number range you got.
And the same can be use as outgoing matching towards CUCM.

And for outbound calls from CUCM to PSTN, you only have one option to get every possible number "+T".

Something like that:

dial-peer voice 1000 voip
desc ### From PSTN ###
incoming called-number +49123123T
huntstop
!
dial-peer voice 2001 voip
desc ### To CUCM ###
destination-pattern +49123123T
huntstop
!

dial-peer voice 2000 voip
desc ### From CUCM ###
incoming called-number +T
huntstop
!
dial-peer voice 1001 voip
desc ### To PSTN ###
destination-pattern +T
huntstop

In case of CME, you can leave out the CUCM dial-peers.

[edwardforgacs]

Sorry, I should have explained, voice class e164-pattern-map 3 is configured with the actual known inbound number ranges, which match valid directory numbers on CME, and doesn't really seem to be the issue. The destination e164-pattern-map is what is causing problems.

There are other patterns in voice class e164-pattern-map 1 but .+T is required for E.164 international dialing, and is the one causing the problem.

The fact it seems to be initiating a call back to the **calling** number SIP Trunk (from the SIP messages) and trying to create a loop is what makes me think it's a bug.

[b.winter]

Then do please post the full actual config. Nobody is able to work with chunks of sophisticated info.

[Roger Kallberg]

Preference is not a factor for inbound dial peer matching from what I know, it is only used in the outbound direction.

In general it is recommended to use other things than calling number to match the inbound dial peer, for example using information in the VIA header as that has the highest preference.

Both of these pictures are taken from this outstanding document that has pretty much all you ever would need to know about how call routing operates in IOS. Explain Cisco IOS and IOS XE Call Routing 

[edwardforgacs]

Thanks Roger, I've reviewed that document and did consider switching to URI matching as I see it is the preferred method.

However, if preference is ignored in the inbound direction (which it does seem from a quick test I just did), it looks like we are out of luck, as that was the reason for using dial-peer hunt in the first place.

By the way, the reason for matching on called number, is that we are actually intentionally trying to map a few *called* numbers to a different inbound dial peer with a slightly different codec config, and the e164 maps seemed to be the easiest way to achieve that. It may be possible with the URI matching but seems messy.

It still seems odd to me that the dial-peer hunt mode (2 = explicit preference first) would break this as the basic concept and cause call loops, as while I see how the call flow is tripping up with the overlapping patterns, that aspect of the e164 maps has been used for some time without issue.

[Roger Kallberg]

Maybe you can use DPGs to define what/which outbound dial peer(s) to use based on different inbound dial peers? That way you remove the actual match on the outbound dial peer from the equation.

Using your example something like this could work.

voice class e164-pattern-map 1
 e164 BAD.BAD
!
voice class e164-pattern-map 3
 e164 <+E.164 destination number>
!
voice class e164-pattern-map 2
 e164 <other +E.164 destination number>
!
voice class dpg 1
 description Dial-peer Group for specific called number in e164-pattern-map 3
 dial-peer 10
!
voice class dpg 2
 description Dial-peer Group for specific called number in e164-pattern-map 2
 dial-peer 11
!
dial-peer voice 8 voip
 description Inbound for called number in e164-pattern-map 3
 incoming called e164-pattern-map 3
 destination dpg 1
!
dial-peer voice 9 voip
 description Inbound for called number in e164-pattern-map 2
 incoming called e164-pattern-map 2
 destination dpg 2
!
dial-peer voice 10 voip
 description Outbound for DPG 1
 destination e164-pattern-map 1
!
dial-peer voice 11 voip
 description Outbound for DPG 2
 destination e164-pattern-map 1