Mobility Identity

Unanswered Question
May 3rd, 2010

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?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
David Hailey Mon, 05/03/2010 - 12:59

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.


Please rate helpful posts!

walshliam Mon, 05/03/2010 - 13:10

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


walshliam Mon, 05/03/2010 - 13:27

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 Mon, 05/03/2010 - 13:35

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?


William Bell Mon, 05/03/2010 - 13:38

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?




William Bell Mon, 05/03/2010 - 13:45

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.



walshliam Mon, 05/03/2010 - 13:50

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 .

walshliam Mon, 05/03/2010 - 13:55

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

walshliam Mon, 05/03/2010 - 19:34

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.


David Hailey Mon, 05/03/2010 - 22:45

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.


Please rate helpful posts!

walshliam Tue, 05/04/2010 - 05:47

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.


David Hailey Tue, 05/04/2010 - 05:54

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

walshliam Thu, 05/06/2010 - 11:43

So, I just wanted to update you. I came in Tuesday and opened a TAC case, while collecting info for the TAC Case I tested again and the issue was resolved! Nothing changed from when I left on Monday and it was down to Tuesday and it worked, so frustrating.

Anyway, I appreciate your ideas and help with this.


William Bell Mon, 05/03/2010 - 14:12

So, you created a phone with two DIDs assigned.  One DID that would come in Good-GW and one that would come in Bad-GW and both calls would present with the same CLID?

So, up to this point you have:

a. confirmed that the carrier is passing the same CLID and Q931 setup by reviewing the Q931 debug on both gateways

b. confirmed that the CLID is presented to the test phone in the same manner regardless of which gateway handles the ingress call

c. confirmed that CSS and partitions are the same (or relatively the same)

I am assuming that transformation patterns are not at play here as asked previously and possibly proven by (b) (though note that the phone transformation for calling party presentation may play a role if transformations are remotely at play here).

That leaves your application.  Going back to your original scenario, you said that you had two different DIDs and two different CCX applications.  One worked.  Have you checked what happens when you take the DID that comes in your Bad-GW and direct it to the JTAPI trigger/CCX application that you know "works"?




William Bell Mon, 05/03/2010 - 13:05

Something is different with the presentation of your CLID in the second scenario. I am not sure what ingress call path would select one gateway over the other. But assuming there is some difference based on called party number, you could take an IP phone and place two numbers on it. One where the call would flow through Good-Gateway and one where the call would flow through Bad-Gateway. On the IP phone look at the calling party display to see if something is different.

If you are running CUCM 7.x, you may want to check calling party transformation settings on your gateway for ingress calls.

In all versions of CUCM 7.x, you may want to check any translations you have that may be erroneously manipulating the CLID. For the test above, you may want to make sure you mirror as much of your production objective as possible. Then take pieces out of the call flow until you narrow things down.

Another tool that may help is the Dialed Number Analysis (DNA) tool. If you have enabled DNA on your system, you can access the tool via https://ipOfPublisherNode/dna.





This Discussion