Hi Bogdan,<div>Thanks for your reply.</div><div>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.</div>
<div>What I did was: </div><div>- Did a lookup location</div><div>- Before calling t_relay called the function serialize_branches(1)</div><div><br></div><div>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.</div>
<div>So i got stuck there :(</div><div><br></div><div>--- Jay<br><br><div class="gmail_quote">On Tue, Jun 23, 2009 at 2:01 PM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Jayesh,<br>
<br>
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).<br>
<br>
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).<br>
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....<br>
<br>
Just let me know if what I said make sense to you.<div class="im"><br>
<br>
Regards,<br>
Bogdan<br>
<br>
Jayesh Nambiar wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hi Bogdan,<br>
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.<br>
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 !!<br>
<br>
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???<br>
I think I am gonna make this requirement "Not Feasible" for now !!<br>
<br>
Any more ideas or ways of achieving this would be highly appreciated.<br>
<br>
Thanks,<br>
<br>
--- Jay<br>
<br></div><div><div></div><div class="h5">
On Fri, Jun 19, 2009 at 1:07 PM, Bogdan-Andrei Iancu <<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a> <mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>>> wrote:<br>
<br>
I see....Ideally we could allow control append_branch per user,<br>
but not possible right now.<br>
<br>
What can be done is to allow append_branch for all of them and to<br>
simply purge the added branches for the users with only one<br>
contact registration. If it is a hack, use serialize_branches()<br>
function to delete the additional branches added by<br>
lookup(location) (actually the function moves the branches in some<br>
AVPS, but the important part is that the branches are cleaned :) ).<br>
<br>
<br>
Regards,<br>
Bogdan<br>
<br>
Jayesh Nambiar wrote:<br>
<br>
Thank you Bogdan, for the correct approach explained.<br>
But the append branch then applies to all users right? What i<br>
was trying to do here was:<br>
1) Allow some basic users to have only one registration<br>
contact possible.<br>
2) Allow premium users to have as many contacts possible and<br>
receive calls on any of the location.<br>
<br>
Based upon certain conditions can i increase the append branch<br>
parameter after looking up location and before relaying !!!<br>
Just a thought.<br>
<br>
--- Jay<br>
<br>
On Fri, Jun 19, 2009 at 12:38 PM, Bogdan-Andrei Iancu<br>
<<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a> <mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>><br>
<mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a><br>
<mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>>>> wrote:<br>
<br>
HI Jayesh,<br>
<br>
What you could do is to accept 2-3 registrations, but to<br>
actually<br>
use the last one only.<br>
<br>
So set the mac_contacts to 2 or 3, the append_branches to 0 (to<br>
use only one contact) and in usrloc module set<br>
desc_time_order to<br>
1<br>
(<a href="http://www.opensips.org/html/docs/modules/1.5.x/usrloc.html#id266565" target="_blank">http://www.opensips.org/html/docs/modules/1.5.x/usrloc.html#id266565</a>)<br>
to sort contacts based on the registration time (first used<br>
will<br>
be the last registered)<br>
<br>
Regards,<br>
Bogdan<br>
<br>
Jayesh Nambiar wrote:<br>
<br>
Hi All,<br>
I had a requirement of allowing only one registration<br>
per user<br>
in a particular scenario. I did not want to use the<br>
max_contacts parameter of registrar module as it wont work<br>
right !!! The drawback was:<br>
If device A had registered successfully and for some reason<br>
got disconnected from the internet, the device won't<br>
unregister itself. Opensips still has the record in the<br>
location table for that device, now if the internet<br>
comes back<br>
and when the device tries to register again, opensips<br>
will not<br>
allow since it already has the record in the location.<br>
The device will have to wait until the earlier registration<br>
expires in the opensips.<br>
The idea was to have a way of updating the location<br>
table if<br>
same user is trying to REGISTER from same location or<br>
different location. Meaning if user A is registered from<br>
location A and someone else using same credentials of<br>
user A<br>
tries to register from location B, the location table<br>
should<br>
only update the earlier record to location B and not keep<br>
location A and location B both for user A.<br>
<br>
Is there a way to do this. Any help will be highly<br>
appreciiated.<br>
<br>
Thanks in advance.<br>
<br>
--- Jay<br>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>>><br>
<br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br></div>