We utilize h.323 trunks between regional CM's. When our WAN link goes down we have policies that block the voice traffic from going over VPN. I'm not seeing my IP trunks go OOS even when this WAN link is down. I see that the SIP trunks to SM go OOS, but not the H.323. Are there timers somewhere ?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
H.323 Trunk Timeout
- Thread starter trilogy8
- Start date
Might not be timers, might be more how the maintenance object tests things.
So, with SIP, if CM gets a SIP message back to a SIP OPTIONS ping, then the sig group is in service.
With H323/Q931 signaling, I'm not sure there's anything at the IP layer to validate that. I mean, sure, it'd be smart if CM tried pinging that IP address and put stuff OOS if it got no reply - but you're more than welcome to disable ICMP and forbid pings between the core voice gear networks across the WAN and that ought not take a sig group out of service.
If you tested the sig group or did a display alarms and errors, I'd bet that you'd find something about a test for a h323 sig group that 'passes if my packet gets a reply' even though its your procr sending a SYN and the firewall sending back a RST to tell it to go away and never establish a socket.
So, with SIP, if CM gets a SIP message back to a SIP OPTIONS ping, then the sig group is in service.
With H323/Q931 signaling, I'm not sure there's anything at the IP layer to validate that. I mean, sure, it'd be smart if CM tried pinging that IP address and put stuff OOS if it got no reply - but you're more than welcome to disable ICMP and forbid pings between the core voice gear networks across the WAN and that ought not take a sig group out of service.
If you tested the sig group or did a display alarms and errors, I'd bet that you'd find something about a test for a h323 sig group that 'passes if my packet gets a reply' even though its your procr sending a SYN and the firewall sending back a RST to tell it to go away and never establish a socket.
- Thread starter
- #3
I meant that I don't think CM would use a ICMP ping as a metric to test a H323 sig group because it would work just fine in practice without ICMP being open - so it wouldn't make sense to use it as a basis for taking the sig group in or out of service.
It's probably considering that some or any response to a SYN msg - even if RST - is enough to call the sig group 'in service'.
What if you made a h323 sig group to IP 1.2.3.4 that doesn't really exist and would never reply? or an unused IP in the same subnet as procr so you know a router or firewall in the way isn't going to respond to a TCP SYN. Does your sig group stay up then?
It's probably considering that some or any response to a SYN msg - even if RST - is enough to call the sig group 'in service'.
What if you made a h323 sig group to IP 1.2.3.4 that doesn't really exist and would never reply? or an unused IP in the same subnet as procr so you know a router or firewall in the way isn't going to respond to a TCP SYN. Does your sig group stay up then?
- Status
Similar threads
