cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
568
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.