System Manager Local Host Name Resolution.

[RedTech443]

I am trying to setup a System Manager with 2 SBC's, using Local hostname resolution.

When I Point My entity link in System Manager to Just one SBC using the IP address, everything works fine, calls go in and out no problems. But In this configuration I can only have it pointed to one SBC at a time, when I need to have it pointed to 2 SBC's for failover.

If I change the Entity link IP to the FQDN of the "local hostname resolution" that is using both SBC's IP address, it comes up and is connected, but I get Proxy authentication error in the trace logs, and neither SBC will take or send calls correctly.

I remember way back reading in earlier versions of System manager 6.3 there was a bug with Local host name resolution, but I cant find it again. I may need to patch but I am not sure if that is t he fix or not and trying to verify.

 

[kyle555]

You dont need to use FQDN - I mean, you can - but that's not LOCAL hostname resolution, it's domain level plain old DNS hostname resolution.

In SMGR-->SM-->Network Config-->LHNR you can add 2 lines for fakename.sbc1.local with different IPs, weights and priorities and make a SIP entity to fakename.sbc1.local and SM will follow the rules you made in LHNR and try reaching them only on the specific IP addresses you punch in.

To say, if sbc.avaya.com has DNS resolvable IP 1.1.1.1 and 2.2.2.2, they're respective SIP services might only be listening for stuff to 1.1.1.1 or 2.2.2.2 and not @sbc.avaya.com - just like how CM's sig groups listen on certain domains and not others.

So, if you had LHNR configured with fakename.com and pointing at 1.1.1.1 and 2.2.2.2, SM would reach out to those IPs and not fakename.com.

Make sense?

 

[RedTech443]

I think that is what what I did, I added an IP for each SBC with the same Hostname, one on each line.

fakename.sbc.com 1.1.1.1
fakename.sbc.com 2.2.2.2

Then in routing under entity, I made it point to fakename.sbc.com

after it syncs, I can see both Ip's as up 200 ok in Session Manager dashboard.
But I get proxy authentication required when making calls into the SBC.

 

[kyle555]

407 proxy auth required isn't uncommon. That means the thing you sent your invite to wants you to send it again with a hash of a password in something called a 'nonce'

So, when SM receives an invite, the first thing it does is look for a SIP entity and entity link on the IP/port pair it got the message on. If that exists, it routes the call. If no entity link exists, it presumes you're a set that should register to it and asks for proxy authentication.

In fact, even when a SIP phone is registered to SM, calls will always result in a 407 proxy auth required and the phone will invite a 2nd time, exactly the same, except with an extra line for authentication.

What it could be is that your SBC has public facing SIP trunks that require a username and password which you would configure in the SBC so it can register to the provider.

Hypothetically, another SM might be on the other side of that SBC and not have an entity link defined for however that traffic goes from your SM-->the SBC-->the other SM and 'the other SM' doesn't associate your message with any defined link/trunk, so it presumes you're a set that needs to authenticate with a set password.

Under what circumstances can you actually get a call through? That might help you figure out what the other end is expecting

 

[RedTech443]

So it works like this.

If I have only 1 IP in the System Manager SIP entity pointing to just one SBC (either SBC) everything works fine.
As soon as I change the IP to a fqdn that I have assigned in LHNR, fakename.sbc.com which points to both SBC's I get proxy authentication errors.

 

[kyle555]

what version of SM? 7.1.0ish has a bug where it DNS queries all Local hostnames which is pretty dumb if you're using only locally significant hostnames like datacenter1.sbc to have SM need to timeout and try to FQDN resolve those hostnames.

Are you on 7.1.0 and are your hostnames also resolvable by DNS? If so, maybe try not having DNS resolvable hostnames and if you otherwise don't need DNS in SM, turn it off in SMNetSetup. If you have the bug in question, you'd wait 10 seconds for DNS1 to timeout and another 10s if you have a DNS2 to timeout.