Hi List
I have some CPE which require special handling like removing 100rel and update from the supported methods because they misbehave.
Previously, I was using reg_fetch_contacts and then appending the branches manually and stacking the UA in an AVP. With the branch index this allowed me to get the AVP containing the UA to which the call was branched in the branch route and perform filtering of methods based on UA, but it was complicated.
Now I use the intended function lookup_to_dset() but now I miss how to access the register contact UA from within a branch route.
Is there an intended way to access that information?
Mit freundlichen Grüssen
-Benoît Panizzon-
Hi Benoît
Here's something that worked for me: using location attributes. I don't know of any simpler way, even though it feels like there should be one, because this way technically saves the agent name twice. I didn't test this in detail, but the principle worked.
modparam("tm|usrloc", "xavp_contact", "ulattrs") # Just before calling save() for a REGISTER. $xavp(ulattrs=>yoink)=$ua; # For an INVITE lookup_to_dset("location"); t_on_branch("ZOINK"); branch_route [ZOINK] { xlog("L_WARN", "BRANCH $T_branch_idx RURI is $ru for UA $xavp(ulattrs[$T_branch_idx]=>yoink)\n"); }
2(1259) WARNING: <script>: BRANCH 1 RURI is sip:frideo@11.15.32.1:10003 for UA zoiper 2(1259) WARNING: <script>: BRANCH 2 RURI is sip:frideo@11.15.32.1:10004 for UA linphone
James
On Mon, 20 Jan 2025 at 12:49, Benoit Panizzon via sr-users sr-users@lists.kamailio.org wrote:
Hi List
I have some CPE which require special handling like removing 100rel and update from the supported methods because they misbehave.
Previously, I was using reg_fetch_contacts and then appending the branches manually and stacking the UA in an AVP. With the branch index this allowed me to get the AVP containing the UA to which the call was branched in the branch route and perform filtering of methods based on UA, but it was complicated.
Now I use the intended function lookup_to_dset() but now I miss how to access the register contact UA from within a branch route.
Is there an intended way to access that information?
Mit freundlichen Grüssen
-Benoît Panizzon-
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi James
Here's something that worked for me: using location attributes. I don't know of any simpler way, even though it feels like there should be one, because this way technically saves the agent name twice. I didn't test this in detail, but the principle worked.
Thank you! I'll have a try.
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello,
On 20.01.25 13:40, Benoit Panizzon via sr-users wrote:
Hi List
I have some CPE which require special handling like removing 100rel and update from the supported methods because they misbehave.
Previously, I was using reg_fetch_contacts and then appending the branches manually and stacking the UA in an AVP. With the branch index this allowed me to get the AVP containing the UA to which the call was branched in the branch route and perform filtering of methods based on UA, but it was complicated.
Now I use the intended function lookup_to_dset() but now I miss how to access the register contact UA from within a branch route.
Is there an intended way to access that information?
after lookup location call, the UA from register is made available in the $location_ua for the contact set in r-uri and $(branch(location_ua)[INDEX]) that gives it for additional branches. Maybe you can get it in branch route as well, if branch index is 0, then is the r-uri, the next branches are built from additional branches after lookup location.
An alternative is to set a branch flag during the registration when you know that some specific processing has to be done when sending requests to that contact. The branch flags are available in the branch route after lookup location.
Cheers, Daniel
That's interesting. It's in the 5.4 documentation, but missing from the 5.8 doc. https://www.kamailio.org/wikidocs/cookbooks/5.4.x/pseudovariables/#branchnam... https://www.kamailio.org/wikidocs/cookbooks/5.8.x/pseudovariables/#branchnam...
James
On Thu, 23 Jan 2025 at 09:11, Daniel-Constantin Mierla via sr-users sr-users@lists.kamailio.org wrote:
Hello,
On 20.01.25 13:40, Benoit Panizzon via sr-users wrote:
Hi List
I have some CPE which require special handling like removing 100rel and update from the supported methods because they misbehave.
Previously, I was using reg_fetch_contacts and then appending the branches manually and stacking the UA in an AVP. With the branch index this allowed me to get the AVP containing the UA to which the call was branched in the branch route and perform filtering of methods based on UA, but it was complicated.
Now I use the intended function lookup_to_dset() but now I miss how to access the register contact UA from within a branch route.
Is there an intended way to access that information?
after lookup location call, the UA from register is made available in the $location_ua for the contact set in r-uri and $(branch(location_ua)[INDEX]) that gives it for additional branches. Maybe you can get it in branch route as well, if branch index is 0, then is the r-uri, the next branches are built from additional branches after lookup location.
An alternative is to set a branch flag during the registration when you know that some specific processing has to be done when sending requests to that contact. The branch flags are available in the branch route after lookup location.
Cheers, Daniel
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi Daniel
after lookup location call, the UA from register is made available in the $location_ua for the contact set in r-uri and $(branch(location_ua)[INDEX]) that gives it for additional branches. Maybe you can get it in branch route as well, if branch index is 0, then is the r-uri, the next branches are built from additional branches after lookup location.
Thank you!
$location_ua is correctly set in the branch route. This saves me having to use the XAVP including associated database overhead.
$(branch(location_ua)[$T_branch_idx]) does not seem to work in branch routes in 5.7
Mit freundlichen Grüssen
-Benoît Panizzon-
On 23.01.25 13:06, Benoit Panizzon wrote:
Hi Daniel
after lookup location call, the UA from register is made available in the $location_ua for the contact set in r-uri and $(branch(location_ua)[INDEX]) that gives it for additional branches. Maybe you can get it in branch route as well, if branch index is 0, then is the r-uri, the next branches are built from additional branches after lookup location.
Thank you!
$location_ua is correctly set in the branch route. This saves me having to use the XAVP including associated database overhead.
Just test and be sure it is not always the ua header of the first branch, I haven't analysed the code much, but it seemed to point to sip msg filed, which is for first branch.
Cheers, Daniel
[]
Hi Daniel
Just test and be sure it is not always the ua header of the first branch, I haven't analysed the code much, but it seemed to point to sip msg filed, which is for first branch.
At least, in the branch route, I get different ua per branch.
I have not yet verified, if they match the ua of the called destination or if they are random ;)