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 <[email protected]> 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;q=0.3 > and 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 [email protected] and do append_branch([email protected]) and > append_branch([email protected]), 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, > Daniel > > I expect to see $rd to be changed to 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: [email protected]: === branch 0: > sip:[email protected];transport=udp, 200 > ERROR: IBG_LOG: [email protected]: === branch 1: > sip:[email protected];transport=tcp, 300 > DEBUG: IBG_LOG: [email protected]: tm > [t_serial.c:522]: t_load_contacts(): load_contact mode selected: 0 > DEBUG: IBG_LOG: [email protected]: tm > [t_serial.c:340]: ki_t_load_contacts_mode(): nr_branches is 2 > DEBUG: IBG_LOG: [email protected]: <core> > [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66608 > DEBUG: IBG_LOG: [email protected]: tm > [t_serial.c:890]: ki_t_next_contacts(): Appending branch > uri-'sip:[email protected];transport=tcp' dst-'' path-'' inst-'' > ruid-'' location_ua-'' > DEBUG: IBG_LOG: [email protected]: <core> > [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66350 > ERROR: IBG_LOG: [email protected]: === rd = > carrierB > DEBUG: IBG_LOG: [email protected]: <core> > [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66078 > ERROR: IBG_LOG: [email protected]: === rd = > gateway2.carrierB.com > DEBUG: IBG_LOG: [email protected]: 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: [email protected]: === branch 0: > sip:[email protected];transport=udp, 200 > ERROR: IBG_LOG: [email protected]: === branch 1: > sip:[email protected];transport=tcp, 300 > DEBUG: IBG_LOG: [email protected]: tm > [t_serial.c:522]: t_load_contacts(): load_contact mode selected: 1 > DEBUG: IBG_LOG: [email protected]: tm > [t_serial.c:340]: ki_t_load_contacts_mode(): nr_branches is 2 > DEBUG: IBG_LOG: [email protected]: tm > [t_serial.c:280]: t_load_contacts_proportional(): proportionally selected > contact with uri: sip:[email protected];transport=tcp (q: 300, > random: 287, q_index: 500, q_total: 500) > DEBUG: IBG_LOG: [email protected]: tm > [t_serial.c:280]: t_load_contacts_proportional(): proportionally selected > contact with uri: sip:[email protected];transport=udp (q: 200, > random: 157, q_index: 200, q_total: 200) > DEBUG: IBG_LOG: [email protected]: 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: [email protected]: <core> > [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec078 > ERROR: IBG_LOG: [email protected]: === rd = > gateway1.carrierB.com > DEBUG: IBG_LOG: [email protected]: <core> > [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec350 > ERROR: IBG_LOG: [email protected]: === rd = > gateway2.carrierB.com > DEBUG: IBG_LOG: [email protected]: <core> > [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec608 > ERROR: IBG_LOG: [email protected]: === rd = > carrierB > DEBUG: IBG_LOG: [email protected]: 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: [email protected]: === branch 0: > sip:[email protected];transport=udp, 200 > ERROR: IBG_LOG: [email protected]: === branch 1: > sip:[email protected];transport=tcp, 300 > DEBUG: IBG_LOG: [email protected]: tm > [t_serial.c:191]: ki_t_load_contacts(): nr_branches is 2 > DEBUG: IBG_LOG: [email protected]: <core> > [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a680 > ERROR: IBG_LOG: [email protected]: === rd = > gateway1.carrierB.com > DEBUG: IBG_LOG: [email protected]: <core> > [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a3a8 > ERROR: IBG_LOG: [email protected]: === rd = > gateway2.carrierB.com > DEBUG: IBG_LOG: [email protected]: <core> > [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a0d0 > ERROR: IBG_LOG: [email protected]: === rd = > carrierB > DEBUG: IBG_LOG: [email protected]: 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 > [email protected]https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > Funding: https://www.paypal.me/dcmierla > > -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > Funding: https://www.paypal.me/dcmierla > >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
