Thanks Bogdan,Thats great !! --- Jay
On Mon, Jun 29, 2009 at 6:18 PM, Bogdan-Andrei Iancu <[email protected] > 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 < >>> [email protected] <mailto:[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]> >>> <mailto:[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]>> >>> <mailto:[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]>> >>> <mailto:[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
