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
- Thread starter
- #81
I was on the public cell network originally.. When I go to whatsmyip from the device I get 24.44.234.199.. on the SBC trace the trace picks up that IP address (along the top where it shows the ladder/arrows for the msgs); However, in the invite when the call is made the C field becomes that of a 10.x.x.x address. Have to find out where that private IP actually came from, but nonetheless.
From my home WiFi same deal.. the public IP is picked up in the ladder, but the C field in the SDP body is 192.168.x.x.
From my home WiFi same deal.. the public IP is picked up in the ladder, but the C field in the SDP body is 192.168.x.x.
What's your phone Interworking profile in your endpoint/subscriber flow? Is that interworking profile picking up on Avaya-specific extensions? Does the application relay for PPM/HTTPS being proxied thru to SM and back to the remote worker operate?
NATs and SIP aren't exactly new. I could only believe the phone is stupid enough to offer a private IP because of a misconfiguration or lack of configuration of telling it where to route audio. Last time I had that problem, the phone was sending RTP to the private DMZ IP of the SBC and not the public IP because of that public IP override setting in the SBC.
Either some interworking profile isn't passing the phone the intelligence it's looking for, or it might not be getting PPM. Is it AST registered in SM? Is it the same deal from a Windows Equinox client? I know in the Windows ones there's a "send logs" that just attaches them in an email. iOS probably has something similar and I'd sniff through those. It's not terrible if you find the right log file. Something like "I really don't think I'm behind a NAT"
Wait...I'm thinking this through on the fly... Now, it is a fact the SBC needs the audio from the remote worker first to know how to get through your NAT. When I've looked at good calls, the audio sets up something like 1 RTP packet from client to SBC which the SBC hijacks to send audio back to the client and I guess thru an update message with SDP tells the client to send audio to the same IP
ort+1. I'm not entirely sure of the mechanics there, but that's the idea.
Now, I don't actually know for a fact if that private c= line is the culprit. For all I know, the SBC knows how to tell the phone to reach it, and it uses its brains to get back to it regardless of SDP content.
Can you traceSBC RTP to 192.x out B1 on the dead air call?
NATs and SIP aren't exactly new. I could only believe the phone is stupid enough to offer a private IP because of a misconfiguration or lack of configuration of telling it where to route audio. Last time I had that problem, the phone was sending RTP to the private DMZ IP of the SBC and not the public IP because of that public IP override setting in the SBC.
Either some interworking profile isn't passing the phone the intelligence it's looking for, or it might not be getting PPM. Is it AST registered in SM? Is it the same deal from a Windows Equinox client? I know in the Windows ones there's a "send logs" that just attaches them in an email. iOS probably has something similar and I'd sniff through those. It's not terrible if you find the right log file. Something like "I really don't think I'm behind a NAT"
Wait...I'm thinking this through on the fly... Now, it is a fact the SBC needs the audio from the remote worker first to know how to get through your NAT. When I've looked at good calls, the audio sets up something like 1 RTP packet from client to SBC which the SBC hijacks to send audio back to the client and I guess thru an update message with SDP tells the client to send audio to the same IP
ort+1. I'm not entirely sure of the mechanics there, but that's the idea.Now, I don't actually know for a fact if that private c= line is the culprit. For all I know, the SBC knows how to tell the phone to reach it, and it uses its brains to get back to it regardless of SDP content.
Can you traceSBC RTP to 192.x out B1 on the dead air call?
- Thread starter
- #83
- Thread starter
- #84
Ok, back in the fight. For redundancy purposes I have 2 Session Managers to utilize for this setup. The initial config I only have 1 defined in the SBC config. What's the right way to add in the additional SM? I've seen a few threads about the 2nd SM needing to be added as a separate and new policy. Will that 2nd SM require a 2nd SBC A interface?
I think you can add it as a second server profile and make the routing profile go "SM1 then SM2". Or, have a VFQDN like "mySMpair.me.com" DNS resolve to both and subjectAltname can include "sm1.me.com" and "mySMpair.me.com" for SM1 or DNS SRV
But you can most certainly have 1 interface outside point to 2 interfaces inside
But you can most certainly have 1 interface outside point to 2 interfaces inside
- Thread starter
- #86
- Server Config I had to add new, with the alternate SM.
- I had to create a new PPM mapping profile as well.
- For Routing I added to the existing with the 2nd SM.
- For the DMZ Relay/Reverse Proxy it only allows 1 server to be applied to the PPM mapping profile. If I add/clone and use the alternate server it only allows the listen port once. So not sure if an additional port needs to be opened, instead of just 443.
- endpoint flow looks to need a 2nd server flow added.
But the overall how it works isn't making sense by not being able to just add an additional server to the existing policies.
- I had to create a new PPM mapping profile as well.
- For Routing I added to the existing with the 2nd SM.
- For the DMZ Relay/Reverse Proxy it only allows 1 server to be applied to the PPM mapping profile. If I add/clone and use the alternate server it only allows the listen port once. So not sure if an additional port needs to be opened, instead of just 443.
- endpoint flow looks to need a 2nd server flow added.
But the overall how it works isn't making sense by not being able to just add an additional server to the existing policies.
If I'm not mistaken (and I haven't looked in a while), I think you just add another of everything and in the profiles there's a priority, so you choose which SM you'd like to go to first.
PPM may be a bit trickier because the SBC would need to know which SM you're on to proxy the PPM request to the appropriate server. I believe that's why there's a specific PPM service configuration in the SBC different from the plain old application relay (what version of SBC interop notes you're using referring to?)
Also, how many SMs in your environment total? There's not a 3rd, 4th, 5th that the users may home to normally from a SIP phone inside, correct? Because I believe user5-->SBC-->SM1 just like user5-->sm1 would get a 302 moved permanently and SM1 would tell a user not associated with SM1 to go register to the primary/2ndary SM in his profile. I'd suggest a remote worker flow to every SM in your environment with user profiles where you'd reasonably expect those users to try the SBC once in a while.
PPM may be a bit trickier because the SBC would need to know which SM you're on to proxy the PPM request to the appropriate server. I believe that's why there's a specific PPM service configuration in the SBC different from the plain old application relay (what version of SBC interop notes you're using referring to?)
Also, how many SMs in your environment total? There's not a 3rd, 4th, 5th that the users may home to normally from a SIP phone inside, correct? Because I believe user5-->SBC-->SM1 just like user5-->sm1 would get a 302 moved permanently and SM1 would tell a user not associated with SM1 to go register to the primary/2ndary SM in his profile. I'd suggest a remote worker flow to every SM in your environment with user profiles where you'd reasonably expect those users to try the SBC once in a while.
- Thread starter
- #88
I'm pretty sure I know what this issue is, but the documentation doesn't say the interfaces that require this. My failover between SBC's was taking 10 full minutes for a client to re-establish connection to the other and am pretty certain it's due to GARP being disabled on our switches. I have to validate with the server team, but I'm reading about the vswitch 'notify switches' setting. The Avaya doc doesn't state which of the interfaces require to be enabled for GARP.
- Thread starter
- #90
I wouldn't think so. Haven't looked at the install docs in a while, and it might be a crossover between both SBC VMs to keep sync, but even if that's the case, I'd expect them to have their own unique IPs to speak to one another and not need GARP.
Heck, the HA pair of SBC can be geo-redundant and not not tied to a crossover cable. If you feel like spanning your VLANs on the B1 and A1 side, 192.168.1.1 A1 can live on the first SBC at data center 1, and if it dies, the other in data center 2 assumes that IP. A crossover interface would obviously not be required.
I don't look forward to the day most networking goes that way. Heck, even CM 7.1 has geo-redundant duplex on the same basis. On a normal CM duplex it's 5x 100ms heartbeats missed that make the standby go active. I can't imagine what kind of tweaking and tuning they did to avoid going split brain all the time.
Heck, the HA pair of SBC can be geo-redundant and not not tied to a crossover cable. If you feel like spanning your VLANs on the B1 and A1 side, 192.168.1.1 A1 can live on the first SBC at data center 1, and if it dies, the other in data center 2 assumes that IP. A crossover interface would obviously not be required.
I don't look forward to the day most networking goes that way. Heck, even CM 7.1 has geo-redundant duplex on the same basis. On a normal CM duplex it's 5x 100ms heartbeats missed that make the standby go active. I can't imagine what kind of tweaking and tuning they did to avoid going split brain all the time.
- Thread starter
- #92
At the same time though when you talk to the server/vmware experts the lack of DR abilities for these vm's is frustrating. They don't like the idea of stretching layer2 across dc's and I guess until what you mentioned above there were no capabilities for the geo layer 3 stuff.
- Thread starter
- #93
In circling back to separating mutual vs server auth for ios vs deskphone the current TLS client profiles are set for peer verification, which is what I want. I created a new TLS server profile requiring peer verfication; However, the only place the TLS server profile is applied is to the signaling interface. Adding a new signaling interface and using the same port (5061) is not permitted. The endpoint flows only reference the tls client profiles, which are already set properly.
So, I believe the A1/B1 physical interfaces can have more than 1 IP assigned to them to have separate signaling interfaces and thus TLS profiles.
Yeah, I don't think you get that knob to tinker with at the User Agent level. I get that that's what you want to do, but the SBC probably doesn't see it that way. As in, the TLS profile decision is probably something very low-level.
I mean, think about it. It'd have to TLS handshake with the endpoint to know what client type it was to know what security profile to apply. That's putting the cart in front of the horse and asking the horse to divide by 0
Yeah, I don't think you get that knob to tinker with at the User Agent level. I get that that's what you want to do, but the SBC probably doesn't see it that way. As in, the TLS profile decision is probably something very low-level.
I mean, think about it. It'd have to TLS handshake with the endpoint to know what client type it was to know what security profile to apply. That's putting the cart in front of the horse and asking the horse to divide by 0
- Thread starter
- #95
I'm pretty sure, yeah. Remote worker stuff tends to go that way. 1 IP for the SIP trunks TCP, 1 for remote workers offering the domain cert, 1 for web conferencing offering a godaddy one for outsiders, etc.
I mean, SCEP the 9600s and MDM the mobiles and do mutual TLS for all of it.
I mean, it'd have to be a rather targeted attack for me to 1. take your SMGR root ca cert and trust it and 2. send a UA string of Avaya one-X Deskphone 7.....
But thinking about it more, if you want to go that way, I'd suggest you check your security rules one more time. Like, see if you can have iOS trust SMGR and point it at the IP for the no-peer-verification IP. Maybe that interface would need a UA match of *, to say anything not Avaya one-X Deskphone and send it to limbo in case anything else mistakenly registers there.
I mean, SCEP the 9600s and MDM the mobiles and do mutual TLS for all of it.
I mean, it'd have to be a rather targeted attack for me to 1. take your SMGR root ca cert and trust it and 2. send a UA string of Avaya one-X Deskphone 7.....
But thinking about it more, if you want to go that way, I'd suggest you check your security rules one more time. Like, see if you can have iOS trust SMGR and point it at the IP for the no-peer-verification IP. Maybe that interface would need a UA match of *, to say anything not Avaya one-X Deskphone and send it to limbo in case anything else mistakenly registers there.
- Thread starter
- #97
For the HA between SBC's I pointed our vmware folks to the GARP requirements and they're indicating there's no such setting in VMware. Other than that paragraph in the deployment guide there's not much in the way of VMware specific configuration. Is there something specific that can be set other than flushing the ARP cache via script? Find it hard to believe there's not something concrete as it's a supported deployment. Granted my test of failover was to reboot what was the primary server, which should have been a valid test. It took close to 10 minutes before a registered client was able to re-register when I thought this should have been seamless.
- Thread starter
- #99
When running a traceSBC and looking at the registration packet in the VIA and contact fields I see the extension I'm using on the client with an IP address appended that I have no clue what it is. The traceSBC, along the top shows my public IP of the client and the destination of the external B1 interface, but within that packet there's a 10.x.x.x address that even my network team doesn't know what it is. Is that something the app uses to keep track of the session or something?
Do you get that from home wifi too? That sounds like maybe a cell carrier not having a IPV4 IP for everyone and NATing you behind IPV6 to the public web and NATing back to IPV4 to hit your SBC
As far as I know, the client should be smart enough to discover it's public IP/know if its behind a NAT or not and pass things like record-route headers appropriately. Record-route means "hop back through me even if you could go direct" for things like call accounting and CDR or whenever a server in the overall flow could be circumvented but doesn't want to be for good reasons. Obviously your client sending "contact: 192.168.1.123" is ridiculous.
Suppose you have that cell hotspot a Windows PC to it and start tracerouting, maybe you'll find out that mobile internet doesn't include your own public IP.
Just a thought. I have no idea where else it'd be making that up. It had to come from somewhere.
As far as I know, the client should be smart enough to discover it's public IP/know if its behind a NAT or not and pass things like record-route headers appropriately. Record-route means "hop back through me even if you could go direct" for things like call accounting and CDR or whenever a server in the overall flow could be circumvented but doesn't want to be for good reasons. Obviously your client sending "contact: 192.168.1.123" is ridiculous.
Suppose you have that cell hotspot a Windows PC to it and start tracerouting, maybe you'll find out that mobile internet doesn't include your own public IP.
Just a thought. I have no idea where else it'd be making that up. It had to come from somewhere.
- Status
Similar threads
