[SR-Users] reg_fetch_contacts for multiple devices registered

Jonathan Hunter hunterj91 at hotmail.com
Tue May 13 13:28:43 CEST 2014



Hi Guys,
Following on from my initial query, I have indexing working for reg_fetch_contacts, however now I am having issues with branching.
First, is append_branches() still applicable to kamailio  4.0.6 ? As when I use its not recognised.
Also I have two contacts registered, contact 0 and contact 1.
Contact 0 was registered first, then contact 1.
Now I perform manipulation on the main branch after identifying the user agent for contact 1, and the mainbranch request is sent out as I wish, this uses branch [0] when running debug to the $ru/$du I have modified.
However with branch [1] this isnt modified which is fine, but uses the contact AOR from Contact 1 and not Contact 0.
Is this normal behaviour and I just need to improve my logic?
Any advise on parallel branching where you extract certain credentials from location table, then as a resultmanipulate the $ru and $du as a result, but dont affect any other multiple registrations that would be great!
Many thanks
Jon








Hi Guys,
I was wondering if anyone could help?
I am currently using reg_fetch_contacts to manipulate signaling based on the user agent device being used, therefore I use the result of;
if(reg_fetch_contacts("location", "$ru", "callee")){  xlog("callee=>user_agent $ulc(callee=>user_agent)\n");}

I then use   $ulc(callee=>user_agent) to make routing decisions.
This seems to only return the user-agent device being used for the first registration at that AOR, as I have two devices registered, a Cisco, and a jitsi client, and it only returns the user_agent of the jitsi client I registered first.
Is it possible to return the user agents of all the devices registered against an AOR so I can manage decisions accordingly?
Many thanks
Jon

 		 	   		   		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140513/7bfdbd9e/attachment.html>


More information about the sr-users mailing list