We are having trouble passing Caller ID to certain cell phones. Nextel and Sprint cells both work great receiving caller ID but AT&T and Cingular both have lots of problems. We have a CM cluster passing to a VG200 with ISDN PRI's. We are passing caller ID correctly otherwise to the outside world. Anyone have any ideas or similar problems??
In the gateway settings in call manager, check your numbering plan. Calling party should be national. Calling number plan should be ISDN. Some switches will not display or forward the IE if the numbering plan is "unknown" in Q.931 messages.
We are also having trouble passing to AT&T cell phones - but otherwise passing OK to the rest of the world - we had assumed this was a misconfiguration with our telco provider's switch . I would be interested to know if anyone pins this directly on an actual AT&T Cisco issue - but it sure seems like if it's getting through the teclco switch (a Lucent 5ESS in this case) it would sure seem like it should get everywhere :-(
Our calling party is Call Manager and and calling number plan is Call Manager - will there be any possible ill effects to watch for by changing these? I assume the Call Manager setting attempts to determine the best setting on a call-by-call basis?
Changing that setting will require the gateway to be reset before taking effect. Other than that it's just changing the messages in the Q.931 IE. It should have no effect on the call (keyword: should). I have had this probelm with a variety of switches and it all just depends on how the carrier has them setup too. Some will only allow you to pass certain information, some use match lists, etc. You can run a debug isdn q931 on the gateway and make a call and see how making this change effects the IE being sent to the carrier.
Here in Minneapolis, all of the cell providers pass our CID. Our set-up was Plan=callManager IE=CallManager. The only exception was T-mobile (coincidentally the provider for our IT staff, no urgency there right?) T-Mobile informed me that they have the only Nokia switch in the area and they see the calls with "unknown" and "unknown" for Plan and IE. The default on the switch was to not pass the ANI even though they saw it, b/c the plan and IE were "unknown". I ran a debug on our 2600's (PRI's to MCI and Qwest) and sure enough I was passing out "unknown" for Plan and IE. After asking T-mobile to look at their switch settings, I tested the problem out both trunks. MCI switched my info somewhere b/c they passed "National" and "ISDN". Qwest, however left it the same. After confirming with qwest, I changed my PRI settings to National and ISDN and bounced the trunk. The next call out passed all the info and the cell phones saw the CID.
In the end it was T-mobiles problem but fixable on my end. We had to do the same thing in Fort Collins for AT&T. The Qwest guy told me that they had a similar problem when forwarding AT&T users to the AT&T v-mail in Seattle. When the user got there, the v-mail system did not recognize the v-mail box and sent them to the top of the tree, asking for their box number.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...