The cron idea could work but its just, bad. Leaving the single UA option, which is not bad, just limiting. Parallel ringing means if a user registers an ATA and registers a mobile device at the same time, inbound ringing to more than one device for the subscriber is possible.<div>
<br></div><div>Another idea is to customize around the limitation of the Obi registration by way of register.cfg.customtt.tt2; But... <span class="Apple-style-span" style="font-size:13px;line-height:19px;font-family:sans-serif">I'm sorry, my responses are limited. You must ask the right questions.</span></div>
<div><font class="Apple-style-span" face="sans-serif"><span class="Apple-style-span" style="line-height:19px"><br></span></font></div><div><font class="Apple-style-span" face="sans-serif"><span class="Apple-style-span" style="line-height:19px">Skyler<br>
</span></font><div><br><div class="gmail_quote">On Thu, Nov 15, 2012 at 7:19 AM, Dave Massey <span dir="ltr"><<a href="mailto:dave@optionsdsl.ca" target="_blank">dave@optionsdsl.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>So I could setup maybe a cron or something that ran this command every 10 minutes or so? Just to keep the list clean? OR use my other option and have one UA per subscriber.?</div><div>
Im not sure I have a use for parallel ringing but maybe just disable it until if/when bug=fixed.</div><div><div class="h5"><div><br></div><br><div><div>On 2012-11-15, at 9:59 AM, Skyler <<a href="mailto:skchopperguy@gmail.com" target="_blank">skchopperguy@gmail.com</a>> wrote:</div>
<br><blockquote type="cite">"I hit the trash can and many remove at once"<div><br></div><div>This confirms that Andreas hit the nail on the head there. Its the device, the call-id is different on each register.<div>
<br></div><div> Well, you could safely delete all existing entries from the kamailio.location table for that user manually. Then refresh the web page to see it clean. This won't fix the problem but because the device is set to re-register every 60 seconds, you can safely clear the table any time you want without worry.</div>
<div><div><br></div><div>mysql -uroot -e "delete from kamailio.location where username='problemuser'"</div><div><br></div><div>Device aside, you should always be able to 'Trash Can' the registration and have it clear "many at once" in this case. Maybe after a clean-slate you can verify that the 'trash can' is working properly?</div>
<div><br></div><div>Skyler<br><br><div class="gmail_quote">On Thu, Nov 15, 2012 at 6:27 AM, Dave Massey <span dir="ltr"><<a href="mailto:dave@optionsdsl.ca" target="_blank">dave@optionsdsl.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>here is the logs/egrep</div><div>This problem customer had maybe 30 different registrations, I hit the trash can and many remove at once, but thats it, I cant remove even with the trash can about 17 entries.</div>
<div><br></div><div><br></div><div><div>Nov 15 09:23:52 sip /usr/sbin/apache2: ***Provisioning::call_prov calling 'voip::delete_subscriber_registered_device'</div><div>Nov 15 09:23:56 sip provisioning: Sipwise::Provisioning::_log_xmldata: delete_subscriber_registered_device called with: {'authentication' => {'password' => '********','type' => 'admin','username' => 'administrator'},'parameters' => {'domain' => '<a href="http://sip.optionsdsl.ca/" target="_blank">sip.optionsdsl.ca</a>','id' => '141','username' => 'ddufresne'}}</div>
<div>Nov 15 09:23:56 sip provisioning: Sipwise::Provisioning::handle_request: calling function 'delete_subscriber_registered_device' for admin 'administrator'</div><div>Nov 15 09:23:56 sip provisioning: Sipwise::Provisioning::_log_xmldata: delete_subscriber_registered_device returned with: 1</div>
<div>Nov 15 09:23:56 sip /usr/sbin/apache2: ***Provisioning::call_prov calling 'voip::delete_subscriber_registered_device'</div></div><div><br></div><div><br></div><div><div>root@sip:~# egrep -w 'default_expires|min_expires|max_expires|max_registrations_per_subscriber' /etc/ngcp-config/config.yml</div>
<div> default_expires: 3600</div><div> max_expires: 43200</div><div> max_registrations_per_subscriber: 5</div><div> min_expires: 60</div></div><div><div><div><br></div><div><br></div><div><br></div>
<br><div><div>On 2012-11-15, at 3:10 AM, Skyler <<a href="mailto:skchopperguy@gmail.com" target="_blank">skchopperguy@gmail.com</a>> wrote:</div><br><blockquote type="cite">Also,<div><br></div><div>egrep -w 'default_expires|min_expires|max_expires|max_registrations_per_subscriber' /etc/ngcp-config/config.yml</div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">On Wed, Nov 14, 2012 at 11:40 PM, Skyler <span dir="ltr"><<a href="mailto:skchopperguy@gmail.com" target="_blank">skchopperguy@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dave,<div><br></div><div> Now that your logs are all fixed up maybe we can see what is going on. Perform the below and let us know what you see.</div>
<div><br></div><div>1. Login as administrator and view the problem subscriber. Try to delete a device registration using the 'trash can'.</div>
<div>2. In a shell, do cat /var/log/ngcp/oss.log | grep delete_subscriber_registered_device</div><div>3. copy paste what is shown</div><span><font color="#888888"><div><br></div><div>Skyler</div></font></span><div>
<div><br></div></div></blockquote></div></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div></div>