As long as dial peers exist there'll be people struggling.

[UrbanPeasant]

As long as dial peers exist there'll be people struggling, and I just became one of them. Perhaps someone can shed some light on this for me:

CUBE - c3900-universalk9-mz.SPA.156-3.M6a

Inbound calling to one number works but fails to another adjacent number that should work off the same dial peer

Mobile/cell phone calling inbound, incoming call leg picked up by DP20 and expected to be sent outbound on DP24 to another gateway.

This works when calling in to extension 11000, 11001, 11002 but fails after that, 11003 onwards

dial-peer voice 20 voip
description *Inbound to CUBE*
translation-profile incoming STRIP+44
preference 1
session protocol sipv2
session target ipv4:10.42.18.99
incoming called-number 015GGG110..

voice-class sip early-offer forced
dtmf-relay rtp-nte
codec g711alaw
no vad

 !

voice translation-profile STRIP+44
translate called 6

!

voice translation-rule 6
rule 1 /^\+44\(15GGG110..\)/ /0\1/

!

dial-peer voice 24 voip
description *Outbound to ACGW*
preference 1
destination-pattern 015GGG1100[0-9]
session protocol sipv2
session target ipv4:10.42.18.99
voice-class sip early-offer forced
dtmf-relay rtp-nte
codec g711alaw
no vad
!

with these peers if I dial 015GGG11000 or +4415GGG11000 the call is picked up on DP20 and sent onwards on DP24.

But if I dial 015GGG511003 or +4415GGG11003 the call is picked up on DP20 but attempted to be send onwards on DP3 which ends up creating a crazy loop. DP3 is for all our other organisational inbound calls from our carrier and works just fine.

dial-peer voice 3 voip
description * LANside OUTBOUND to IS-SUB01 *
translation-profile outgoing PSTN_inbound
preference 1
destination-pattern 0[12][056][123].%
session protocol sipv2
session target ipv4:10.42.18.72
dtmf-relay sip-kpml sip-notify rtp-nte
codec g711alaw
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
no vad

!

I'm out of ideas about why one call matches DP24 out, but the other matches DP3, when DP24 has the more specific pattern match.

The INVITES hitting the CUBE are identical (save for the called number). 

And I don't seem to be getting any useful out put from csim start 015GGG11003 either

752788: Jan 9 15:32:54.635: //-1/xxxxxxxxxxxx/RXRULE/sed_subst: No match! number= matchPattern=id; |[; ]*id$ replacePattern=

When I look at 'call active voice brief' can see that a call for 11000 has the correct originate number, but a call for 11003 does not, and show up as the extension number only. This is weird because CUCM is passing the full number through from a prefix on the route pattern, and the CUBE has no translation rules that would treat 11000 differently to 11003.

Wrong:

0    : 3091429 1166758366ms.1 (14:53:29.666 UTC Thu Jan 9 2020) +-1 pid:20 Answer 078HHH65714 connecting

0    : 3091431 1166758566ms.1 (14:53:29.866 UTC Thu Jan 9 2020) +-1 pid:3 Originate 11003 connecting

Correct :

0    : 3092153 1166851026ms.1 (14:55:02.328 UTC Thu Jan 9 2020) +-1 pid:20 Answer 078HHH65714 connecting

0    : 3092154 1166851026ms.2 (14:55:02.322 UTC Thu Jan 9 2020) +-1 pid:24 Originate 015GGG11000 connected

I'd love to hear what people think I've got wrong and where to look next. At the moment I'm lost for further ideas.

Thanks and regards

Nathan

[Vaijanath Sonvane]

Hi,

Based on what you have mentioned, the called number 015GGG11XXX is matching both dial-peer 24 and dial-peer 3. Even though Dial-Peer 24 is longest match (most specific), looks like gateway is looking at explicitly defined dial-peer preference command. Please try changing the dial-peer 3 preference to 2 or higher.

[UrbanPeasant]

Thanks Vajanath,

I tried that. DP3 is one of 4 x DP that send calls in to CUCM. So I adjusted all their preferences to be higher values so that DP24 should be picked alone, rather than load balanced. Though I must say I wasn't hopeful of that as a solution, because the 'show dialplan number 01524511008' output showed that DP24 should indeed win anyway.

…..tag = 24, destination-pattern = `015GGG1100[0-9]'

…..Matched: 015GGG11008   Digits: 11   Matched pattern: 015GGG1100[0-9] Preference: 1

…..Target: ipv4:10.42.18.99

The preference changes didn't work.

At first I couldn't understand how the call was being looped round-and-round to CUCM. But after matching DP3, the numbers are translated, and the call sent inbound to CUCM. CUCM sees the incoming number match a route pattern, adds the national dialling prefix to it, and sends it back to the CUBE, and repeat. This loop behaviour was identifiable because each time the CUBE sends a call in to CUCM we prefix an 8 to the incoming number to facilitate users returning calls, and what we see on the CUBE becomes (example of an internal call from my DN to 015GGG11003) :

0    : 3093192 1167582506ms.1 (15:07:13.803 UTC Thu Jan 9 2020) +-1 pid:20 Answer 888888888895219 connecting.

Even if I change DP24 to be an EXACT match for the dialled number 015GGG11003, the call doesn't connect and gets looped, like you see in the first part of the image attached.

I've stopped the looping now by applying huntstop to DP24, which causes the return of 'Your call cannot be completed as dialled' from CUCM, and that enabled me to see the 404 message in the next part of the image. Which led me to look at the upstream gateway, bottom part of the image, which would appear to tell me that the problem is coming from upstream number allocation behind the gateway at 52.114.132.46

I don't think I can do much more with this presently, as I don't have anything to do with that remote PBX, but I'll update again once the situation has been looked at further. As it stands my faith in my understanding of the CUBE, dial peers and regex has been restored a little!

Thanks again

Nathan.

[Vaijanath Sonvane]

Hi Nathan,

Thanks for the update. Great to see that you made some progress to identify the issue.