H.323 Trunk Setup - LRQ

[RatX]

Would greatly appreciate any assistance with this one:

I'm in the process of implementing H.323 trunks between our Avayas (CM3.1 & 4) and a voice provider over their MPLS network. Their setup requires separate trunks for inbound and outbound traffic, with their gatekeepers managing the distribution between the two.

In the outbound H.323 trunk signalling group settings, they requested that we set "LRQ Required?" to "y" and use port 1719 for our local C-LAN and the remote gatekeeper. However, as long as LRQ is set to y, no signalling traffic is generated on the LAN or their CE's (monitored through a sniffer). If we switch LRQ to n on the signalling group, signalling traffic is generated, but calls are not established.

Information on LRQ is hard to find, the Avaya configs in this doc are similar to our own:

http://www.avaya.com/master-usa/en-us/resource/assets/applicationnotes/CM-H323-CiscoGK.pdf

For our outbound testing, we are dialing the trunks' TAC's, we haven't implemented the full dialplan yet. Any ideas why the LRQ setting would block our signalling traffic, or is there an additional setting (outside of signalling group, trunk group, network-region and codec-set)? H.245 specapp is enabled.

We haven't tested inbound yet, but outbound is our main concern at this stage.

Thanks for any info!

 

[jarett56]

One thing to make sure of is that the near-end listen port and the far-end listen port on your signaling group is set at 1719. Then on their side it needs to match exactly as you have it programmed. This can cause calls to not establish or one-way established calls.

I typically use 1720 versus 1719 when creating IP trunks between my Avaya an out other smalle s8300/G700 stand alone systems.

The IANA well know ports are listed here for H.323 signaling ports.
1718 h323gatedisc.
1719 h323gatestat.
1720 h323hostcall.

On 3.1 and 4 CM you also need to verify the clan ip-interface you are using has the following fiels set to yes for phones and gateways.

Allow H.323 Endpoints? y
Allow H.248 Gateways? y
Gatekeeper Priority: 5

I don't know if any of this will help, but I'll keep digging a little.

J

 

[RatX]

Thanks for the info, jarett56. FYI, we were able to resolve this issue yesterday - our error was that we were testing by dialling the TAC directly. Without LRQ enabled, simply dialling the TAC generated the expected signalling traffic.

With LRQ enabled, it was necessary to first set up AAR and a route pattern - after that, the signalling info was immediately generated and after some fine tuning we were able to establish calls.