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

Unanswered Question
Oct 8th, 2008
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
htarra Tue, 10/14/2008 - 06:47
User Badges:
  • Bronze, 100 points or more

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 Tue, 10/14/2008 - 07:49
User Badges:
  • Blue, 1500 points or more

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.


jarogers2 Tue, 10/14/2008 - 07:59
User Badges:

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.

allan.thomas Tue, 10/14/2008 - 08:13
User Badges:
  • Blue, 1500 points or more

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.




This Discussion