Unifying 3CX with Microsoft 365 - Teams Direct Routing - Part 3 of 3

[urssax]

Interesting thing happening when I go to configure the direct routing...we already have our own FQDN for 3CX, and when I use that in my FQDN line then it will not let me upload the cert files. If I change it to ANYTHING else, then I get prompted to upload the cert files.

Does the FQDN used for Teams Direct Routing have to be different than the public FQDN that we are already using? Or do I proceed through Step 2 and move onto Step 3?

Hello, it worked for me.
In Step 1: I have my own domain "teams.muster.de" and a DNS A-Record to "teams.muster.de" on the 3cx system Open the port on the firewall. For me it is 5062. For you in the picture it is 5061 !!!!!! Certificate bought on "teams.muster.de" both certificates must be in PEM format

 

[charles]

Interesting thing happening when I go to configure the direct routing...we already have our own FQDN for 3CX, and when I use that in my FQDN line then it will not let me upload the cert files. If I change it to ANYTHING else, then I get prompted to upload the cert files.

Does the FQDN used for Teams Direct Routing have to be different than the public FQDN that we are already using? Or do I proceed through Step 2 and move onto Step 3?

The team's FQDN can be the same as your 3cx FQDN as long as the certificate covers the entire FQDN (no wildcards), and the certificate is provided by one of the root certificate authorities, supported by Microsft. Also in this case you will need to make sure that TCP port 5061 is open and forwarded.

 

[NickD_3CX]

Hi @p.reitter

- Does the CRM Integration also work when using Teams as a client? Does it show the correct name, when you receive an external call over teams?

It depends. When CRM Integration is enabled, on incoming calls, 3CX will always check if the Caller Number exists in the CRM and add it as a CRM Contact in 3CX. This means that when the Caller calls in a second time, regardless what client you are using the Name of the Caller will appear as it is in the CRM.

CRM Integration though also the function to launch the Customer tab in the CRM interface. This will only work when using the 3CX WebClient or Desktop App.

In general, for such scenarios and for people that primarily operate in Queue and with CRM Integrations, you should have them use the 3CX Client, not Teams.
The recommended usage of the Teams Integration is also very well laid out here:
https://www.3cx.com/community/threads/teams-direct-routing-with-resource-accounts.83711/post-391624

- Is it possible to transfer the calls using the Teams Client?

Yes, more information here:
https://www.3cx.com/community/threads/v18-beta-2-a-step-closer-to-final-release.83013/post-386131

 

[h4x]

The team's FQDN can be the same as your 3cx FQDN as long as the certificate covers the entire FQDN (no wildcards), and the certificate is provided by one of the root certificate authorities, supported by Microsft. Also in this case you will need to make sure that TCP port 5061 is open and forwarded.

Hi Charles,
So I'll use my existing FQDN for my Teams SBC...cool...but this doesn't answer the question of what is happening during setup. Is this normal behavior for the setup to hide the upload fields for the certificate if I am using my existing FQDN? That's the part that I don't understand.

 

[Evolute IT]

Hi Charles,
So I'll use my existing FQDN for my Teams SBC...cool...but this doesn't answer the question of what is happening during setup. Is this normal behavior for the setup to hide the upload fields for the certificate if I am using my existing FQDN? That's the part that I don't understand.

Yes, because the Secure SIP will use the same certificate as the PBX itself.

In other cases, we need different certs because the FQDN is not the same.

 

[charles]

Th

Hi Charles,
So I'll use my existing FQDN for my Teams SBC...cool...but this doesn't answer the question of what is happening during setup. Is this normal behavior for the setup to hide the upload fields for the certificate if I am using my existing FQDN? That's the part that I don't understand.

This is correct, as stated by the message, that the secure sip certificate will be used if the team's SBC FQDN is the same as the FQDN of the 3cx system, and as this is already in the 3cx system there is no need to re-upload it. The secure sip section is found under the management console > Security > Secure Sip, here you will see the certificate and the intermediate certificates in the certificate section, and under this is the Private key. We have also recently released a very detailed FAG which will also help: https://www.3cx.com/docs/microsoft-teams-integration-faqs/.

 

[h4x]

Yes, because the Secure SIP will use the same certificate as the PBX itself.

In other cases, we need different certs because the FQDN is not the same.

Thank you for clarifying...we were previously using a wildcard cert, and I have my new standard cert ready, but haven't updated the server with that yet.

I know there has been a lot of discussion on this threat about the use of a wildcard cert, and I found it interesting that when you look at the list of Microsoft approved certificate providers, it does mention that a wildcard is acceptable under certain circumstances:
Alternatively, Direct Routing supports a wildcard in the CN and/or SAN, and the wildcard needs to conform to standard RFC HTTP Over TLS. An example would be using *.contoso.com which would match the SBC FQDN sbc.contoso.com, but wouldn't match with sbc.test.contoso.com.

 

