[asterisk-dev] Limiting Number of registrations

Rafael Vidal Aroca rafael at 3wt.com.br
Mon Feb 13 17:31:31 MST 2006


    Thanks for your opinion. I think, i'll try implementing that. But 
check that out:

gaia*CLI> sip show peer 5001
gaia*CLI>

  * Name       : 5001
  Secret       : <Set>
  MD5Secret    : <Not set>
  Context      : default
  Language     : br
  FromUser     :
  FromDomain   :
  Callgroup    :  (0)
  Pickupgroup  :  (0)
  Mailbox      :
  LastMsgsSent : -1
  Dynamic      : Yes
  Expire       : 784 seconds
  Expiry       : 900
  Insecure     : No
  Nat          : No
  ACL          : No
  CanReinvite  : No
  PromiscRedir : No
  DTMFmode     : rfc2833
  LastMsg      : 0
  ToHost       :
  Addr->IP     : 192.168.0.102 Port 5061
  Defaddr->IP  : 0.0.0.0 Port 5060
  Username     : 5001
  Codecs       : 0x10e (gsm|ulaw|alaw|g729)
  Codec Order  : (g729|alaw|ulaw|gsm)
  Status       : OK (15 ms)
  Useragent    : Sipura/SPA3000-3.1.7(GWg)
  Full Contact : sip:5001 at 192.168.0.102:5061

    Where would i differ the device ip from the remote ip?

Rafael


Alexander Lopez wrote:

> 
>
>  
>
>>-----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
>
>
>
>  
>
>_______________________________________________
>--Bandwidth and Colocation provided by Easynews.com --
>
>asterisk-dev mailing list
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>  
>


-- 
Rafael Vidal Aroca
3WT - Wireless Web World Tech
rafael at 3WT.com.br
Tel/Fax: +55 16 3371-7761
Cel: +55 16 8126-8014





More information about the asterisk-dev mailing list