Equinox bad domain 3

[Manie3]

.

ACSS

Just another day in the life of ME

 

[Manie3]

Hi All

Sorry for the double message posting on mobile and tt is flakey when submitting

Upgraded a server edition select from 10.1 to 11 sp 2. To get them using equinox. Set everything up as per normal.

Upgraded system
Allowed correct ports on app relay on sbc
Set domain from talk.company.group to company.group
Kept fqdn as talk.company.group
Changed dns setting to look at private dns server
Added a forward zone on the dns for group.company
Added a host of talk.company.group pointing to internal ip of system
.pfx ssl cert added on 7070
Webroot.ca added on file management

Been testing using webclient and internally i can get to

https://ipadd:9443/webclient

Externally cant get to it using

https://talk.company.group:9443/webclient

get an error of didnt resolve

Equinox mobile app using web address of

https://talk.company.group/46xxsetting.txt

i can get to enter ext and password enter both of these and go through on the app but get the red triangle stating bad domain.

Checked the 46xx settings and the domain looks fine

Have done about 20 odd systems recently and they have all flown in nicely but the difference is this company using their own ssl cert rather than our normal *company.co.uk

Any ideas of what to try next ???


ACSS

Just another day in the life of ME

 

[kyle555]

A couple of things I've noticed:

IPO won't deliver webpages on a FQDN if it can't resolve the FQDN itself.

So, my.ipo.net is in DNS pointing to IPO on 1.2.3.4, but if that IPO can't resolve my.ipo.net, then your browser can get

http://1.2.3.4/46xxsettings.txt

but not

http://my.ipo.net/46xxsettings.txt

Also, don't know when it showed up in IPO as I don't deal with it much, but in the VOIP tab in LAN 1, you have your SIP domain and SIP Registrar FQDN.
I guess in your case that'd be company.group and talk.company.group respectively.
When you have that SIP Registrar FQDN in there, your autogenerated 46xxsettings does a SET SIP_CONTROLLER_LIST talk.company.group:5061 rather than SET SIP_CONTROLLER_LIST 1.2.3.4:5061.
It's important because for mobile apps to trust the certificate presented to them, it needs to do more than just be trusted by the device. If you're connecting to server talk.company.group, then that server needs to provide a certificate issued to talk.company.group. You can accomplish the same stuff with IP addresses for your registrar and by having an IP address in a subjectAlternativeName in a certificate, but the internet likes FQDNs in there.

 

[Manie3]

Cheers for the uodate @kyle555 the thing is thougb the fqdn works fine i can get to

https://talk.company.group/46xxsettings.txt

fine in web browser and the sip controller settings show the correct fqdn. I think it may be down to the .pfx i uploaded.

I was playing about with this earlier today and teied setting the domain same as the fqdn and the app came up all green for about 5 minutes then suddenly flagged bad domain again.

I think ill change the domain and fqdn tomorrow to our usual company.cloud.co.uk.

Unless you can think of anything else ?

ACSS

Just another day in the life of ME

 

[jamie77]

What kind of certificate have you got installed? I recommend a UCC cert with SANs for your FQDN and your domain. Secure SIP requires this anyway (J100's for example)

Get your FQDN and Domain set properly against the correct LAN interface.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[kyle555]

I mean, there isn't much to it - SET SIP_DOMAIN company.com. If you get that in your settings file, you'll register extn@company.com. The call server won't honor your login attemptif the SIP domain isn't right in the first place. I don't know why Equinox would give such an error - but there is a SIP error code I recall seeing in Session Manager at least of "invalid domain" or something to that effect.

If you can get it to work on mobile, try on Windows. Maybe try adding the FQDN/IP in your Windows hosts file. You'd want to look at a SIP trace.

I can't imagine it being your PFX. If you got in TLS the first time, then it stands to reason it's good enough for a re-register.

 

[Manie3]

This issue was resolved by setting them up with our own ssl cert and changing their domain and fqdn to our usual.

Thank you

ACSS

Just another day in the life of ME

 

[TheSmash]

Have some PINK for posting your awesome solution ;-)

ACSS (SME)