H.323 Trunk issue

[KBCap]

Hi I have an issue that is starting to Vex me. To picture the scene, we have 2 H.323 trunks 30 channels each. each is supplied from a geographically different location over different infrastructure to a single far end CM and are identical in setup I do not have visibility on the third party CM but have had screenshots (which I cannot post) which indicate that they mirror our config.
The sig groups are up both ends. the trunks groups come up in service both ends and we can make and take calls (So where’s the problem your thinking)
the problem we have is that if left unused say over night when a call is placed in the morning the call proceeds & connects but no audio either way. This happens across both trunks. if we busy / release the trunks service is restored. There don’t appear to be any alarms or errors generated for the outage of the audio. Below is the config Sig & Trunk. The node names have been altered for security of the customer.

Any insights leading to a resolution will be met by a party in your honour though maybe not an invite.


SIGNALING GROUP

Group Number: 400 Group Type: h.323
Remote Office? n Max number of NCA TSC: 0
SBS? n Max number of CA TSC: 0
IP Video? n Trunk Group for NCA TSC: 370
Trunk Group for Channel Selection: 370
TSC Supplementary Service Protocol: a Network Call Transfer? n
T303 Timer(sec): 10
H.245 DTMF Signal Tone Duration(msec):
Near-end Node Name: clan3b02 Far-end Node Name: ***IPTRUNK1
Near-end Listen Port: 1720 Far-end Listen Port: 1720
Far-end Network Region: 163
LRQ Required? n Calls Share IP Signaling Connection? y
RRQ Required? n H245 Control Addr On FACility? n
Bypass If IP Threshold Exceeded? n
H.235 Annex H Required? n
DTMF over IP: in-band Direct IP-IP Audio Connections? n
Link Loss Delay Timer(sec): 90 IP Audio Hairpinning? n
Enable Layer 3 Test? y Interworking Message: PROGress
DCP/Analog Bearer Capability: 3.1kHz

Trunk Group

TRUNK GROUP

Group Number: 370 Group Type: isdn CDR Reports: y
Group Name: *** IP TRUNK 1 COR: 80 TN: 1 TAC: 1370
Direction: two-way Outgoing Display? n Carrier Medium: H.323
Dial Access? n Busy Threshold: 255 Night Service:
Queue Length: 0
Service Type: tie Auth Code? n
Member Assignment Method: auto
Signaling Group: 400
Number of Members: 30
Page 2

Group Type: isdn

TRUNK PARAMETERS
Codeset to Send Display: 6 Codeset to Send National IEs: 6
Charge Advice: none
Supplementary Service Protocol: a Digit Handling (in/out): enbloc/enbloc


Digital Loss Group: 18
Incoming Calling Number - Delete: Insert: Format:

Disconnect Supervision - In? y Out? n
Answer Supervision Timeout: 0
CONNECT Reliable When Call Leaves ISDN? n

Page 3

TRUNK FEATURES
ACA Assignment? n Measured: none
Internal Alert? n Maintenance Tests? y
Data Restriction? n NCA-TSC Trunk Member:
Send Name: y Send Calling Number: y
Used for DCS? n Send EMU Visitor CPN? n
Suppress # Outpulsing? n Format: public
UUI IE Treatment: service-provider

Replace Restricted Numbers? n
Replace Unavailable Numbers? n
Send Connected Number: y
Network Call Redirection: none Hold/Unhold Notifications? n
Send UUI IE? y Modify Tandem Calling Number? n
Send UCID? n
Send Codeset 6/7 LAI IE? y

 

[kyle555]

Is it only overnight or during long periods of inactivity? Something's goofy network side and the best you can do is prove that out. Do a station trace when the call goes out. Since you're not direct IP in your sig group, you're always going through a gateway.

Silly question - what does the inter-network region connectivity to the far end 163 look like? If 1-->163 and 2-->163 and 3-->163 is direct WAN always yes, then CM considers ALL media gateways equidistant from the far end.

Say your far end of your IP trunk is in Boston. That condition would mean a IP phone in New York could theoretically pick a DSP off any gateway over any WAN link to get to Boston. Got gateways with "direct wan" in London, Paris, Tokyo, Prague, Seattle and New York? Improper NR configuration could cause a round robin effect there.

Obviously your signaling channel stays up and rings the far end to get a no audio condition in the first place - so that's good. Without seeing a trace of a good/bad call to see if they use different gateways, I'd maybe recommend putting the far end network region 163 behind your core site's DSPs to force traffic through that.

To say, if your main office were NR250, 163 would be direct wan to 250, but direct wan no to every other region and go through intervening region 250 to hit 163. Also, inter/intra region shuffling NO for 163. That would at least guarantee the same media path every time and make troubleshooting a little easier when you bust out wireshark if you can't already absolutely guarantee which network interface that missing RTP is leaving in your environment