My 2811 does not dial area codes beginning with 0. This happened after I upgraded the IOS. I rolled back to the previous version, the same problem is still there. I tried a third version, still the same problem. I did not have any configuration changes during the upgrade.
It works when I modify the translation rule to have a non-zero prefix and dial the non-zero code. But the users do not want to dial an addition non-zero prefix to the called number.
Call-forward all to zero-prefixed numbers are working, but 'busy' and 'noan' are not.
The problem seems to be between ip phones and CME. Debug shows the CME does not find a dial-peer, but it sends out busy signal to the phone after it collects the first 2 digits. All later digits are ignored.
Any ideas are appreciated.
Solved! Go to Solution.
Hi, the translation rules makes a bit difficult to understand what is the wanted result, can you check with "debug ccsip message" what number is being sent out.
Also if you have fixed lengh numbers in your country I suggest you configure a DP without T to speed-up calls.
Rule 112 can be much simplified but I guess that is not the problem now.
This is a 2 year old system. I started looking after it 2 months ago. I upgraded the IOS for a non-voip feature, which with no reason broke the MS VPN. So I changed back the IOS and VPN is fixed, but the voip problem occurred.
I am in New Zealand. I will do the debug test the first thing tomorrow morning.
The translation rules are not triggered in this case, no dial-peer is selected before cme sends out busy signals. On the phone display, only the first 2 digits are displayed as the called number. In a successful call, the display should include all the dialed digits plus the translated prefix.
Thank you very much.
"debug ccsip message" shows nothing when I call a number starting with 0. No DP is triggered:
"debug voip dialpeer" shows: digit 0 is the only called number.
000363: May 20 08:05:45.641: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Calling Number=099254311, Called Number=, Voice-Interface=0x48B91B80,
Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH
000364: May 20 08:05:45.641: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Result=Success(0) after DP_MATCH_ORIGINATE; Incoming Dial-peer=20038
000365: May 20 08:05:46.161: //-1/CD17E31680E9/DPM/dpMatchPeersCore:
Calling Number=, Called Number=0, Peer Info Type=DIALPEER_INFO_SPEECH
000366: May 20 08:05:46.161: //-1/CD17E31680E9/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=0
000367: May 20 08:05:46.161: //-1/CD17E31680E9/DPM/dpMatchPeersCore:
Result=Partial Matches(1) after DP_MATCH_DEST
000368: May 20 08:05:46.161: //-1/CD17E31680E9/DPM/dpMatchPeersMoreArg:
"debug voip ccapi inout" and "debug ephone detail" are attached.
Can you beging configure a more proper DO?
Like, destination-pattern 0........
Avoid using T for fixed lenght numbers.
I tried a specific DP for a mobile number. "debug ccsip message" still shows nothing.
dial-peer voice 21856588 voip
translation-profile outgoing outgoing-calls
session protocol sipv2
session target ipv4:184.108.40.206
That is a bit strange, suggest you experiment with a barebon DP to see if at some point the call goes out and then start from there.
What do you mean by bearbon DP?
I doubt this is something related to FW that does not match the IOS, as this happened only after I changed IOS. And non-zero numbers are OK.
You are absolutely right. It is the configuration issue. I have found it at last.
The older version IOS used 'after-hours exempt'; the newer IOS does not take this command. Instead, it takes 'after-hour exempt'. There is no 's'.
Can I blame Cisco for this?
Thanks for your direction.
No problem. I personally blame cisco for anything, they are not offended.
Thanks for the nice rating and good luck!