[h4x]

Th

This is correct, as stated by the message, that the secure sip certificate will be used if the team's SBC FQDN is the same as the FQDN of the 3cx system, and as this is already in the 3cx system there is no need to re-upload it. The secure sip section is found under the management console > Security > Secure Sip, here you will see the certificate and the intermediate certificates in the certificate section, and under this is the Private key. We have also recently released a very detailed FAG which will also help: https://www.3cx.com/docs/microsoft-teams-integration-faqs/.

Thanks for the clarification, Charles.

I would argue that the message isn't inherently clear in its wording, but that it makes sense post-fact in knowing what the behavior is. For the dummies like me out there, I was like, "Ok, great...I'm glad its using Secure SIP...I need to upload my certs for the Teams SBC..." It might be good to update the documentation to add this information.

 

[NickD_3CX]

I know there has been a lot of discussion on this threat about the use of a wildcard cert, and I found it interesting that when you look at the list of Microsoft approved certificate providers, it does mention that a wildcard is acceptable under certain circumstances:

I mentioned this in an earlier post, a Certificate that covers that exact FQDN you have set and not to be a wildcard is a 3CX requirement.
I explained why here.

 

[h4x]

I mentioned this in an earlier post, a Certificate that covers that exact FQDN you have set and not to be a wildcard is a 3CX requirement.
I explained why here.

Right, right...I was just commenting that the Microsoft documentation notes the wildcard use...which could be a point of confusion.

 

[h4x]

We have also recently released a very detailed FAG which will also help: https://www.3cx.com/docs/microsoft-teams-integration-faqs/.

Charles, I meant to say THANK YOU for that link...I have been looking for more detailed documentation, but hadn't found that yet.

 

[charles]

Charles, I meant to say THANK YOU for that link...I have been looking for more detailed documentation, but hadn't found that yet.

You are most welcome. I am glad this helps.

 

[TomR]

Anyone trying to do this on an OVH VPS? i think the port is blocked for 5062. Does anyone know how to unblock the port? OVH support are not very helpful.

I tried on an OVH bare metal (with my own VPS) and it didn't work. Never tracked down the issue - it could be that port 5062 is blocked. Mine just hung indefinitely when I tried to pair with Microsoft 365 - didn't even get as far as the Teams bit. Using Vultr VPS now and works fine

 

[David Masters]

Just wondering if anyone has managed to configure this for a Microsoft Teams Rooms device account?

For some reason the device account, whilst set as a 'MEMBER' in Azure AD is not appearing in the potential list of Users to sync from AAD into 3CX.

As a result, there is no connection between AAD and 3CX for theTeams Room account.

 

[David Masters]

Just wondering if anyone has managed to configure this for a Microsoft Teams Rooms device account?

For some reason the device account, whilst set as a 'MEMBER' in Azure AD is not appearing in the potential list of Users to sync from AAD into 3CX.

As a result, there is no connection between AAD and 3CX for theTeams Room account.

*** UPDATE
In case anyone else was having this issue - the cause has been identified and reported here
https://www.3cx.com/community/threa...s-integration-configuration.83907/post-392493

Thank you @hvs

 

[Charles_3CX]

Interesting thing happening when I go to configure the direct routing...we already have our own FQDN for 3CX, and when I use that in my FQDN line then it will not let me upload the cert files. If I change it to ANYTHING else, then I get prompted to upload the cert files.

Does the FQDN used for Teams Direct Routing have to be different than the public FQDN that we are already using? Or do I proceed through Step 2 and move onto Step 3?

If you installed 3CX using a custom FQDN and this FQDN is also within your email domain, within 355, and is the same as your teams SBC FQDN then the Secure Sip configuration of your 3CX will be used with the port 5061/TCP so there is no need to re upload a certificate. See the full guide here for more information regarding this and more, here: https://www.3cx.com/docs/microsoft-teams-integration-faqs/#h.43yy972n40m3

 

[dunkavery]

Hi,
we have a custom cert for the 3cx system but currently using a wildcard for the teams integration- will this work?we believed the custom cert was just for sip\tls part

 

[NickD_3CX]

Hi,
we have a custom cert for the 3cx system but currently using a wildcard for the teams integration- will this work?we believed the custom cert was just for sip\tls part

You cannot use a Wildcard certificate that covers the Teams SBC FQDN you enter in 3CX.
This is covered in our FAQ, which I think you should check out as it may solve many of your questions:
https://www.3cx.com/docs/microsoft-teams-integration-faqs/#h.txihzzszti82
Wildcard certs don't work for SIP TLS either for the same reason.

You need a certificate that covers exactly the FQDN for Teams that you are using.