Outgoing calls fail on SRST router in fallback

[kallan]

Has anyone come across a problem using th NM-HDV-2E1 Pri module in SRST fallback? We are running CCM 3.2.2c spF and a 3620 router with IOS 12.2.11T. The router is configured as a H323 gateway with pots dial-peers with a destination-pattern 9 Everything works OK during during operation and PSTN calls go out the router when users phone numbers beginning with '9'. When the router goes into fallback, all the phones configured for SRST fallback to the router and they can ring each other. Incoming DDI's also work OK. The problem is with outgoing calls, when the users press '9', the PRi does not wait for the remaining digits, it just makes a call immediately with no destination. Debug isdn q931 shows the router trying to make a call. I have tried changing the dest-pattern to 9T but no change, I have also put a full phone number in and dialled the number but as soon as the user presses '9' the Pri tries to make a call. Using the 'csim start 901234567' the router performs correctly and makes a call to 901234567. I have removed the dia-peers and used the 'callmanager-fallback' command 'access-code pri 9 direct-inward-dial' to create virtual dial-peers but we see the same problem - any ideas?

Config:

dial-peer voice 10 pots

preference 1

destination-pattern 9

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind connect enable 8

direct-inward-dial

port 1/0:15

!

dial-peer voice 11 pots

preference 2

destination-pattern 9

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind connect enable 8

direct-inward-dial

port 1/1:15

call-manager-fallback

limit-dn 7960 1

ip source-address 172.20.5.1 port 2000

max-ephones 24

max-dn 24

date-format dd-mm-yy

[tringwelski_2]

check out the access code, it states its optional, but srst doesnt work w/o

call-manager-fallback

access code pri 9

[jtvedte]

try adding:

isdn map address . plan unknown type unknown

to the D channel serial interface.

[kallan]

Hi,

Thanks for your feedback but unfortunately it did not resolve the problem.

If you have any other thoughts please let me know otherwise I will be raising it with TAC

Regards, Keith

[jtvedte]

I'd suggest you turn on isdn Q.931 debugging - and watch a successful call - and then put the router in SRST mode - and watch what it does....

At that point, hopefully it will be somewhat more obvious what is/isn't working....

But - if that doesn't work - I'd suggest opening a TAC case.... :o(

You can attach the debug output to the case notes....

[kallan]

John,

Thanks for your reply. Debug isdn q931 shows the calling party as the extension from where you are calling from but the called party shows blank. It appears the dial-peer has matched the '9' and tried to make a call on zero digits. I have now opened a TAC case.

Thanks again, Keith

[bart-peters]

your dail peer has to wait for extra digits in SRST mode and you didn't configure it to do that. just change you outgoing dial peer pattern in:

destination-pattern 9T

You could also adjust the timeout interdigit (default is 10 seconds) because you have to wait for that time before the call will be made after you dialed the last digit

and it has to be a capital T

dial-peer voice 10 pots

preference 1

destination-pattern 9T

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind connect enable 8

direct-inward-dial

port 1/0:15

!

dial-peer voice 11 pots

preference 2

destination-pattern 9T

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind connect enable 8

direct-inward-dial

port 1/1:15

[kallan]

Hi,

Thanks for the reply. The answer as you say was in fact to place a 9T on the destination pattern. In addition to adding the 9T to the normal H323 dial-peer voice X pots, I had to add the "access-code pri 9T direct-inward-dial" command, note also with the 9T. I had not tried adding the 9T to both the dial-peer AND the call-manager-fallback command. Once this was added the SRST worked fine.

Regards,

Keith.