[Spce-user] Multiple ATA registrations

[Skyler]

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.

Another idea is to customize around the limitation of the Obi registration
by way of register.cfg.customtt.tt2; But... I'm sorry, my responses are
limited. You must ask the right questions.

Skyler

On Thu, Nov 15, 2012 at 7:19 AM, Dave Massey <dave at optionsdsl.ca> wrote:

> 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.?
> Im not sure I have a use for parallel ringing but maybe just disable it
> until if/when bug=fixed.
>
>
> On 2012-11-15, at 9:59 AM, Skyler <skchopperguy at gmail.com> wrote:
>
> "I hit the trash can and many remove at once"
>
> This confirms that Andreas hit the nail on the head there. Its the device,
> the call-id is different on each register.
>
>  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.
>
> mysql -uroot -e "delete from kamailio.location where
> username='problemuser'"
>
> 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?
>
> Skyler
>
> On Thu, Nov 15, 2012 at 6:27 AM, Dave Massey <dave at optionsdsl.ca> wrote:
>
>> here is the logs/egrep
>> 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.
>>
>>
>> Nov 15 09:23:52 sip /usr/sbin/apache2: ***Provisioning::call_prov calling
>> 'voip::delete_subscriber_registered_device'
>> 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' => 'sip.optionsdsl.ca','id'
>> => '141','username' => 'ddufresne'}}
>> Nov 15 09:23:56 sip provisioning: Sipwise::Provisioning::handle_request:
>> calling function 'delete_subscriber_registered_device' for admin
>> 'administrator'
>> Nov 15 09:23:56 sip provisioning: Sipwise::Provisioning::_log_xmldata:
>> delete_subscriber_registered_device returned with: 1
>> Nov 15 09:23:56 sip /usr/sbin/apache2: ***Provisioning::call_prov calling
>> 'voip::delete_subscriber_registered_device'
>>
>>
>> root at sip:~# egrep -w
>> 'default_expires|min_expires|max_expires|max_registrations_per_subscriber'
>> /etc/ngcp-config/config.yml
>>     default_expires: 3600
>>     max_expires: 43200
>>     max_registrations_per_subscriber: 5
>>     min_expires: 60
>>
>>
>>
>>
>> On 2012-11-15, at 3:10 AM, Skyler <skchopperguy at gmail.com> wrote:
>>
>> Also,
>>
>> egrep -w
>> 'default_expires|min_expires|max_expires|max_registrations_per_subscriber'
>> /etc/ngcp-config/config.yml
>>
>>
>>
>> On Wed, Nov 14, 2012 at 11:40 PM, Skyler <skchopperguy at gmail.com> wrote:
>>
>>> Hi Dave,
>>>
>>>  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.
>>>
>>> 1. Login as administrator and view the problem subscriber. Try to delete
>>> a device registration using the 'trash can'.
>>> 2. In a shell, do   cat /var/log/ngcp/oss.log | grep
>>> delete_subscriber_registered_device
>>> 3. copy paste what is shown
>>>
>>> Skyler
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20121115/f5094a27/attachment-0001.html>