cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
566
Views
5
Helpful
5
Replies

CME/SRST Telephony-Dialpeers up/up even when phones not registered

jarogers2
Level 1
Level 1

CME in SRST mode yields up/up dial-peers for the ephone DNs. This results in no inbound calls. Have the exact same hardware/IOS/config on another site and it works properly. Baffles me. Anyone run into this before?

CME 4.1

IOS 124-15

No ephone's registered yet show dial-peer voice summ and show telephony-service dial-peers shows populated extensions and up/up which seems to be the issue since the inbound calls look for those nonexistent devices.

5 Replies 5

htarra
Level 4
Level 4

In order to re-order the dial-peers, you'll need to remove them all (including MGCP created ones) and put back your SRST ones from scratch. Another option would be modify your dial-peers, so they handle inbound calls better and terminate on specific dial peers if possible.

allan.thomas
Level 8
Level 8

Is this a centralised voice deployment where your remote office is running CME SRST for MGCP fallback?

What protocol have you configured on your gateway MGCP or H.323?

I have come across problems before with CME SRST and H.323. The specific problem was that an incoming DDI call 3300 for example was matched against the dial-peer associated with the hunt-list pilot dn 3300 specifically when in SRST.

However, despite changing the preference in the Hunt-list it was still preferred over the VoIP dial-peer to CUCM.

The problem was because the router defaults to variable length matching, and was overcome by disabling it on the VoIP dial-peer to the CUCM by changing the VoIP dial-peer destination-pattern to 3300$.

Obviously this would not be a problem if you were using MGCP with CME SRST fallback. However if you are using H.323 it become a little more complicated, ensure that you do not have overlapping dial-peers.

Run a debug voice ccapi inout, this will give you an indication as to which outgoing dial-peer it is matched against.

Please post your configuration for review.

Allan.

It is centralized with CME in SRST mode. Gateway is H.323 which is a standard we use.

The issue is detailed in a bug TAC showed me. I don't have the documentation currently, but it first showed up in CME 4.0 and only with H.323.

Resolution was to go transitionto MGCP, upgrade to the very latest code, or as a quick fix apply "no huntstop" on the ephone-dn.

I'll see if I can find the bug ID. It was severity 2. Worth noting for anyone putting out H.323 gateway with CME in SRST mode.

Bug ID: CSCse59347

IOS Fixed-In:

12.4(4)XC4

12.4(6)XE1

12.4(9)T1

12.4(9.16)T

Thanks for information good to know.

The issue was that I was using a hunt-group so no-hunstop was not an option on the ephone-dns.

It was CME 4.0 that I came across this problem strangely enough.

Rgds

Allan.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: