Forum Discussion

JaySummerfield's avatar
JaySummerfield
Copper Contributor
Sep 24, 2020

Direct Routing - Q.850 Cause 63 Get Inbound Direct routing - no trunk config found in ACMS

I'm currently attempting to setup Direct Routing on a new SBC cluster which is a direct copy of an existing server with just new FQDNs and IP addresses.

 

I can make calls fine from all users, however inbound calls get the following Cause 63 Forbidden message:

 

REASON: Q.850;cause=63;text="3590c12b-5610-41e1-9266-1d135e125008;Get Inbound Direct routing - no trunk config found in ACMS."

 

I've attempted to remove and recreate the users on the SBC domain as well as remove and add licences but I still get the same.

 

The SIP INVITE looks identical to the platform that works apart from the FQDN now being the new cluster address which is active on the Tenant.

 

Has anyone seen this specific trunk config ACMS error before?

  • DanLeaf810 I was meant to update this at the time. I had to remove the domains in full from Microsoft 365 and add them again (not forgetting to activate them by assigning users).

     

    I didn't find one specific thing that was wrong when checking the setup end-to-end so can only assume something didn't activate correctly on the back end. Having removed the SBCs from the Teams admin portal and the domains and started from scratch all worked second time around.

  • JaySummerfield this problem is mainly due to wrong contact header, check the invite sent to teams and check the  header specially the sbc fqdn l.

    • rmahajan701's avatar
      rmahajan701
      Copper Contributor

      MoHussein 

      I am facing the same issue. Let me explain it as it is:

      We have a very simple setup for Microsoft Teams direct routing. Everything is working fine with incoming and outgoing calls.

      We are facing problems after implementing LBR. I am stating a problem as it is with respect to the setup we have.

       

      We have users who are sitting in the office , using team applications on their PCs and able to make and receive calls.

      Now we have implemented LBR to restrict these users to make calls when they are not connected to the office network or restrict when they are trying to make calls from any network except the office.

      Now in the office the private network is 192.168/168.0/24 and public IP is X.X.X.X/27.

      I have defined the private subnet in the network topology subnet And public IP's in the trusted IPs list.. So , ideally the call should work when users are trying from the office network. But the problem is calls are not working even from the office network which is allowed as per  the LBR.

      Users are getting error : calls failing with Get Outbound Direct routing - no trunk config found by LBR selection criteria.

    • JaySummerfield's avatar
      JaySummerfield
      Copper Contributor

      DanLeaf810 I was meant to update this at the time. I had to remove the domains in full from Microsoft 365 and add them again (not forgetting to activate them by assigning users).

       

      I didn't find one specific thing that was wrong when checking the setup end-to-end so can only assume something didn't activate correctly on the back end. Having removed the SBCs from the Teams admin portal and the domains and started from scratch all worked second time around.

      • DanLeaf810's avatar
        DanLeaf810
        Copper Contributor

        JaySummerfield - thanks for getting back to me so quickly - appreciated ! I'll give that a go as all looks fine with the setup and I can't find any other articles relating to the issue. 

  • fowler_23's avatar
    fowler_23
    Iron Contributor

    JaySummerfield 

    Hi,

     

    In the INVITE message to Teams from the SBC.  Can you check the message and check that the SBC FQDN is correct and matches the OnlinePSTNGateway configured?

     

    You want to make sure it's not the local FQDN e.g. your SBC may be contoso.local but the MS FQDN is configured as contoso.com.  If the SBC isn't configured correctly, it could be sending out the wrong FQDN which means MS wouldn't accept your incoming message

     

     

Resources