[asterisk-dev] Limiting Number of registrations

[Alexander Lopez]

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com 
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
> Olle E Johansson
> Sent: Monday, February 13, 2006 1:51 PM
> To: Asterisk Developers Mailing List
> Cc: Olle E Johansson
> Subject: Re: [asterisk-dev] Limiting Number of registrations
> 
> 
> 13 feb 2006 kl. 20.16 skrev Rafael Vidal Aroca:
> 
> >
> >    Hi guys,
> >
> >    i've been playing with chan_sip.c trying to add an interesting 
> > feature in asterisk for voip providers, that blocks a 
> second SIP peer 
> > against registering in the server.
> >
> >    That would work like that: first
> >    client connects -> OK
> >    second client tries to connect while the other is 
> connect -> ERROR
> >
> >    So, i used _sip_show_peers, and checked if the user is on line.  
> > If it is online, it rejects the register. Now a great 
> problem arises! 
> > The update is exactly like the first register, so after the first 
> > register, the client can't keep the register correctly.
> >      I don't know if i explained well, but the ideia is to block 
> > simultaneos connections. Does anyone have an idea or hint 
> of how that 
> > could be done?
> ´
> I've been trying various concepts over time, but nothing is 
> fool proof. What if a customer looses power, everything 
> reboots and he's got a new IP from the DHCP server? We won't 
> allow that registration...
> 
> I think an external hook that optionally can be executed is better.  
> That way, a system could send a warning e-mail to the 
> customer or notify him in some way that he's confusing the system.
> 
> /O_______________________________________________

I will post this again with the changes due to Olle's post:
Expand your rules to check for remote IP and Device IP both of these are available with the functions for SIP.

First Conpare the the EXTERNAL Ip's if they match a currently registered account, then check the INTERNAL IP, if it holds true then allow the (re)-registration. If not block.
 
Use the re-register function to determine how often the UA is set to send a re-register request. Store the next 'interval' in memory if a period of time has passed say 1.5xinterval than delete the rule.  As the device is not working.

If a network 'goes down' and the router spits out a new IP and the UA grabs a new one, it is enough of an event that users will know that something is wrong.


Comments??


Alex



>