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 <[email protected] > 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 < >> [email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> 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 >> [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
