Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

IX Workplace remote worker failover from ipo primary to secondary 3

Status
Not open for further replies.

UCMen33260

Technical User
Feb 17, 2020
53
FR
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
 
I found that on IX logs:

2020-02-21 23:43:27,141 DEBUG [CSDKEventLoop] - [ClientSDK] > CSIPIdentity[102]:: Discovered Proxy Set
SignalingServerGroup {

RegistrationGroup {

SimultaneousRegistrationsLimit = 1

SignalingServer {
ServerName = ipo-a-01.mydomain.com
FailbackPolicy = auto
Addrs = {
}
TransportToPortMap {
TLS :5061
}
PreloadedRoutes = {
}
IsPermanentMemberOfRegistrationGroup = false
}
}


RegistrationGroup {

SimultaneousRegistrationsLimit = 1

SignalingServer {
ServerName = tcp://ipo-a-02.mydomain.com:5060
FailbackPolicy = auto
Addrs = {
}
TransportToPortMap {
TCP : 5060
}
PreloadedRoutes = {
}
IsPermanentMemberOfRegistrationGroup = false
}
}

}
 
I tried that:

I cleared IX config and registering again using the IPO secondary 46xxsettings file.
So, IX is registered on IPO secondary.
I disconencted the IPO secondary and waiting 10 min.
I donwloaded the IX logs file and surprise ! logs shows same issue, in this case inverted so:


SET SIP_CONTROLLER_LIST "ipo-a-02.mydomain.fr:5061;transport=tls,ipo-a-01.mydomain.fr:5060;transport=tcp" :)

Result of troubleshooting:

Always the fallback system SIP controller is on TCP 5060...

I will do a deepdive on IPO linux files...

Regards
 
Hi,

I found a solution and now IX resiliency is working fine between IPO primary and secondary !

regards
 
Yes of course !

My issue was on SIP Servers on SBCE:

I used TCP, so when IX connect on the IPO primary, I see on the (200 OK):

<ipo>
backup_ipoffice_server="ipo-a-02.mydomain:5060;transport=tcp";
FAILBACK_POLICY="auto";
</ipo>

I changed the protocol on both SIP Server to TLS and the backup_ipoffice_server is on TLS 5061 now!

Another important thing, I must change TLS from 1.2 to 1.0 in IPO security settings.
Without this change, System status shows an error: unsupported protocol version.

I'm working on that, I'll upgrade IPO on SP2

Another thing, When I select a TLS Client Profile on SIP Server, IX don't connect and SBCE shows errors on (Incidents tab):

Incident Type TLS Handshake Failed Category TLS Certificate
Timestamp February 24, 2020 12:30:33 PM CET Device SBC-CLUSTER
Cause error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Incident Type TLS Handshake Failed Category TLS Certificate
Timestamp February 24, 2020 12:30:33 PM CET Device SBC-CLUSTER
Cause unable to get issuer certificate


I'm working on that now !

regards
 
Strange, because I use the same certificate on SBCE and IPO.
I use a Let's Encrypt SSL Certificate.

 
Here is client/server profiles:

SNAG-0003_24-02-2020_15.20.43_pjb7et.png


SNAG-0002_24-02-2020_15.20.20_ritgdi.png


Does I need to install the CA on the EMS ?
 
No, I have the Let's Encrypt CA, (IPO_A_ROOT_V1 is only the name used).

The issue is that when I requested the SSL certificate on Lets Encrypt website, I received a CA Bundle that contain the CA and the intermediate CA.
The SBCE don't support that maybe...
 
The bundle contains the server certificate AND the root certificates. You have to extract it or download the needed root certificates from let's encrypt.

And you have to adress IPO via FQDN instead of IP address I guess. Because the let's encrypt certificate will probably not contain the internal IP of IPO in it's SANs.

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN
 
No, Let's Encrypt bundle contain CA only: here is an example from Lets Encrypt website

SNAG-0004_24-02-2020_16.56.53_bcrk5w.png


And certificate is provided separatly:

SNAG-0005_24-02-2020_16.56.58_bi5l2w.png
 
The certificate issue appear only when I select a TLS Client profile on SIPServer:

SNAG-0006_24-02-2020_18.32.04_kjx1us.png


This feature seems to be not mondatory.
 
Public certification authority don't provide certificates with IP addresses on the SAN.
 
TLS Client Profile must be NONE on my configuration, because my SIP Servers are (Call Server type) and DNS Query type is forced on NONE/A when you select Call Server

Information from Avaya SBCE documentation :

SNAG-0017_25-02-2020_10.37.10_ws2gjz.png


But I confirm that Ihave an issue on my certificate and TLS profiles configuration.

To use FQDN in my SIP Servers, I should have a DNS resolution internally, but the problem in SBCE, that I cannot select a DNS server for each interface (B1, B2, A1).

And in my case, I need DNS resolution on B1 interface, because B1 is used for SIP Trunk, and Trunk Server use SRV like DNS Query type to resolve the Registrar SIP.

I'm looking for a solution on that DNS problem.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top