[OpenSIPS-Users] update location table on REGISTER request
Jayesh Nambiar
jayesh.voip at gmail.com
Mon Jun 29 15:03:03 CEST 2009
Thanks Bogdan,Thats great !!
--- Jay
On Mon, Jun 29, 2009 at 6:18 PM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:
> Hi Jayesh,
>
> I just added in 1.6 branch (devel) some more control over the registrar
> module behaviour - some options are now per AOR (and not global), so you can
> set "b" (no Branches) flag to "lookup()" function only for the users you
> want to use only one contact.
>
> See:
> http://www.opensips.org/html/docs/modules/devel/registrar.html#id271025
>
> Regards,
> Bogdan
>
>
> Bogdan-Andrei Iancu wrote:
>
>> HI Jayesh,
>>
>> You made a good point here - as all branches do have the same q, the
>> function will actually do nothing (or almost nothing).
>>
>> So, what I suggest is:
>> - adding some params to the lookup() function to be able to pass as flag
>> (per user) if branches should be added or not
>> - a clear_branches() function (for more generic usage) to remove any
>> already branches.
>>
>> I think this will solve your problem.
>>
>> Best regards,
>> Bogdan
>>
>> Jayesh Nambiar wrote:
>>
>>> Hi Bogdan,
>>> Thanks for your reply.
>>> This had made perfect sense to me when you suggested this solution first.
>>> The problem I ran into was even after using serialize_branches(), all the
>>> registered contacts used to get the call.
>>> What I did was: - Did a lookup location
>>> - Before calling t_relay called the function serialize_branches(1)
>>>
>>> After searching a little about serialize_branches, I got to know that it
>>> serializes based upon the q value only and contacts with same q-value will
>>> be still parelell forked.
>>> So i got stuck there :(
>>>
>>> --- Jay
>>>
>>> On Tue, Jun 23, 2009 at 2:01 PM, Bogdan-Andrei Iancu <
>>> bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>>>
>>> Hi Jayesh,
>>>
>>> So, just to recap - you want to get use the last registered
>>> contact (per user option - for some user only the last, for others
>>> all contacts).
>>>
>>> What I suggested was to allow multiple registrations for all users
>>> and to keep the contacts sorted by time (so that the last uploaded
>>> contact will be the first to use).
>>> Now, during lookup(), fetch all branches from usrloc. At this
>>> point, what you have to do is to discard the additional branches
>>> for users you allow only one contact - and you can use the
>>> serialize_branches() function (without anything else) to discard
>>> the additional branches....
>>>
>>> Just let me know if what I said make sense to you.
>>>
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Jayesh Nambiar wrote:
>>>
>>> Hi Bogdan,
>>> Tried using serialize branches with different possibilities
>>> and scenarios but it only serializes based upon the "Q" value
>>> of the contact. Tried googling a lot about it but could not
>>> find much help.
>>> Contacts with same Q value are still parallel forked as
>>> clearly mentioned in the document. Moreover clients like
>>> X-Lite and Eyebeam dont even have a q value when registered. I
>>> have alredy set desc_time_order to 1 but it does not make a
>>> difference with serialize_branches() function !!
>>>
>>> Any ideas like if we can attach q values from script before
>>> saving into location table. But for that also what should be
>>> the logic before attaching the q-value???
>>> I think I am gonna make this requirement "Not Feasible" for now !!
>>>
>>> Any more ideas or ways of achieving this would be highly
>>> appreciated.
>>>
>>> Thanks,
>>>
>>> --- Jay
>>>
>>> On Fri, Jun 19, 2009 at 1:07 PM, Bogdan-Andrei Iancu
>>> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
>>> <mailto:bogdan at voice-system.ro
>>> <mailto:bogdan at voice-system.ro>>> wrote:
>>>
>>> I see....Ideally we could allow control append_branch per user,
>>> but not possible right now.
>>>
>>> What can be done is to allow append_branch for all of them
>>> and to
>>> simply purge the added branches for the users with only one
>>> contact registration. If it is a hack, use serialize_branches()
>>> function to delete the additional branches added by
>>> lookup(location) (actually the function moves the branches
>>> in some
>>> AVPS, but the important part is that the branches are
>>> cleaned :) ).
>>>
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Jayesh Nambiar wrote:
>>>
>>> Thank you Bogdan, for the correct approach explained.
>>> But the append branch then applies to all users right?
>>> What i
>>> was trying to do here was:
>>> 1) Allow some basic users to have only one registration
>>> contact possible.
>>> 2) Allow premium users to have as many contacts
>>> possible and
>>> receive calls on any of the location.
>>>
>>> Based upon certain conditions can i increase the append
>>> branch
>>> parameter after looking up location and before relaying !!!
>>> Just a thought.
>>>
>>> --- Jay
>>>
>>> On Fri, Jun 19, 2009 at 12:38 PM, Bogdan-Andrei Iancu
>>> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
>>> <mailto:bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>>
>>> <mailto:bogdan at voice-system.ro
>>> <mailto:bogdan at voice-system.ro>
>>> <mailto:bogdan at voice-system.ro
>>> <mailto:bogdan at voice-system.ro>>>> wrote:
>>>
>>> HI Jayesh,
>>>
>>> What you could do is to accept 2-3 registrations, but to
>>> actually
>>> use the last one only.
>>>
>>> So set the mac_contacts to 2 or 3, the
>>> append_branches to 0 (to
>>> use only one contact) and in usrloc module set
>>> desc_time_order to
>>> 1
>>> (
>>> http://www.opensips.org/html/docs/modules/1.5.x/usrloc.html#id266565)
>>> to sort contacts based on the registration time
>>> (first used
>>> will
>>> be the last registered)
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Jayesh Nambiar wrote:
>>>
>>> Hi All,
>>> I had a requirement of allowing only one
>>> registration
>>> per user
>>> in a particular scenario. I did not want to use the
>>> max_contacts parameter of registrar module as it
>>> wont work
>>> right !!! The drawback was:
>>> If device A had registered successfully and for
>>> some reason
>>> got disconnected from the internet, the device won't
>>> unregister itself. Opensips still has the record
>>> in the
>>> location table for that device, now if the internet
>>> comes back
>>> and when the device tries to register again,
>>> opensips
>>> will not
>>> allow since it already has the record in the
>>> location.
>>> The device will have to wait until the earlier
>>> registration
>>> expires in the opensips.
>>> The idea was to have a way of updating the location
>>> table if
>>> same user is trying to REGISTER from same
>>> location or
>>> different location. Meaning if user A is
>>> registered from
>>> location A and someone else using same
>>> credentials of
>>> user A
>>> tries to register from location B, the location
>>> table
>>> should
>>> only update the earlier record to location B and
>>> not keep
>>> location A and location B both for user A.
>>>
>>> Is there a way to do this. Any help will be highly
>>> appreciiated.
>>>
>>> Thanks in advance.
>>>
>>> --- Jay
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>
>>> <mailto:Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>>
>>> <mailto:Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>
>>> <mailto:Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>>>
>>>
>>>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090629/1d28c11a/attachment-0001.htm
More information about the Users
mailing list