I have a handful of SIP endpoints (J169) deployed using dual registration and they are randomly popping up with a message that another user has logged in with this extension. It forces the phone to have to be re-logged in. I am testing this with an extension that I just created and it happened to me after 30-40 mins. What can be the issue with this? It's an SBC H/A deployment.
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 Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Remote SIP Extensions Logging Off
- Thread starter trilogy8
- Start date
- Thread starter
- #2
- Thread starter
- #3
This looks to be potentially fixed. The readme notes of the J169 v.4 SIP phones state you have to use an IP address and not FQDN of the SIP controller. I modified my 46xx settings to the public IP of the B interface of the SBC and the endpoint remained stable the entire night. I find this a bit disturbing as SIP is supposed to be based on DNS and FQDN's.. no?
No. SIP allows use of FQDN's and DNS to find out IP addresses to send or forward to but ultimately it gets down to what the IP address actually is. Endpoint realms aren't normally established using domain names but the other way around using the ip addresses.
Think of it this way. SIP is very routing dependent. Routers and switches make their path decisions upon asic's (port controllers) that are tied MAC to IP in the MAC address table. There's no domain information in that table. Domain information can be looked up to various extents but the IP is ultimately what ties a message to where it needs to route to.
Think of it this way. SIP is very routing dependent. Routers and switches make their path decisions upon asic's (port controllers) that are tied MAC to IP in the MAC address table. There's no domain information in that table. Domain information can be looked up to various extents but the IP is ultimately what ties a message to where it needs to route to.
- Thread starter
- #5
The endpoint will always send periodic - 1/hour-ish REGISTERs to each item in the list.
For that reason, you MUST prefer that the endpoint learn about all possible SIP controllers via PPM.
The phone will always attempt to register to the entries in PPM and those in the SIP controller list.
For example, you have a multi site setup, you go to another office, you login to a phone, that phone has a SIP controller list with primary, secondary, BSM.
The BSM is for the specific office. It's not your home office, so the BSM doesn't know about you.
If the BSM is in the SIP controller list, the endpoint will try to register once per hour and get a 404 and get logged out.
That's from personal experience. For your case, I'd assume that because you can't have unlimited entries in the controller list that the endpoint would consider each entry as a different SM and thus a different registration. SM would not see that as an endpoint simultaneously registering to 2 servers - certainly if the second register from the phone appears like a new phone trying to register for the first time.]
Clear the phone and have it boot with 1 entry in the settings file and report back.
For that reason, you MUST prefer that the endpoint learn about all possible SIP controllers via PPM.
The phone will always attempt to register to the entries in PPM and those in the SIP controller list.
For example, you have a multi site setup, you go to another office, you login to a phone, that phone has a SIP controller list with primary, secondary, BSM.
The BSM is for the specific office. It's not your home office, so the BSM doesn't know about you.
If the BSM is in the SIP controller list, the endpoint will try to register once per hour and get a 404 and get logged out.
That's from personal experience. For your case, I'd assume that because you can't have unlimited entries in the controller list that the endpoint would consider each entry as a different SM and thus a different registration. SM would not see that as an endpoint simultaneously registering to 2 servers - certainly if the second register from the phone appears like a new phone trying to register for the first time.]
Clear the phone and have it boot with 1 entry in the settings file and report back.
- Thread starter
- #7
I'll have a play with your suggestion tomorrow. We only use SIP endpoints remotely, so in our settings file, the SIP controller list is an FQDN that points to public IP's of our SBC's. Not to ASM. We use Ultra DNS to point to one SBC specifically. When I go into the endpoint settings under 'SIP proxy settings' I see it resolves to both public IP's of the SBC. If I were to change the settings file from FQDN, I'd then have to have 2 lines that have the public IP addresses listed. For my test, I'd want the endpoint to prefer the first IP in that list over the other. Not sure if that's a possibility.
So, my 2 phones stayed logged in overnight on the same extension. I'd set SIP CONTROLLER LIST to FQDNs and used the same FQDNs in the PPM Mapping Profile
I did read that part in the release notes (i'm on 4.0.6) that SM only supports via IP.
I have a HA pair for SM1 in data center 1 and another pair for SM2 in DC2.
When I restart the app on the primary SBC on DC1, the 2 phones both login again twice and have a little service interruption. They both seem to do that every few minutes thereafter, but they don't log out.
When I do SIP CONTROLLER LIST and PPM Mapping with the public IP, restarting the application on the SBC for SM1 has both phones smoothly transition seemlessly - although I got a limited service triangle for half a second and question mark for presence for another half a second on one of the phones but not the other. They did not logout, flip over, or go to SM2 as active controller, they worked just fine.
So yeah, use IPs.
I did read that part in the release notes (i'm on 4.0.6) that SM only supports via IP.
I have a HA pair for SM1 in data center 1 and another pair for SM2 in DC2.
When I restart the app on the primary SBC on DC1, the 2 phones both login again twice and have a little service interruption. They both seem to do that every few minutes thereafter, but they don't log out.
When I do SIP CONTROLLER LIST and PPM Mapping with the public IP, restarting the application on the SBC for SM1 has both phones smoothly transition seemlessly - although I got a limited service triangle for half a second and question mark for presence for another half a second on one of the phones but not the other. They did not logout, flip over, or go to SM2 as active controller, they worked just fine.
So yeah, use IPs.
- Thread starter
- #9
Hi Kyle, coming back to this because I'm a bit confused on what's happening behind the covers. If I change my controller list in the 46xx file from a single entry DNS name that has 2 public IP's of my 2 standalone SBC's behind it and in DNS it is setup to point to SBC-A as the primary, what is going to be the behavior if I then have to put 2 separate entries for each of the SBC public IP's, instead of the names Does the phone pick the first entry in the list or is it going to use round robin or both? Right now, when I go into the phone menu I see that DNS resolved and shows both SBC IP's in the list.
- Thread starter
- #11
SET SIP_CONTROLLER_LIST europe.home-remote.acne.com:5061;transport=5061 --- this is current (behind that DNS name are 2 different public IP's of 2 separate SBC's)
-- DNS is setup to route to the first IP in the list, which is SBC1
-- In the phone menu, under the SIP section I see the DNS name and both IP's resolved
If I have to move away from the DNS name to IP:
SET SIP_CONTROLLER_LIST 66.66.66.66:5061;transport=5061
SET SIP_CONTROLLER-LIST 77.77.77.77:5061;transport=5061
-- What is going to be the difference in behavior?
-- DNS is setup to route to the first IP in the list, which is SBC1
-- In the phone menu, under the SIP section I see the DNS name and both IP's resolved
If I have to move away from the DNS name to IP:
SET SIP_CONTROLLER_LIST 66.66.66.66:5061;transport=5061
SET SIP_CONTROLLER-LIST 77.77.77.77:5061;transport=5061
-- What is going to be the difference in behavior?
Yeah, don't do that. The phone will consider europe.home.whatever as a single SM.
SET SIP_CONTROLLER_LIST europe.home-remote.acne.com:5061;transport=5061
why not
SET SIP_CONTROLLER_LIST 66.66.66.66:5061;transport=5061,77.77.77.77:5061;transport=5061
or
SET SIP_CONTROLLER_LIST publicFQDNofSBC1:5061;transport=5061,publicFQDNofSBC2:5061;transport=5061
Unless ENABLE_PPM_SOURCED_SIPPROXYSRVR is 0, the phone will use the IPs from PPM for registration BUT it will always also periodically register to what's in SIP_CONTROLLER_LIST.
So, for example, if you had core SM1 and 2 and many sites BSMs. And say 46xx for BSM Site 1 said:
SET SIP_CONTROLLER_LIST coreSM1:5061;transport=5061,coreSM2:5061;transport=5061,BSM1:5061;transport=5061
And suppose a user from site 2 showed up and logged in to their extension.
Even though the user from site 2 has a profile in SM for "primary coreSM1, 2ndary CoreSM2, survivable BSM2" and even though the phone will be simultaneously registered to those 3 SMs, you'll notice about after an hour that the phone will logout because it sent a register to BSM1 per the SIP controller list and got a 404 and a phone drops credentials on a 404 cause either the PW is wrong or it's registering to the wrong server.
So, in your case, what I'd think is happening is that the phone is registering to the 2nd IP in that singular FQDN, but because the phone believes it's the first SM, that's what's triggering SM to think that another phone logged in.
SET SIP_CONTROLLER_LIST europe.home-remote.acne.com:5061;transport=5061
why not
SET SIP_CONTROLLER_LIST 66.66.66.66:5061;transport=5061,77.77.77.77:5061;transport=5061
or
SET SIP_CONTROLLER_LIST publicFQDNofSBC1:5061;transport=5061,publicFQDNofSBC2:5061;transport=5061
Unless ENABLE_PPM_SOURCED_SIPPROXYSRVR is 0, the phone will use the IPs from PPM for registration BUT it will always also periodically register to what's in SIP_CONTROLLER_LIST.
So, for example, if you had core SM1 and 2 and many sites BSMs. And say 46xx for BSM Site 1 said:
SET SIP_CONTROLLER_LIST coreSM1:5061;transport=5061,coreSM2:5061;transport=5061,BSM1:5061;transport=5061
And suppose a user from site 2 showed up and logged in to their extension.
Even though the user from site 2 has a profile in SM for "primary coreSM1, 2ndary CoreSM2, survivable BSM2" and even though the phone will be simultaneously registered to those 3 SMs, you'll notice about after an hour that the phone will logout because it sent a register to BSM1 per the SIP controller list and got a 404 and a phone drops credentials on a 404 cause either the PW is wrong or it's registering to the wrong server.
So, in your case, what I'd think is happening is that the phone is registering to the 2nd IP in that singular FQDN, but because the phone believes it's the first SM, that's what's triggering SM to think that another phone logged in.
- Thread starter
- #13
If I were to change to: SET SIP_CONTROLLER_LIST 66.66.66.66:5061;transport=5061,77.77.77.77:5061;transport=5061 Does the phone attempt the first IP in the list upon launch over the public Internet? I guess I’m trying to preserve the same primary path as the current FQDN Europe.home-remote.acne.com:5061;transport=tls DNS points to SBC1 as primary unless it fails a probe, which then points to SBC2.
I’m gonna have to change this setting and bounce a bunch of phones, so I’m trying to not introduce anything else that may change as a result.
I’m gonna have to change this setting and bounce a bunch of phones, so I’m trying to not introduce anything else that may change as a result.
Yes, it tries the first. It'll register, get PPM, and use those.
Your PPM mapping profile is going to say something like "for SM1 10.10.10.10:5061, replace with 66.66.66.66:5061" and for SM2 10.10.11.10, use 77.77.77.77
And that's how it gets its primary/secondary
If ever 66.66.66.66 is down and a phone came up for the first time that was never registered, it'd use the settings file, know to use the second address, and upon getting PPM know that 66.66.66.66 is the primary and if its failback policy is automatic, then it'd know it should flip back to 66 and that 77 was never intended to be its primary in the first place.
You can maybe test it out if you put a group in your settings file for testing, or find a way to load a 46xx locally to your phone with the changes to see how it behaves.
Make sure you're not using extended hostname validation to avoid a cert error
Your PPM mapping profile is going to say something like "for SM1 10.10.10.10:5061, replace with 66.66.66.66:5061" and for SM2 10.10.11.10, use 77.77.77.77
And that's how it gets its primary/secondary
If ever 66.66.66.66 is down and a phone came up for the first time that was never registered, it'd use the settings file, know to use the second address, and upon getting PPM know that 66.66.66.66 is the primary and if its failback policy is automatic, then it'd know it should flip back to 66 and that 77 was never intended to be its primary in the first place.
You can maybe test it out if you put a group in your settings file for testing, or find a way to load a 46xx locally to your phone with the changes to see how it behaves.
Make sure you're not using extended hostname validation to avoid a cert error
- Thread starter
- #15
It's the phone sending another instance of its registration to what it thinks is the primary SM that's the problem. Purely FQDN related.
If you had internal DNS and did the same thing to the SMs and not the SBCs I'm confident you'd have the same problem if a single FQDN resolved to 2 SM100s
If you had internal DNS and did the same thing to the SMs and not the SBCs I'm confident you'd have the same problem if a single FQDN resolved to 2 SM100s
- Status
Similar threads
- Locked
- Question