01-13-2011 06:02 AM - edited 03-16-2019 02:51 AM
Hi
I’m using H323 gateway with 2 or 4 BRI interfaces configured in a trunk group for PSTN access. I have a problem with correct failover when one of the BRI ports is unavailable. Here is the configuration
trunk group PSTN-Trunk
max-retry 4
voice-class cause-code 1
description *** 2 BRI trunk group to local PSTN ***
hunt-scheme round-robin both down
voice class cause-code 1
no-circuit
temp-fail
dial-peer voice 90 pots
trunkgroup PSTN-Trunk
tone ringback alert-no-PI
description *** Outbound to PSTN ***
destination-pattern 0.T
direct-inward-dial
interface BRI0/3/0
description --- PSTN ---
no ip address
no logging event link-status
no snmp trap link-status
isdn switch-type basic-net3
isdn point-to-point-setup
isdn incoming-voice voice
isdn static-tei 0
trunk-group PSTN-Trunk
interface BRI0/3/1
description --- PSTN ---
no ip address
no logging event link-status
no snmp trap link-status
isdn switch-type basic-net3
isdn point-to-point-setup
isdn incoming-voice voice
isdn static-tei 0
trunk-group PSTN-Trunk
With this configuration when one of the BRI lines will be unavailable, because the line is down (cause code temp-fail) or the provided does not allow the call (cause code 34 no-circuit) and the hunt algorithm will point the outgoing call to that BRI, call will fail over to the next interface, this is ok. But now if I will drop the call (disconnect on the IP Phone) in this moment, the voice gateway will still complete unexacting call! This call is not visible in show voice call status, show isdn active, only show isdn status will show that one of the B channels is used. The
I have few question regarding this, does someone experience this problem or know a better way to implement failover in the trunk group? Maybe somebody can point me to a good document explaining the failover in the trunk group, because there is very little told about why to use max-retry command without which the failover will not even work.
Thanks
01-13-2011 12:12 PM
Stuck calls is a bug. Update IOS.
01-14-2011 12:59 AM
Thank you for your reply.
I'm using ISO ver 12.4(15)T12 - c2800nm-advipservicesk9-mz.124-15.T12.bin, any change you could provide me with a bug ID ?
Regards
08-13-2014 06:50 AM
The solution is following
no dial-peer outbound status-check pots
in global command
03-21-2011 11:41 PM
To finish this subject, after being unable to identify the bug I contacted TAC for support. In the end I have tested several IOS version like ver. 12.4(20)TX, 12.4.(25)x and they are all effected. This is a bug and the next version without it proposed by TAC is 12.4(24)T4 and 15.X. I did test version 15.1(3)T and the bug is fixed.
A workaround would be to use multiple dial-peers, which I tried, but in my case this would complicate configuration and would be hard to manage.
Regards.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide