[OpenSIPS-Users] update location table on REGISTER request

Jayesh Nambiar jayesh.voip at gmail.com
Tue Jun 23 17:38:53 CEST 2009


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
> 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>> 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>>> 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>>
>>
>>               http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090623/e855f001/attachment.htm 


More information about the Users mailing list