cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
618
Views
0
Helpful
6
Replies

E1 - MGCP Gateway : call push to operator before user finished to dial

cedricm73
Level 1
Level 1

Hi,

i have an issue with a MGCP Gateway configuration (2851/IOS 12.4-23) connected to a CUCM 6.1.2.

when i dial a number, as soon as the number match a unique route pattern, the call is send over the E1 and the operator send back an error as the number is no complete.

For example if a user try to dial 9004133221100, which is matching 9.00! then i see on the phone that only 9004 is taken into consideration, then i get operator error message.

On the gateway runing 'term mon' and 'debug isdn q931' i can see :

*Feb 4 12:58:08.626: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0001

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Calling Party Number i = 0x0081, '1....'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '004'

Plan:Unknown, Type:Unknown

*Feb 4 12:58:08.690: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8001

Any idea where could be the issue. i have 20 other gateways in different country connected on this callmanager and they do not suffer this issue. i just remember that there was a setting on CCM4.13 for this kind of behaviour but for icomming call, not outgoing (ISDN call in En bloc or Overlap modes)

any good idea is welcome. thx

6 Replies 6

Brandon Buffin
VIP Alumni
VIP Alumni

Sounds like your dial plan is overlapping somewhere. Go to the route plan report and search for 900 and 9.00 and see if you see the overlap.

Hope this helps.

Brandon

Hi, first thanks for your quick feedback. i have double check the route pattern and don't see any overlap. in fact 9.00 was an example, all route pattern that goes to this Operator have the issue.

Phone have CSS that contain only IT-MIL-PSTN

and

routeplan report on this IT-MIL-PSTN give :

9.15[45] Milan Free Telecom Service IT-MIL-PSTN

9.0[1-9]XXXXXXXX Milan National call IT-MIL-PSTN

9.19[01] Milan Free Telecom Service IT-MIL-PSTN

9.19[01]# Milan Free Telecom Service IT-MIL-PSTN

9.15[45]# Milan Free Telecom Service IT-MIL-PSTN

9.11[2345789]# Milan Emergency Numbers IT-MIL-PSTN

9.13[39]# Milan Free Telecom Service IT-MIL-PSTN

9.192193 Milan Fastweb IT-MIL-PSTN

9.192193# Milan Fastweb IT-MIL-PSTN

9.0[1-9]XXXXXXXX# Milan National call IT-MIL-PSTN

9.0[1-9]XXXXXXX# Milan National call IT-MIL-PSTN

9.11[2345789] Milan Emergency Numbers IT-MIL-PSTN

9.0[1-9]XXXXXXX Milan National call IT-MIL-PSTN

9.899XXXXXX# Milan Premium number IT-MIL-PSTN

9.3XXXXXXXX Milan Mobile Call IT-MIL-PSTN

9.3XXXXXXXX# Milan Mobile Call IT-MIL-PSTN

9.3XXXXXXX# Milan Mobile Call IT-MIL-PSTN

9.3XXXXXXX Milan Mobile Call IT-MIL-PSTN

9.00!# Milan International Call IT-MIL-PSTN

9.00! Milan International Call IT-MIL-PSTN

9.800XXXXXX Milan Toll Free number IT-MIL-PSTN

9.800XXXXXX# Milan Toll Free number IT-MIL-PSTN

9.803X Milan Toll Free number IT-MIL-PSTN

9.803X# Milan Toll Free number IT-MIL-PSTN

9.899XXXXXX Milan Premium number IT-MIL-PSTN

for example for mobile phone, it's wait until we match the first 9.3XXXXXXX and send over the E1. if it match an exiting number it's work, but if the good number contain 1 more digit, it is just send before the user get time to place the call. i don't thin it is an operator configuration issue as changing the route pattern 9.00! to another voiceateway/operator and the issue persist with this phone. realy weird...

Are you manipulating the digits with a mask and/or digit discard instructions at the route pattern or route list/route group levels? It's possible that CUCM is only sending the first 4 digits to the gateway.

Brandon

yes, i am removing the predot before sending to the gateway (Called Party Transformations on route pattern).

The issue look like really link to the fact that as soon as the number dial match 1 pattern, CUCM release to gateway without waiting the extra digit.

but it's look like i solve my issue (with your help) by deleting 9.00! and 9.00!# and recretate them from scratch.... really wierd. i will now recreate all other and see if it's solve my issue and will post the output in this thread. thanks for your support as it was really and route pattern issue, while i was focussing on E1/Operator issue.

it sounds like you are on the right path. To discover what call manager is doing with the call (what route patterns it matches, where the call goes from there, waht its alternate routes are, try using DNA (Dialed Number Analyzer). This tool will not tell you if a number is valid (from the PSTN's perspective, but it will tell you whether or not the dialed digits match a pattern and what call manager will do with the call.

thanks all for your advice. i confirm that recreating all route pattern from scratch solve my issue.