SRST not calling in

[5c5administrator]

Hi,

can soneone please help, I have our remote sites registered to the the Call Manager Cluster with SRST in place if failure on the main WAN path. However a couple of times now on a main WAN failure the telephones have correctly registered to the SRST Router and can make outgoing calls but when calling the main number to the site incoming calls are not working. We only require it to be a basic ring to a telephone when in SRST mode.

Enclosed is a copy of the SRST config.

call-manager-fallback

max-conferences 4 gain -6

ip source-address 10.25.101.1 port 2000

max-ephones 10

max-dn 20

no huntstop

pickup 487320

alias 1 487320 to 3491

alias 2 487320 to 3492

alias 3 487320 to 3493

alias 4 487320 to 3494

alias 5 487320 to 3495

alias 6 487320 to 3496

[karldbrooks]

Are you translating the inbound called number to match extensions? If not ou wil need a dialplan pattern in the SRST config to route the calls.

A copy of the gateway config (removing IP addresses and passwords of course) would help further.

[5c5administrator]

Hi,

Yes I am translating to match 6 telephone extensions.

Regards,

Darren.

[5c5administrator]

Hi,

enclosed is a copy of the config, any help would be appreciated.

Regards,

Darren.

[5c5administrator]

Soory the config did not attach

[5c5administrator]

updated config

[pcameron]

2 possibilities here -

1) The problem is the inwards calls are not being translated (or contracted) to the internal numbering.

2) Since this is H323, the calls are coming in but are being sent to the CallManager and hence are disappearing down the network black hole.

Best thing to do here is put the system into SRST and run 'debug isdn q931' and make an inwards call. This will show us the called number from the PSTN, and also confirm the call clearing reason.

Once we know the exact reason, it will be simple to get this working.

BTW , please add the command 'network-clock-select 1 BRI 0/2/0' to sync up the system clocking correctly.

[5c5administrator]

Thankyou, I will do this either when I can get to site or our of hours remotely.

[5c5administrator]

Hi,

tried a few things such as a third dial peer with a lower preference, different variance of aliases with no success.

Here is the output of the debug isdn q931 when calling the number prior to any modifications.

1d07h: ISDN BR0/2/0 Q931: RX <- SETUP pd = 8 callref = 0x01

Sending Complete

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x89

Exclusive, B1

Called Party Number i = 0x81, '740670'

Plan:ISDN, Type:Unknown

1d07h: ISDN BR0/2/0 Q931: TX -> CALL_PROC pd = 8 callref = 0x81

Channel ID i = 0x89

Exclusive, B1

1d07h: ISDN BR0/2/0 Q931: TX -> DISCONNECT pd = 8 callref = 0x81

Cause i = 0x809B - Destination out of order

1d07h: ISDN BR0/2/0 Q931: RX <- RELEASE pd = 8 callref = 0x01

1d07h: ISDN BR0/2/0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x81

Any help would be appreciated.

Regards,

Darren.

[pcameron]

It looks like you are translating the called number of 740670 to a 4 digit internal number (you have blanked out the specific numbers) in the config.

If this is translated to a specific number that is registered via SRST, the preference of the number should be 0 and the call should ring through to this phone. If there is no phone, then the call will still match on the voip dial peers as they will be the closest match.

first thing we need to know is what number is the 740670 translated to and is this device registered. Secondly , what is the time frame between the setup message coming in and the call being cleared with 'destination out of order' (which suggest the TCP session to the CUCM failed). You should always set debug timestamps to the msec - in config mode 'service timestamps debug datetime local msec'. This will give us an idea of how long it takes the call to fail At a guess, it will probably be around 30-40 seconds.

You can also set up the VOIP dial peers for proper redundancy by lowering the TCP establish timer -

!

voice class h323 1

h225 timeout tcp establish 3

!

!

dial-peer voice 3 voip

voice class h323 1

preference 1

!

dial-peer voice 4 voip

voice class h323 1

preference 2

!

This will drop the tcp establishment timer to 3 seconds , so if the session dos not come up in this time, the second dial peer will be attempted. If the Q931 debugs are still showing the call is failing (in 6 seconds or so this time).

All of the above will prove if the call is not matching on the phone registered in SRST mode. We would still need to confirm why the call is not getting to the handset. Is the phone definately registered to this particular router when it goes to SRST ?

[5c5administrator]

Hi, thanks for your help I was working on it late last night and in fact it was due to the alias command 740670 pointing to the hunt pilot on Call Manager and with the H323 Gateway not having a phone registered with the number it did not know where to go to. Therefore I changed the alias from the pilot number to the extensions rather than 740670 and it worked.

Thanks for all your help on this.

Darren.