Re: [Serusers] Restrict registration to one user per login

It would be really nice if somehow the SIP UA's MAC address could be discovered. If that were possible you could really do per-seat connections. Regards, Paul On Wed, 23 Mar 2005 14:29:37 -0500, Dana Olson <rickaster(a)gmail.com> wrote: > As far as I knew, 0.9.0 wasn't officially released as stable yet. Am I wrong? > > And yes, what you said to prevent the locking issue is exactly > correct. But my scripting does this on 0.8.14 as well. The only time > it will lock is if an IP address changes and then a reregister request > is sent without unregistering first. I don't even know if that is a > possibility, but I assume it is. > > Ideally, we would be able to know if it's the same phone > re-registering, but you can't tell the difference if it's the same > person with a new IP, or, for example, if you open up task manager, > kill the softphone (which means its registration doesn't force > expire/unregister), change IP addresses, and then log in again. > > My script does this in its current state. It will only reject if the > registration hasn't expired and a new IP address is trying to > register. I'm not sure, but I assume, this is also what happens with > max_contacts. > -- > Dana > > On Wed, 23 Mar 2005 16:54:21 GMT, Iqbal <iqbal(a)gigo.co.uk> wrote: > > > > Hi > > > > I never tried max_contacts, but would it not be possible to logoff the > > previous contact b4 the new one registers, that way you wont have a > > locking issue. > > > > This is the kind of thing I guess yahoo IM etc all do...kind of > > > > Iqbal > > > > PS is max contacts in CVS head, or in 0.9 also > > > > On 3/23/2005, "Java Rockx" <javarockx(a)gmail.com> wrote: > > > > >We're shipping UTstarcom iAN-02EX ATAs and these are fully remote > > >configurable as they query our Apache farm for their configuration > > >upon bootup (based on their MAC address). > > > > > >So we have full control of the customer IAD, and the customer doesn't. > > > > > >For softphones --- this is bad. Xten (eyebeam) AFAIK, do not have a > > >way to remotely configure them and therefore you have to give the SIP > > >proxy UID and PWD to the customer and we decided under no > > >circumstances will this be done on our network. > > > > > >The solution for a softphone is to find one that will remotely > > >configure like the UTstarcom IAD. We're not shipping softphones so I > > >can't really help you there. > > > > > >Regards, > > >Paul > > > > > > > > >On Wed, 23 Mar 2005 10:05:26 -0500, Dana Olson <rickaster(a)gmail.com> wrote: > > >> On Wed, 23 Mar 2005 09:14:42 -0500, Java Rockx <javarockx(a)gmail.com> wrote: > > >> > IMHO setting max_contacts is very dangerous because if you reboot your > > >> > SIP UA and your NAT device gives you a new port assignment, the you > > >> > will __fail__ to register if your previous contact AOR has not > > >> > expired. > > >> > > > >> > I think this is the hardest part of implementing a "per-seat" > > >> > configuration. You just don't know when a NAT will assign a new port > > >> > to a SIP UA. > > >> > > > >> > I gave up on this for this very reason. Our solution is to lock down > > >> > the SIP UAs and never let a customer get in to the settings (except > > >> > for the LAN/WAN settings). > > >> > > > >> > Regards, > > >> > Paul > > >> > > >> Hey Paul, I hear you. I'm just saying that max_contacts is basically > > >> what we're attempting to accomplish, only in the stable banch of SER. > > >> And I've basically got it down to the point where the only time it > > >> locks me out is if A) someone is already logged in with that account, > > >> or B) my IP address changes. I also wrote a real quick CGI that will > > >> list all the users logged in, and if you click on any of them, it'll > > >> force them out of the location table, allowing someone else to login > > >> (or re-login, if the IP changed). > > >> > > >> However, if my superiors find this to not be an acceptable solution, > > >> I'd like to know what you are using, and how did you lock it down? We > > >> tried with SJphone and had some success, but the quality just doesn't > > >> compare to eyeBeam. We managed to lockdown eyeBeam a bit, but users > > >> can still get into the settings. I'd appreciate your insight. > > >> -- > > >> Dana