CME 4.2 SRST with h323 CCM 4.1.3

Unanswered Question
Aug 24th, 2007

Hi,

We currently have a local CCM 4.1.3 cluster with local E1 gateways and need to add a new remote site.

The solution I'm building (in lab first) will use a CME 4.2 on the remote site configured with SRST in case the link falls.

When the link is up, the remote users should register to the CCM but still use the CME as their gateway out to the PSTN.

For this to work, I have configured the CME as a h323 gateway in CCM.

For outbound calls all is working fine, for inbound calls, it seems that the CME is matching it's own dial-peers first.

When the link is up this means that the phones will not receive inbound calls.

To fix this issue, I have added the $ in my voip dial-peer destination patterns.

When doing this inbound calls work as well, but the problem is that the phones only start ringing after the caller has allready heard about 2 or 3 rings on his phone.

Is there a way to get this time down so that the phones start ringing directly?

Thanks in advance fort the help.

Jeroen.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
juscraig Fri, 08/24/2007 - 10:54

Hi Jeroen,

Help me understand this better. What is your PSTN connectivity (E1 PRI?) at the remote site where you are running CME and what is your WAN connectivity?

Why even run CME code at the remote site? Is there a reason you are wanting to do this? You can just configure this Voice Gateway as an H.323 gateway and register it with your CallManager cluster, and then use SRST if the WAN fails.

For ingress calls to your CME site,

are they not coming in on your local E1 in that site? If so, they have to hit an inbound pots dial-peer there first. Then the Pots call leg is terminated on the CME, and a VoIP call leg is created to CCM, then the phone should ring. (If the dial-peers are set up correctly).

What is the latency over the WAN from your CME site back the CCM Cluster?

jeroenhermans Sat, 08/25/2007 - 10:13

Hi,

Thanks for your reply. The PSTN connectivity in lab where I'm testing this for the moment is analog with a vic2-2fxo card.

When we will roll it out in production it will be with a E1 PRI.

We want to run CME at the remote site because we need to have the added functionality

like login to hunt groups when the connectivity to the central site is lost.

Calls are indeed coming in via the local pstn connection on the remote site. they match a pots dialpeer and then they need

to match a voip dial peer going to the callmanager at the central site. The problem is that they are mathing the dial-peers that CME

automatically creates when you configure ephones and dn's. To get around this problem, I added the $ after my dialpeer that is pointing to the callmanager.

This works, but it takes about 2 rings before the ipphone actually starts to ring.

When I remove the ephone and dn's configuration on the CME, the phone starts to ring directly. Offcourse, when the link fails, the phones are not configured on the CME this way and no calls can be received/placed.

In production it will be an MPLS network with COS setup for voice, so very limited latency

Tanks for your help.

J.

johutchins Sat, 08/25/2007 - 17:06

Easy fix: Make the gw MGCP

From the CME Sys Admin book:

The option defined with the "srst mode auto-provision" command determines whether Cisco Unified CME adds the learned phone and extension information to its running configuration. If the information is added, it appears in the output when you use the show running-config command and is saved to NVRAM when you use the write command.

?Use the "srst mode auto-provision none" command to enable the Cisco Unified CME router to provide SRST fallback services for Cisco Unified Communications Manager.

--Jon

jeroenhermans Sun, 08/26/2007 - 23:27

Hi,

Thanks for your answer.

Making the gateway MGCp is not an option as we need to have support for T38 faxing using a fax over Ip solution. With our version of callmanager, this only works with h323.

This is a piece of my config, you will see that it is configured with the srst mode auto-provision none command :

telephony-service

srst mode auto-provision none

srst ephone description Cisco Unified CME SRST Fallback : Aug 17 2007 14:53:32

srst dn line-mode dual

fxo hook-flash

load 7960-7940 P00308000400

max-ephones 24

max-dn 72

ip source-address 10.10.1.77 port 2000

calling-number initiator

timeouts interdigit 3

system message SRST active.Limited Features

time-zone 5

time-format 24

date-format dd-mm-yy

max-conferences 8 gain -6

call-forward pattern .T

call-forward system redirecting-expanded

moh music-on-hold.au

web admin system name admin password engineer

dn-webedit

time-webedit

transfer-system full-consult dss

transfer-pattern 0.T

secondary-dialtone 0

create cnf-files version-stamp 7960 Aug 20 2007 11:30:00

Thanks,

Jeroen

Actions

This Discussion