[Serusers] Restrict registration to one user per login

[Java Rockx]

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
>