CME 15.7(3)M2 with 7800 and 8800 series handsets and a SIP trunk to an external provider
Hello all. I've run into an issue whereby only the first digit of a number dialled is shown on the phone's display once the call has connected. I've have a dial plan to allow users to return missed calls without the nine and that exhibits the same problem. So typically the display shows either a 9 or a 0 but not the rest of the number.
There is a similar post on the same topic here (https://community.cisco.com/t5/ip-telephony-and-phones/cme-phone-only-displays-first-digit-of-dialed-party/td-p/2688386) but the solution to remote no-remote-party-id from sip-ua doesn't work for me. I've tried both options.
I'm fairly new to CME and would be grateful for any advice. Thanks in advance.
Configuration extract attached.
Daniel, I'm afraid not. I've still got this issue. Regardless of whether the number dialled is external or internal, only the first digit is shown on the display as soon as the ringing tone is heard. I've tried all sorts with no success. If you do find a solution please let me know.
Hi Scott. Thanks for your reply. The issue affects calls made as opposed to received. For example. if I was to dial extension 400, the display shows '4'. If I dialled 90123456789, the display shows '9'. Always just the first digit. Incoming caller display from the SIP trunk works just fine and shows the full number.
Thanks for confirming.
Would it be possible to make some test calls (one internal and one external) and provide the following output for me please:
debug ccsip messages
debug voip ccapi inout
One observation in the config, dial-peer 3 which is for your "Internal calls" appears to be pointing at your SIP trunk. I am not sure if that's as a result of your redacted config or not, but I wouldn't have thought that config is required.
Attached as requested. I will also post the current config to avoid any confusion as the original post is now quite old.
I note a few lines which could be of interest in the debug.
020530: Apr 1 11:56:04 BST: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 111
020531: Apr 1 11:56:04 BST: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 1
Does this mean there's an issue matching dial peers? I've included a debug for dialpeer voip all too later on in the same text file.
I've noticed something which may also help to identify what's going on. If the call is placed by dialling the number and then pressing the 'call' softkey the full number is show on the display, if I pick up the handset and dial the number it shows only the first digit.
Thank you in advance.
Thanks Scott. No change I'm afraid. It still reverts to the first digit of the number when dialling off hook. Dialling on hook and pressing 'call' shows the full number.
I didn't forget about you - honest. :-)
So I have been taking a look at this tonight and re-read the point you made about the caller ID showing when the phone is on-hook vs when the phone is off-hook and figured that was pertinent. Apologies for overlooking that point before.
Assuming I am not too late to the party, can you please try the following configuration, on two phones at the moment:
voice register pool 1
no digit collect kpml
voice register pool 2
no digit collect kpml
Reset both phones and then issue the following commands:
voice register global
Test again and let me know what the results are.
If they don't work, please replicate the issue, on-hook and off-hook and take debug ccsip messages for both.
I would also suggest taking debug voip ccapi inout for both two, but provide these seperately to the ccsip messages debug if you have no success.
Great news - no digit collect kpml resolved the called number issue. The phones now display the full number dialled.
A rather significant side issue is that the phones with no digit collect kpml configured take about 10 seconds to place a call after I finish dialling for numbers that are a perfect dial plan match. It's possible to work around this by pressing dial but I don't expect most users would tolerate the delay. I've tried altering the inter-digit timeout but it doesn't make much difference.
I will keep trying to find the perfect solution. Perhaps a newer version of IOS is a good idea. Thanks again for all your help.