Two SBC lookin on the same IP adress. First SBC is working, second SBC is not.

[DmitryZhukovVVT]

I have a Microsoft tenant, Added the main domain. Created SBC for sip router. All working.
I added a second SBC on the same sip router. But at this time incoming calls to the second SBS don't work. I use a wildcard certificate for both SBC on the sip routers. But I can't see any logs about the second SBC, but I see logs about the first. Looks like teams don't send options to the second SBC.

[#2]

Hi,

Did you setup two SBCs with the same IP address? Then it sound like you have an active/passive setup, so all traffic will be sent to the active SBC until that SBC fail and the passive SBC becomes the active one.

[#3]

Actually, I wanted to use a different SBS, not active/passive. I planet separate calls inside my sip router. Is it possible? For example, if I separate SBS by different port?

[#4]

You will need one public IP for each SBC. Add both SBCs in the Teams Admin Center and add both to the same Voice Routing, then Teams will send calls to both of them.

[#5]

@LinusCansby small clarification. Calls from teams to our SIP router work for both SBC. Outgoing from the SIP router to the teams work only for the first SBC.
In the teams administration console, the second SBC displays TLS inactive, and SIP options - No SIP OPTIONS.
Everything is fine with the first SBC. I tried deleting the SBC and adding a new one but in the opposite order. First after the second. Nothing has changed, the second SBC continued to be in such a state (inactive). As soon as I added the first one, it (first what have no problems) immediately assumed the active state.
In the logs of the SIP router, we do not see anything to the second SBC. But we see constant requests to the first SBC.
Yesterday we tried to split the SBC into different ports, but it was unsuccessful.
As I wrote above, the certificate for both SBCs is the same wildcard.

[#6 · Accepted solution]

It is okay to use a wildcard certificate on the SBC.

It sounds strange that Teams sends calls to a SBC that it says is inactive, should not be possible. I guess there is something wrong with the "SIP Gateway", you should check with the partner that deployed these for you.

Each SBC should have a public routable IP address.

[#7]

Can you clarify exactly how you have it configured? It sounds like you're trying to setup 2 SBCs on the same public IP address, but different ports. Is that correct? Do you have them setup behind a firewall and doing NAT to the SBCs? Is there any reason you cannot use different IP addresses? Are you the installer?

[#8]

This is our test environment. There is only one public IP address in this environment.
The question is very simple. Can I use one public IP for multiple SBCs?
I mean, each SBC has a unique FQDN, but that FQDNs is all resolved to the same public IP address.

[#9]

@DmitryZhukovVVTI've not seen anything in the documentation that explicitly states you can only have one SBC per IP address, however it's easy for something like that to not be documented.  While it might be an "easy question", other items factor into the answer, hence my additional questions.  For example, if you have both SBCs behind a firewall, using different ports (say 5061 for sbc1 and 5067 for sbc2), are you sure the firewall rules allow access to both? Have you verified you are seeing traffic to both SBCs on the firewall (i.e. hit counts on the firewall rules are increasing for both)?  Have you looked in the Teams Admin Center to see if any errors are listed?

[#10]

hello

[#11]

Sure.
At the moment we are using different ports for the two CBCs. Firewall rules allow traffic for these ports.
We see traffic on the first port and we don't see it on the second. It seems that Microsoft is not sending us anything.

In the Teams Admin Center, on the problematic SBC, I see "No SIP OPTIONS" and "Inactive. The trunk never connected".

But I don't understand why there is no traffic on this SBC. Therefore, I ask the question, maybe it is impossible in principle?

[#12]

@DmitryZhukovVVT 

Can you put pririoty 1 and 2 as on first SBC and 2nd SBC in Voice route and verify

[#13]

@LinusCansby's suggestion to check with the partner who deployed the SIP routers is a good idea. Also, ensuring each SBC has a public routable IP address could potentially resolve the problem.