Let me explain a little more.

The Route Pattern configured with a Force Authorization Code is not pointing to an intercluster trunk, its pointing to an H.323 gateway which has PRI's for off-net calling, the inbound call is coming from an intercluster trunk.

Path

Phone A ---- Cluster 1 ---- Intercluster Trunk ---- Cluster 2 ---- H.323 Gateway

All calls on Cluster 2 must use a Forced Authorization Code.  Cluster 1 is company A and Cluster 2 is company B.  When an employee from Company A places a call they dial 9 and the number.  Cluster 1 routes this call using it own gateways.  When an employee from Company B places a call from phone A they dial 8 and the number.  Cluster 1 routes all calls with 8 to Cluster 2 via the Intercluster trunk.  Cluster 2 requires a force authorization code for all calls out.  When Forced Authorization codes are enabled on Cluster 2 Route Patterns, the call fails with reorder and no specific error in the debug.  If I disable Forced Authorization codes on Cluster 2 the call is successfully completed.

What I trying to find out is whether the system will prompt inbound calls from an intercluster trunk, destined for outbound gateways, to enter a Forced Authorization code.

Hi Myron,

okay, that makes sense, the short answer is no but there may be a workaround.

If you configure your Cluster 1 8.XXXXX! route patterns to send calls to Cluster 2 with an FAC, then on Cluster 2 configure route patterns in a new partition pointing to the route lists containing the H323 gateway with no FAC.  Put this partiton in a new Calling Search Space and apply it to the intercluster trunk on Cluster 2.  This will require the user in Cluster 1 to input an FAC to get out the H323 gateway in Cluster 2, alternatively, if you don't want users in Cluster 1 to have to enter an FAC you can disable it on the 8.XXXX! intercluster route patterns.

The users in Cluster 2 won't have access to the partition with the route pattern without an FAC and so will still be required to enter one.

The major drawback of this solution is that the FAC won't be in the Cluster 2 CDRs which may be an issue if you use it for reporting or billing.

Hopefully this makes sense and at least puts you on the track to resolving this,

regards,

Paul

Thanks Paul, but that's one of the issues, we need to see the FAC on cluster 2 for billing purposes.

Hi Myron,

Unfortunately I don't think you're going to be able to do this.  It may be a case of doing something a little bit creative with the billing software to make sure it's billed correctly, correlating the calling DN in the cluster 2 CDR to the FAC in the cluster 1 CDR maybe.

good luck and if you find a solution I'd be interested to hear about it,

regards,

Paul