Avaya SBCE to SM Failover

[dclark1111]

We have two Session Managers and 1 SBCE to one provider and 1 SBCE to another provider. Each SBC run EMS on the box. We have both SM's defined in Server Config, routing and in server flows. On a normal operating day, everything works just fine. When we busy out one SM for maintenance, the calls stop with a 503 (expected). But what wasn't expected the calls never went to the second priority listed in server flow, to our second SM. I can manually change Priority and make the non-maintenance mode SM higher (Priority 1) and the calls will work again.

I am looking for a way to have automatic fail-over. When the system sees a 503, it moves to the second option in the list. Is this possible? If so, where do I start to fix this issue.

 

[kyle555]

Yeah, I don't think a 500 level response causes the SBC to try the next choice. What if you were to mark the entity link out of service from SM1 to that SBC? Would SM respond to OPTIONS pings from the SBC? Is the SBC sending OPTIONS pings as heartbeats?

If SM1 died and the SBC couldn't get any answer from it, then it'd use the second choice in the routing profile.

Otherwise, you'd want to look into using FGDNs.

 

[dclark1111]

Thanks for the reply and help!

When the entity link is out of service, it responds 503 to the call.

It does respond to the options Pings as well. The SBC is sending OPTIONS pings as a heartbeat every 30 seconds.

I have read up on FGDN, but it appears it's load balancing is DNS, but no priority. I am trying to keep everything on 1 SM until it failed then move to the other. The only reason for this - we have some devices that only talk to 1 SM. Is my understanding of FGDN correct with the every other balancing method?

EDIT - Should have add this is the link I am using to learn about FGDN -

https://downloads.avaya.com/css/P8/documents/101051469

 

[kyle555]

Yeah, sorry. I'm not sure FGDNs would do it for you. It looks to be a way to keep mid-call signaling up if a SM happened to die that things like session refreshes can be handled by SM2 - I don't think it'll change the fact that as long as a SIP OPTIONS gets a response - any response - 200OK, 404, 500, etc, that the sender of the OPTIONS ping - the SBC in your case - will consider SM#1 as open for business and consider its 503 authoritative for the server pair and not try the next SM.

If you made sure to have a different SIP firewall profile for each SM and went to blacklist A1's IP 1.2.3.4/32 in SM1 that SM1 would no longer respond to options pings and force the SBC to consider SM2.

I'm actually designing a scenario like this where my routing profile in SBC2 has priority A1 of SBC1, SM1, SM2. We're using application rules to limit numbers of calls to certain numbers, but the carrier upon getting a 503 from SBC1 in data center 1 when >10 calls are up will send it on the second path for the SIP trunk to SBC2 in data center 2 where that SBC isn't aware of the current limits and lets it pass. So, if SBC2 gets a call AND SBC1 is up, then I know it's cause it busted the limit on SBC1, so I send it to SBC1 to send to SM with a domain substitution of overflow.customer.com to make CM play a "we're too busy" announcement, but if DC1 failed, then SBC2 would see A1 of SBC1 down and use the local SMs and process failover like normal.