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