I have stood up a new smgr/sm 7.1. Before moving on to the SBC I just wanted to test the equinox mobile app directly to SM to make sure it works. At just a basic level I just need to create a new SIP user. I exported the identity and trust certs from SM and SMGR and I keep getting cert errors. Would those not work by manually installing them on the mobile device?
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 TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Equinox 4
- Thread starter wpetilli
- Start date
Nonono, mutual TLS means the client needs a pkcs12 with private key to offer SM and that SM trust that authority. You haven't done that (yet?)
SIP level failures mean some signaling problem. SDP, SIPS enforced in the route pattern, encryption settings in the codecs, something is failing you out.
Do Avaya sip handle xxxx and e164 handle +xxxx exist in the profile? Is your numbering format absolutely private on the trunk delivering the call from cm to sm? calltype aar no longer denotes private numbering, that's a long story though. Your problem is most certainly in administration somewhere.
SIP level failures mean some signaling problem. SDP, SIPS enforced in the route pattern, encryption settings in the codecs, something is failing you out.
Do Avaya sip handle xxxx and e164 handle +xxxx exist in the profile? Is your numbering format absolutely private on the trunk delivering the call from cm to sm? calltype aar no longer denotes private numbering, that's a long story though. Your problem is most certainly in administration somewhere.
- Thread starter
- #42
Right now on the clients are our company root / subca certs that are pushed via MDM policy. The SM has a replaced identity cert that has all the sm100 names in the SAN. Both on Sip security module and http. our root and subca certs are installed in the trust store of the SM. Those same root / subca certs are installed in the trust store of SMGR. If I change TLS Endpoint Cert Validation to none I get past those fatal cert errors and can register with the limited voip service error. A call is able to be made now, but that error is there.
my RP is pretty standard..
TG 5
FRL 0
all other settings are default except I'm using lev0-pvt as per the documentation.
The codec set is set
1.g.722-64K
2.g.711mu
3.g.726a-32k
4.g.729
5.g.729b
1-srtp-aescm128-hmac80
2-srtp-aescm128-hmac32
none
my RP is pretty standard..
TG 5
FRL 0
all other settings are default except I'm using lev0-pvt as per the documentation.
The codec set is set
1.g.722-64K
2.g.711mu
3.g.726a-32k
4.g.729
5.g.729b
1-srtp-aescm128-hmac80
2-srtp-aescm128-hmac32
none
try a new NR and codec set for the SIP phone and sig group to SM with just 711/no encryption.
If it wants a DSP first and you don't have DSPs that can process 726 or 722 for example, that might be the cause of a termination error.
Does CM try to deliver to SM to the phone when the phone is called, or is CM giving the termination error message? Maybe a denial event logged against the calling or called station might give some "bearer capability" problem?
If it wants a DSP first and you don't have DSPs that can process 726 or 722 for example, that might be the cause of a termination error.
Does CM try to deliver to SM to the phone when the phone is called, or is CM giving the termination error message? Maybe a denial event logged against the calling or called station might give some "bearer capability" problem?
- Thread starter
- #44
Did the new NR/codec set and I ran traces on the tac of the sip tg on CM as well as on the station, along side the traceSM. I see all clean 200's all the way and I'm able to make calls, but I still have the red error about voip service limited. I'm calling 4 digit between CM's across totally different SM's and am making outbound pstn calls via the cm pri, no issue. Just have that red error and it's not saying what it is.
- Thread starter
- #45
I installed the windows client on my office pc and it prompted me for a certificate. I installed the SM identity cert and it logged in straight away. Our root and subca's are already part of the windows build. I then went back to the 46xx file autoconfig method for my ios device and installed the identity cert and put the root and subca in as well, even though those are already in the device trust store. The error cleared. So, not sure if it needed a cert in the private store and which of those it needed. Theoretically, the root and subca in the device trust store should have been all it needed. Unless there's some other setting the device is getting from the 46xx file that it likes that it can't get from the manual config method I've been doing. Still need to sort that before a prod rollout. The A/D team isn't going to love it the way it is, but I can at least move up to the SBC level testing.
- Thread starter
- #46
Moving along.. when I attempt to come in from externally now from the SBC I see my device and the SBC going through all the client/server hello exchanges with no errors and immediately get a 503 service unavailable from the SBC back to my device. Of course no information in the message.
- Thread starter
- #47
When I run a pcap from the web interface on B1 and A1 separately, I get no traffic on A1 at all. I see the traffic from the endpoint hitting the B1 interface, but it's dying in the SBC somewhere. We also see nothing on the SM trace. Is there any sort of static route that needs to be put in for the A1 and B1 subnets to be able to talk?
No...do you have Incidents in your SBC of something not matching a flow?
That's basically what you get if you haven't configured the SBC correctly. And it's odd to get your head around received inteface/signlaing interface and all that stuff. It's not intuitive.
Either that, or options pings from SM to SBC or vice versa fail and they don't see each other in service despite a correct configuration. But that's unlikely. Any SIP level response is fine - forbidden, not found, wtv - if they send a sip message to one another and get any type of reply, it considers the SIP ping successful and keeps the link up.
That's basically what you get if you haven't configured the SBC correctly. And it's odd to get your head around received inteface/signlaing interface and all that stuff. It's not intuitive.
Either that, or options pings from SM to SBC or vice versa fail and they don't see each other in service despite a correct configuration. But that's unlikely. Any SIP level response is fine - forbidden, not found, wtv - if they send a sip message to one another and get any type of reply, it considers the SIP ping successful and keeps the link up.
- Thread starter
- #49
No, no incidents. When I run the diagnostics from the server the ping tests fail from A1 to my dns server, to the d g/w of the A1 subnet, but not sure if ping is a requirement for those. Same with B1. Since these servers are in the dmz the security team typically blocks ping unless it's necessary for a function. Things like the ports for dns are open, but not ping. They're going to allow ping just to see if is the issue, but they don't believe so.
- Thread starter
- #50
- Thread starter
- #52
I've gone line by line of the doc and a stare and compare to a previously working lab POC and things from a config standpoint look spot on. What I am seeing and not sure if it's the culprit, or how to determine from what interface it is.. on the SBC 'Status/Server Status' I have 2 entries for the SM (sm100 address) to TCP/5060 and TLS/5061. The TCP status is up and TLS is down. There is a permit any from A1 to the entire trust, so it doesn't look f/w related.
check the SM firewall settings/traceSM if its dropping SBC traffic. it might have some stupid rule of max X things from an IP which need the SBC's A1 whitelisted if it'll be passing traffic for everyone outside to SM by it.
Or, TLS handshake failures between A1 and SM100. I said the SBC sucks with external certs and I wasn't kidding. Do something like putting the standby out of service, tshark -i A1 -host SM100IP -w /tmp/tlstest.pcap and restart the primary SBC and see what happens.
If you're configured right for the SBC to pass to SM, and it TLS handshake fails in setting up its initial connection, you'll never see anything pass to SM, nor will you see any given registration proxy thru the SBC to SM - the SBC needs to SIP OPTIONS ping the SM, obviously with a happy TLS handshake before passing a register along. I'd almost call it normal that you wouldn't attempt a TLS handshake to SM to pass a register along if the SIP link to SM hadn't been established beforehand.
Or, TLS handshake failures between A1 and SM100. I said the SBC sucks with external certs and I wasn't kidding. Do something like putting the standby out of service, tshark -i A1 -host SM100IP -w /tmp/tlstest.pcap and restart the primary SBC and see what happens.
If you're configured right for the SBC to pass to SM, and it TLS handshake fails in setting up its initial connection, you'll never see anything pass to SM, nor will you see any given registration proxy thru the SBC to SM - the SBC needs to SIP OPTIONS ping the SM, obviously with a happy TLS handshake before passing a register along. I'd almost call it normal that you wouldn't attempt a TLS handshake to SM to pass a register along if the SIP link to SM hadn't been established beforehand.
- Thread starter
- #54
Yea, I had already whitelisted everything possible in SM.
I do see the heartbeat OPTION traffic in the traceSM to the SBC. From the SBC 'server config/heartbeat' sbc@A1 IP to sm@sm100 IP. But that's all on 5060. Client connections never hit SM.
For the cert stuff I seem to get a clear connection into B1. Does the SBC need something for SM or just need to be part of the same root chain?
I do see the heartbeat OPTION traffic in the traceSM to the SBC. From the SBC 'server config/heartbeat' sbc@A1 IP to sm@sm100 IP. But that's all on 5060. Client connections never hit SM.
For the cert stuff I seem to get a clear connection into B1. Does the SBC need something for SM or just need to be part of the same root chain?
there's a tls profile per server connection I think.
To say, the SBC can chain up to different root CAs on B1 and A1. If your endpoint flows map the remote workers to TLS on the SM and that cert handling between A1 and SM isn't happy, you can TCP SIP ping 5060 all day between A1 and SM and still never have a remote worker login.
Maybe you can map the A1-->SM part for remote workers to use TCP explicitly as a test, but you won't get presence or other UC functions from SM that way.
To say, the SBC can chain up to different root CAs on B1 and A1. If your endpoint flows map the remote workers to TLS on the SM and that cert handling between A1 and SM isn't happy, you can TCP SIP ping 5060 all day between A1 and SM and still never have a remote worker login.
Maybe you can map the A1-->SM part for remote workers to use TCP explicitly as a test, but you won't get presence or other UC functions from SM that way.
- Thread starter
- #56
- Thread starter
- #57
Hmm. Ok. If you did traceSM/traceSBC and captured that and wrote your packets to a pcap, that'd be normal. Yes it's a capture, of TLS, but those applications log the packets above the TCP/IP layer. If you that on a tshark right on the wire, I'd be curious to see what you mean by the "packets are able to be read". I mean, there's something readable in there, but it shouldn't be SIP signaling or anything relative to your remote worker flow.
So, either you goofed and told the SBC to relay unencrypted stuff on 5061 - just telling it to use 5061 doesn't explicitly pop a TLS profile in there - or, you're somewhere in limbo with how it handles certs. It shouldn't be hard on the inside - the SBC just needs to trust what SM offers, that's an easier thing to do on it than configure a cert for it to offer endpoints, but still. Try default certs on the inside part? I mean, not trying to start a handshake is weird. I've complained probably a few times in this thread and in others about how bad the SBC is at administering certs on - where it won't do what you tell it and won't let you know. Do you think you've hit that part?
I can give ya some oneliners to import certs via CLI, but its tedious, needs to be done on each SBC and is basically you throwing in the towel on the admin interface. Patch to latest? Open a ticket at Avaya if you've got the support?
So, either you goofed and told the SBC to relay unencrypted stuff on 5061 - just telling it to use 5061 doesn't explicitly pop a TLS profile in there - or, you're somewhere in limbo with how it handles certs. It shouldn't be hard on the inside - the SBC just needs to trust what SM offers, that's an easier thing to do on it than configure a cert for it to offer endpoints, but still. Try default certs on the inside part? I mean, not trying to start a handshake is weird. I've complained probably a few times in this thread and in others about how bad the SBC is at administering certs on - where it won't do what you tell it and won't let you know. Do you think you've hit that part?
I can give ya some oneliners to import certs via CLI, but its tedious, needs to be done on each SBC and is basically you throwing in the towel on the admin interface. Patch to latest? Open a ticket at Avaya if you've got the support?
- Thread starter
- #59
- Status
Similar threads
