MVA Two Stage Dialing Issue with E.164

[robinluo_connexim]

Hi, I am currently trying to setup Unified Mobility in CUCM 7.x and have had the following issue.

The whole dialplan follows Cisco's SRND and use E.164 for call routing. The remote destination number is +14162223333. I have no problem connect to this Remote Destination profile from PSTN and enter my PIN.

The problem is when I am making the second stage dialing to call any number, the call fails with "your call cannot be completed as dial ...". The CSS has been verified. If I use a different format for the remote destination number, anything other than E.164 would work, whenever a PLUS sign is attached, call fails.

Is this a configuration issue? Any parameter to address this problem?

TIA.

[htluo]

This sounds strange.  2nd-stage dialing does not verify remote destination.

What exactly the number you entered in 2nd stage?

Michael

http://htluo.blogspot.com

[robinluo_connexim]

Hi Michael,

======================

Here is the failed scenario:

======================

Remote Destination: +14165558888

Service Parameter: Matching Caller ID with Remote Destination "Complete"

Also created a translation rule to convert ANI to +14165558888 on the inbound dialpeer which triggers MVA application on H323 GW.

Once dialed the MVA number entered PIN number, system prompted the destination number under option 1. Dialed an internal extension, received error message: "your call cannot be completed as dialed ..."

======================

Below is the working scenario:

======================

Remote Destination: 94165558888

Service Parameter: Matching Caller ID with Remote Destination "Complete"

Also created a translation rule to convert ANI to 94165558888 on the inbound dialpeer which triggers MVA application on H323 GW.

Once dialed the MVA number entered PIN number, system prompted the destination number under option 1. Dialed an internal extension, destination rang and connected.

I am using E164 number to route the call in my CUCM system (globalization, normalization, etc etc)

Any idea? Thanks.

[robinluo_connexim]

In fact, I even tried another scenario, which I changed the matching rule to "partial", and the ANI used 4165558888 only, still had the same problem.

ignore this message please

Message was edited by: Robin Luo

[htluo]

I guess there might be some problem on digit manipulation.

Like I said, the 2nd stage dialing does not verify RD (Remote Destination) at all.

Would you be able to collect "Cisco CallManager" logs?

1) Go to CUCM Serviceability > Trace > Configuration.  Set "Cisco CallManager" trace level to detailed.  Apply to all nodes if you're not sure which node the H.323 GW registered with.

2) Try the fail scenario.

3) Use RealTime Monitoring Tool collect "Cisco CallManager" traces.

4) Provide caller number, dialed number, 2nd-stage dialed number, approximate time (the more accurate the better).

Upload traces here.  We can take a look.

Michael

http://htluo.blogspot.com

[robinluo_connexim]

Hi Michael,

I kind of solved the problem by changing the match rule from COMPLETE to PARTIAL. I was able to keep the Remote Destination as E.164 format while using MVA to complete the 2nd stage dialing.

I did look into the detail trace (both CCM and MVA), I found something interesting, which I am not sure if it's my setting problem:

06/28/2010 07:56:34.173 CCM|DbMobility: getMatchedRemDest starts: cnumber = 14165558888|<:STANDALONECLUSTER><:10.10.10.2><:DETAILED><:FFFFFF>

06/28/2010 07:56:34.173 CCM|DbMobility: getMatchedRemDest: full match case|<:STANDALONECLUSTER><:10.10.10.2><:DETAILED><:FFFFFF>

06/28/2010 07:56:34.173 CCM|DbMobility: can't find remdest 14165558888 in map|<:STANDALONECLUSTER><:10.10.10.2><:ERROR><:FFFFFF>

It appears DbMobility process tried to lookup the calling number in the remote destination table based on the matching rule (full match), however it found the difference between 14165558888 and +14165558888, the call failed. I think by changing it to partial match solved this issue.

Could you please confirm if my finding is correct? Thanks a lot.

Robin

[robinluo_connexim]

also please ignore my earlier post in which I said partial match did not work, must did something wrong by that time ...