cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
115
Views
3
Helpful
6
Replies

Cisco CUBE: Incoming call loops back to ITSP

Manual404
Level 1
Level 1

Hello,

I am calling from +37069361111 (Lithuania) to +443300601111 (UK) (last digits changed) and the call is being sent back to Lumen (ITSP) instead of getting forwarded to CUCM.

In other words:
The expected call flow should be: Lithuania Mobile Phone --> England CUBE --> England CUCM --> England Softphone (Jabber)
However, real call flow is: Lithuania Mobile Phone --> England ITSP Lumen --> England CUBE --> England ITSP Lumen --> England CUBE --> England ITSP Lumen --> England CUBE --> ... etc.


Here are the dial peers on my CUBE (I stripped off a lot of unecessary configuration lines to make it simple).
Do you see anything wrong with this?

voice class dpg 4001
description *** Send Calls to CUCM ***
dial-peer 4002 preference 1


voice class dpg 5001
description *** Send Calls to Lumen Information ***
dial-peer 5002 preference 1


voice class server-group 1
ipv4 123.456.123.456 preference 1
description *** Lumen SBC ***


voice class server-group 2
ipv4 10.1.1.1 preference 1
ipv4 10.1.1.2 preference 2
description *** CUCM Servers ***

dial-peer voice 4001 voip
description *** Incoming DP from CUCM to CUBE ***
destination dpg 5001
incoming called-number .

dial-peer voice 5001 voip
description *** Incoming DP from Lumen to CUBE ***
destination dpg 4001
incoming called-number .

dial-peer voice 5002 voip
description *** Outgoing calls to Lumen ***
preference 1
destination-pattern +T
session server-group 1

dial-peer voice 4002 voip
description *** Outbound Calls to CUCM Cluster ***
preference 1
destination-pattern +44T
session server-group 2
no vad


1 Accepted Solution

Accepted Solutions

It was me that misread your information. You were really clear. I’m sorry for the misunderstanding. It’s clear that you had two different issues. The issue with different number formats could have been solved by a voice translation rule/profile in your router to strip down the called number to four digits, but using full +E.164 format in CM on the directory numbers is a much better option.



Response Signature


View solution in original post

6 Replies 6

Change the inbound match to use VIA header information instead of incoming called-number .. For more information on how to do this please have a look at this fantastic document that goes deep in on how call routing operates in IOS. Explain Cisco IOS and IOS XE Call Routing 

Very likely what is happening is that the wrong inbound dial peer is matched as you have identical match statements on them.



Response Signature


Based on your shared configuration this would likely be what you'd need.

voice class uri PSTN sip
 host ipv4:123.456.123.456

voice class uri CUCM sip
 host ipv4:10.1.1.1
 host ipv4:10.1.1.2

dial-peer voice 4001 voip
 no incoming called-number .
 incoming uri via CUCM

dial-peer voice 5001 voip
 no incoming called-number .
 incoming uri via PSTN

The IP from the ITSP you might want to check in an inbound Invite to see what they send in the VIA field. For CM it should be correct based on your shared information.



Response Signature


Hello Roger,

I did configure the URIs but it didn't solve the issue at first (it's working now).

The main issue was on CUCM. I had the directory number set to 4-digits and added the other digits as external mask. It was all fine when calls were going out because the external mask would add the digits to make a full number but when calls were coming in - it would not find the full number. Issue got resolved when I changed the directory number from 4-digits to a full one (and removed the external mask).
Also, not sure if the URIs were needed but my dial-peers are now configured with URIs instead of "incoming called-number ." and it's all working.

The match on VIA that I provided is needed to diffrenciate the match of the two inbound dial peers. Without that you'd not match the correct inbound dial peer and then the DPG config that send the calls to the applicable outbound dial peer would not be using the correct/intended outbound dial peer for the two call scenarios.


@Manual404 wrote:

Hello Roger,

I did configure the URIs but it didn't solve the issue at first (it's working now).

The main issue was on CUCM. I had the directory number set to 4-digits and added the other digits as external mask. It was all fine when calls were going out because the external mask would add the digits to make a full number but when calls were coming in - it would not find the full number. Issue got resolved when I changed the directory number from 4-digits to a full one (and removed the external mask).
Also, not sure if the URIs were needed but my dial-peers are now configured with URIs instead of "incoming called-number ." and it's all working.


FWIW What you describe here has nothing to do with what you originally asked for. This pertains to inbound calls and what you asked for initially was outbound calls.



Response Signature


No, there was no issue with outbound calls. I could call from my Jabber anywhere.

I mentioned in the topic title that the issue was inbound calls (calling my Jabber from a mobile phone in Lithuania).

Sorry if something was unclear.

It was me that misread your information. You were really clear. I’m sorry for the misunderstanding. It’s clear that you had two different issues. The issue with different number formats could have been solved by a voice translation rule/profile in your router to strip down the called number to four digits, but using full +E.164 format in CM on the directory numbers is a much better option.



Response Signature