Hi Paolo,

I believe you, so I compared a few times the current config against the old working configuration. But I failed to find any differences.

Please find attached a reduced version of the current config.

Thanks in advance.

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.

Hi,

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.

Hi Paolo,

"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

tt-triton-cme#

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:

Result=MORE_DIGITS_NEEDED(1)

"debug voip ccapi inout" and "debug ephone detail" are attached.

Thanks.

Can you beging configure a more proper DO?

Like, destination-pattern 0........

Avoid using T for fixed lenght numbers.

Hi,

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

destination-pattern 021856588

redirect ip2ip

b2bua

session protocol sipv2

session target ipv4:202.162.176.51

dtmf-relay rtp-nte

codec g711ulaw

Thanks.

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.

Hi Paolo,

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.

Thanks.

Hi Paolo,

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!