Mobility Identity

[walshliam]

I'm not sure if that is the feature I'm looking at so here is the scenario. I have a Dual Mode Phone client with a TCT device name. MyMobile Identity Name is my name and the Destination Number is My Cell preceeded with a 9. When I dial our Auto Attendant (IPCC) from the Cell Phone, The CUCM sees my Cell caller ID and associates the inbound call to my 7965, turning on the remote device in use. When I call a different Auto Attendant(Same IPCC Server), through another Gateway,the call fails. I have checked the inbound CSS on both Gateways and although they are named differennt, they each have the same partitions. Can Someone explain the call flow? Where should I start for Trouble shooting?

TIA

Liam

[David Hailey]

Are the trunks on these 2 gateways from the same carrier? Same trunk group? You could try to catch a call using debug isdn q931 and see what is being handed off across this trunk.

Hailey

Please rate helpful posts!

[walshliam]

OK, just tried. The 10 digit Calling Party Number matches my Mobility ID.

Thanks

[David Hailey]

This is across the "working" or the "non-working" trunk?

[walshliam]

accross the non-working trunk. Any idea how the call flows here? I assume, the call is coming this way:

PSTN - PRI - CMM - MGCP - CM ?? At this point, what is happening to associate the call to my Desk Phone and connect the call?

[David Hailey]

Well, we can't really tell you what your ingress call flow SHOULD be - but I mean, at a high-level, yes that's it. It would be PSTN via PRI connected to CMM operating in MGCP mode and then to CUCM for digit analysis and routing. I think another question for you would be how the Auto Attendants handling the calls as you call into them? One works properly, one doesn't. Possibly the inbound call is fine...maybe the issue or cause of your "problem" might be attributed to what the AA does that you're dialing. Can you give us some details there?

Hailey

[William Bell]

The CUCM associates the mobile CLID to your desk phone by using the remote destination profile. In cases where the remote destination profile is created with an offnet dialing prefix (like 9+10-digits of your mobile phone) then you may want to look at the following Call Manager service parameters:

"inbound calling search space for remote destination"

"matching caller ID with remote destination"

"number of digits for caller id partial match" (if using partial match for above, which may not be a bad idea)

Also, while the q931 debug may show you what is being handed off to the gateway by the PSTN, it does not communicate the complete picture. You need to see if the CLID is being modified as it enters your CUCM cluster from the gateway.

Have you done the simple test of putting lines on an IP phone and seeing what is presented?

Have you looked at DNA?

HTH.

Regards,

Bill

[William Bell]

Clarification on my last post.

Since you said you created your Remote Destination profile with a "9" prefixed, I think that you will want to double check:

"matching caller ID with remote destination" :  set to partial

"number of digits  for caller id partial match" :  set to the number of digits you expect from carrier.  10 based on this thread.

HTH.

Regards,
Bill

[walshliam]

Yes, I just added a DID that terminates on the GWand teh Caller ID is identical from both GW. Both GW have the exact same config, but same version and it appears the Telco is sending Caller ID the same on both, so not sure what else to look at? I may have to open a TAC, really wanted to find this without them .

[David Hailey]

Take a look at the settings Bill noted in his last post.

[walshliam]

Yes sorry, forgot to mention we were only looking for partial match on 10 digits.

[walshliam]

First, Thanks for all the great help, It's very difficult to explain this config let alone troubleshoot remotely blind . . .

I am going to have TAC take a look at this and provide some logs, hopefully they can get to the bottom of this. I think if I understood how the Remote Destination was linked in on an inbound call I could troubleshoot this better, but I'm only speculating and I have not found any details on how that feature functions.

I will post an update tomorrow after TAC reviews the case.

Liam

[David Hailey]

Hey bud, I just wanted to point out that Bill and I (especially Bill) have given you a lot of information and troubleshooting tips.  If you open a TAC case, they are likely going to focus on the same things as well.  So, it would be in your best interest to read back thru the thread and try anything you've skipped over BEFORE you open your TAC case.  The more info, the better as far as TAC is concerned.

Hailey

Please rate helpful posts!

[walshliam]

sure, Thanks for the tip. I had done most of these steps before posting on Netpro. I have verified the config, confirmed the CSS are good, tested with DNA and gone through the debugs and traces. I have done everything I can from my end. I posted on here to see if I could better understand how the remote destination and the inbound call functions, which I have not been able to get answered. If I knew that, I would have another avenue for troubleshooting.

Liam

[David Hailey]

Well RDP at the most basic level is like a shared line. The difference

is that CUCM forks a second call out to the RDP DN when a call is

received that matches the DN associated with the RDP DN (typically a

cell phone).

Sent from my iPhone

On May 4, 2010, at 8:47 AM, walshliam