IX Workplace remote worker failover from ipo primary to secondary 3

[UCMen33260]

Hi team,

I'm a new member on TEK-TIPS looking to share my skills, to help members and to be helped too

I deployed a primary and a secondary IPO and an SBCE for remote workers.
When the primary IPO fails, IX Workplace is unable to register on IPO secondary.
Someone has tested this and have a solution?
Thank you

Best regards

 

[derfloh]

They must have the same SIP domain configured and different FQDNs.

It should be reflected in 46xxsettings.txt

With all DNS and certificates in place it shouldn't be a big issue.

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[UCMen33260]

I confirm that all those prerequisites are already configured (unique SIP Domain, FQDN's, certificates).

 

[derfloh]

You need traces to see what happens.

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[UCMen33260]

I maked trace,

When IPO primary is down, IX Workplace (remore worker) continue sending REGISTER/OPTIONS to the IPO primary and never sends REGISTER/OPTIONS to the secondary.

My config:

IPO primary: 10.200.26.1 (FQDN: ipo-a-01.mydomain.com)
IPO secondary: 10.200.26.2 (FQDN: ipo-a-02.mydomain.com)
SIP domain: mydomain.com

Regards

 

[derfloh]

Did you configure secondary server with lower priority in the server profile?

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[UCMen33260]

I thiunk that the issue is here:
I have priority configured like that:

Primary: 1
Secondary: 2

Test maked: Connection with a remote worker user on IPO primary and I disconnect the network card of the IPO primary on VMware.

The trace SBC shows that IPO primary is not responding to the query but SBC continue sending REGISTER to IPO primary.

So I changed the priority to:

Primary: 1
Secondary: 1

and my IX workplace connect on IPO secondary, I can make calls but presence is not available.

The problem is, when I reconnect again IPO primary, my remote worker continue requesting the IPO secondary and still connected on the secondary so.



Regards

 

[derfloh]

Did you configure heartbeat to IPO?

Best would be if the secondary FQDN points to another IP of the SBC.

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[UCMen33260]

I don't no how to do that.
I use SBCE like reverse proxy for remote workers only.

My SBCE signaling interface (Internal) is A1: 10.200.26.20

Regards

 

[derfloh]

How many public IP addresses are available? Is there another free one that can be used?

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[UCMen33260]

Yes, I have another public IP address to use.

Regards

 

[derfloh]

Then set up another IP on the public interface (B1). Point the secondary FQDN to the second public IP and forward ports to second B1 IP address. Create the needed signaling and media interfaces and subscriber and end point flow.

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[sizbut]

Hate to ask the obvious, but has it been tested first with the IX Workplace internal rather than remote, ie. without the potential SBC/external DNS issues.

Stuck in a never ending cycle of file copying.

 

[UCMen33260]

Internaly, resiliency works fine, I already tested that.
But externaly is more complicated !

I maked the configuration requested by (derfloh).
But I use a unique SIP Server on SBCE (R8.1) (Server configuration on SBCE 7)

And my routing rule is based on Priority:

Do I need to use two SIP Server and two Routing rules with different priority in each one?

Thank you

Regards

 

[UCMen33260]

My network configuration used:

Maybe, I need to use that:

Regards

 

[derfloh]

That's how I meant it (the second pic)

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[UCMen33260]

Do I need 2 Proxy Relay too?

Does Hearbeat is mondatory?

Here is my SBCE configuration step by step:

1) Network settings:

2) Signaling interfaces

3) Media interfaces

4) SIP Servers (server configuration on SBCE 7)

5) Routing

6) Subscriber Flows

7) Server Flows

8) Reverse Proxy

With this configuration, SBCE continue sending requests to IPO PRIMARY (when IPO PRIMARY is down)

Regards

 

[UCMen33260]

I think that remote worker resiliency is not supported on IP office/SBCE...
First, we can't configure heartbeat on SBCE, because we don't use a SIP Line between IPO and SBCE for remote worker.
Second, SBCE don't send REGISTER to IPO secondary if IPO primary is down despite the priority is configured on the routing profile.

Also, IX Workplace is different from OneX, son resiliency documents provided by Avaya are not valid in this case.

Any ideas?

Regards

 

[derfloh]

Heartbeat should be possible though because it is just a "SIP Server". You should also be able to see the IPOs in the "Status"-"Server Status" menu. Even if it shouldn't be necessary. Does the Client contact the secondary "Signalling Interface" or just the primary? You can see the involved IP addresses if you step to the REGISTER message in TraceSBC and hit Enter.

I guess IPO is down but the client doesn't check that too fast because it is registered with SBC. And SBC isn't down. If you re-register the registration to first IPO should fail and IX should register to the second FQDN.

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[UCMen33260]

I configured heartbeat for both IPO PRI and SEC on my call server used for SIP Line (Trunk SIP):

On IPO PRI, I have a SIP Line (10.200.26.10:UDP/5060) and on IPO SEC, I have a SIP Line (10.200.26.11:UDP/5060).
For this, heartbeat is working:

But when I configure heartbeat for Call servers used for remote worker, SBCE response (503 Service Unavailable). I disable heartbeat and IX connect again immediatly.

I tried also to re-register IX on IPO PRI, same issue...

Regards