20 Aug
2020
20 Aug
'20
5:54 a.m.
Hello,
as I see it in the issue tracker, with revert_uri() the $ru is not added to the destinations list, only the two appended branches appear in the logs. So that is no longer an issue, right? Only the reverse ordering?
Cheers, Daniel
On 19.08.20 18:43, Cindy Leung wrote:
Hi Daniel,
Thanks for the suggestion. I'm not modifying the R-URI in any way but tested with revert_uri() regardless. The behavior is the same. I'll open a ticket. Thanks.
Cindy
On Wed, Aug 19, 2020 at 10:18 AM Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Looking a bit at the node, I see that the r-uri branch is ignored if not changed at all. So if you updated r-uri in the config, then it will be kept. But the same behaviour seems to be in 5.3. Maybe in the new config you do operations over $ru or use some functions changing it. You can try to do revert_uri() before t_load_contacts(0). Cheers, Daniel On 19.08.20 16:12, Daniel-Constantin Mierla wrote:Hello, On 18.08.20 08:05, Cindy Leung wrote:Hello all, Just started using v5.4.0 on our system and I noticed a change in behavior when doing the append_branch, t_load_contacts, and t_next_contacts combo. Previously using v5.3.4 and it appears to be fine. Here's the call scenario: Kamailio receives a call to sip:1001@carrierB. Kamailio sees carrierB and appends 2 contacts: gateway1.carrierB.com <http://gateway1.carrierB.com>;q=0.3 and gateway2.carrierB.com <http://gateway2.carrierB.com>;q=0.2. After t_load_branches(0),first, I am not finding the t_load_branches() function, is it supposed to be t_load_contacts()? The, supposing it was the later, afaik, the load contacts was putting the branches in internal xavps, not pushing to the r-uri. The append_branch() was not changing the first branch (the r-uri) but adding extra. So if you have the invite coming in to u1@s.com <mailto:u1@s.com> and do append_branch(u2@s.com <mailto:u2@s.com>) and append_branch(u3@s.com <mailto:u3@s.com>), then it will be 3 branches that will go out in case of parallel forking. With t_load_contacts() and t_next_contacts(), these 3 branches should be prepared to do serial forking. Now, I haven't really used these functions myself to comment more, it is based on what append_branch() is doing: adding extra branches and keeping the first branch (r-uri) untouched. But if you found a different behaviour than expected, open a bug on issue tracker and we can refer the developer of commit 1399714fbba63732f94eb8034dabb1e565ca832a (which added proportional load) to review it. Cheers, DanielI expect to see $rd to be changed to gateway1.carrierB.com <http://gateway1.carrierB.com>, but it's not. This is the piece of config I'm trying to debug: xlog ("=== branch 0: $(branch(uri)[0]), $(branch(q)[0])\n"); xlog ("=== branch 1: $(branch(uri)[1]), $(branch(q)[1])\n"); t_load_contacts(0); while (t_next_contacts()) { xlog ("=== rd = $rd\n"); } This is the log I get. It appears to use the backup contact first. ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: === branch 0: sip:1001@gateway2.carrierB.com <mailto:sip%3A1001@gateway2.carrierB.com>;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: === branch 1: sip:1001@gateway1.carrierB.com <mailto:sip%3A1001@gateway1.carrierB.com>;transport=tcp, 300 DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: tm [t_serial.c:522]: t_load_contacts(): load_contact mode selected: 0 DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: tm [t_serial.c:340]: ki_t_load_contacts_mode(): nr_branches is 2 DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66608 DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: tm [t_serial.c:890]: ki_t_next_contacts(): Appending branch uri-'sip:1001@gateway1.carrierB.com <mailto:uri-%27sip%3A1001@gateway1.carrierB.com>;transport=tcp' dst-'' path-'' inst-'' ruid-'' location_ua-'' DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66350 ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: === rd = carrierB DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66078 ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: === rd = gateway2.carrierB.com <http://gateway2.carrierB.com> DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21 <mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: tm [t_serial.c:627]: ki_t_next_contacts(): no contacts in contacts_avp - we are done! t_load_contacts(1) works a little better. But we don't need the probability feature. ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: === branch 0: sip:1001@gateway2.carrierB.com <mailto:sip%3A1001@gateway2.carrierB.com>;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: === branch 1: sip:1001@gateway1.carrierB.com <mailto:sip%3A1001@gateway1.carrierB.com>;transport=tcp, 300 DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: tm [t_serial.c:522]: t_load_contacts(): load_contact mode selected: 1 DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: tm [t_serial.c:340]: ki_t_load_contacts_mode(): nr_branches is 2 DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: tm [t_serial.c:280]: t_load_contacts_proportional(): proportionally selected contact with uri: sip:1001@gateway1.carrierB.com <mailto:sip%3A1001@gateway1.carrierB.com>;transport=tcp (q: 300, random: 287, q_index: 500, q_total: 500) DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: tm [t_serial.c:280]: t_load_contacts_proportional(): proportionally selected contact with uri: sip:1001@gateway2.carrierB.com <mailto:sip%3A1001@gateway2.carrierB.com>;transport=udp (q: 200, random: 157, q_index: 200, q_total: 200) DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: tm [t_serial.c:303]: t_load_contacts_proportional(): proportionally added backup contact with uri: sip:1001@carrierB SIP/2.0#015#012Via: SIP/2.0/UDP 172.18.1.21:5060;branch=z9hG4bK-21-1-0 blah blah blah (q: -1) DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec078 ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: === rd = gateway1.carrierB.com <http://gateway1.carrierB.com> DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec350 ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: === rd = gateway2.carrierB.com <http://gateway2.carrierB.com> DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec608 ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: === rd = carrierB DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: tm [t_serial.c:627]: ki_t_next_contacts(): no contacts in contacts_avp - we are done! As a comparison, this is what we've been getting in 5.3.4 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: === branch 0: sip:1001@gateway2.carrierB.com <mailto:sip%3A1001@gateway2.carrierB.com>;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: === branch 1: sip:1001@gateway1.carrierB.com <mailto:sip%3A1001@gateway1.carrierB.com>;transport=tcp, 300 DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: tm [t_serial.c:191]: ki_t_load_contacts(): nr_branches is 2 DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: <core> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a680 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: === rd = gateway1.carrierB.com <http://gateway1.carrierB.com> DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: <core> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a3a8 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: === rd = gateway2.carrierB.com <http://gateway2.carrierB.com> DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: <core> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a0d0 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: === rd = carrierB DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21 <mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: tm [t_serial.c:460]: ki_t_next_contacts(): no contacts in contacts_avp - we are done! Is there anything else that's been changed in branch building that we should pay attention to? Thanks. Cindy _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Funding: https://www.paypal.me/dcmierla-- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Funding: https://www.paypal.me/dcmierla
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla