[Serusers] Restrict registration to one user per login

[Dana Olson]

I thought of this too, and I think it really is the only way to do it. *sigh*

I suppose that this could be done if we develop our own custom
softphone, but I doubt we will do that (not entirely true, we're
considering it, but it won't be immediately deployable either way).

Ah well, I'm close enough I think. :)
--
Dana


On Wed, 23 Mar 2005 14:37:29 -0500, Java Rockx <javarockx at gmail.com> wrote:
> 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 at 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 at 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 at 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 at gmail.com> wrote:
> > > >> On Wed, 23 Mar 2005 09:14:42 -0500, Java Rockx <javarockx at 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