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), 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: sipp-ci1-20200818053427-1-23@172.18.1.21: === branch 0: sip:1001@gateway2.carrierB.com;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21: === branch 1: sip:1001@gateway1.carrierB.com;transport=tcp, 300 DEBUG: IBG_LOG: 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: 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: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66608 DEBUG: IBG_LOG: 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;transport=tcp' dst-'' path-'' inst-'' ruid-'' location_ua-'' DEBUG: IBG_LOG: 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: === rd = carrierB DEBUG: IBG_LOG: 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: === rd = gateway2.carrierB.com DEBUG: IBG_LOG: 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: === branch 0: sip:1001@gateway2.carrierB.com;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21: === branch 1: sip:1001@gateway1.carrierB.com;transport=tcp, 300 DEBUG: IBG_LOG: 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: 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: tm [t_serial.c:280]: t_load_contacts_proportional(): proportionally selected contact with uri: sip:1001@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: tm [t_serial.c:280]: t_load_contacts_proportional(): proportionally selected contact with uri: sip:1001@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: 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: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec078 ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21: === rd = gateway1.carrierB.com DEBUG: IBG_LOG: 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: === rd = gateway2.carrierB.com DEBUG: IBG_LOG: 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: === rd = carrierB DEBUG: IBG_LOG: 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: === branch 0: sip:1001@gateway2.carrierB.com;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21: === branch 1: sip:1001@gateway1.carrierB.com;transport=tcp, 300 DEBUG: IBG_LOG: 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: <core> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a680 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21: === rd = gateway1.carrierB.com DEBUG: IBG_LOG: 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: === rd = gateway2.carrierB.com DEBUG: IBG_LOG: 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: === rd = carrierB DEBUG: IBG_LOG: 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
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 and do append_branch(u2@s.com) and append_branch(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, 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: 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 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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 and do append_branch(u2@s.com) and append_branch(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, 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: 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 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
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 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 u1@s.com and do append_branch(u2@s.com) and append_branch(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, 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: sipp-ci1-20200818053427-1-23@172.18.1.21: === branch 0: sip:1001@gateway2.carrierB.com;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23@172.18.1.21: === branch 1: sip:1001@gateway1.carrierB.com;transport=tcp, 300 DEBUG: IBG_LOG: 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: 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: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66608 DEBUG: IBG_LOG: 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;transport=tcp' dst-'' path-'' inst-'' ruid-'' location_ua-'' DEBUG: IBG_LOG: 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: === rd = carrierB DEBUG: IBG_LOG: 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: === rd = gateway2.carrierB.com DEBUG: IBG_LOG: 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: === branch 0: sip:1001@gateway2.carrierB.com;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21: === branch 1: sip:1001@gateway1.carrierB.com;transport=tcp, 300 DEBUG: IBG_LOG: 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: 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: tm [t_serial.c:280]: t_load_contacts_proportional(): proportionally selected contact with uri: sip:1001@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: tm [t_serial.c:280]: t_load_contacts_proportional(): proportionally selected contact with uri: sip:1001@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: 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: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec078 ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21@172.18.1.21: === rd = gateway1.carrierB.com DEBUG: IBG_LOG: 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: === rd = gateway2.carrierB.com DEBUG: IBG_LOG: 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: === rd = carrierB DEBUG: IBG_LOG: 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: === branch 0: sip:1001@gateway2.carrierB.com;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21: === branch 1: sip:1001@gateway1.carrierB.com;transport=tcp, 300 DEBUG: IBG_LOG: 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: <core> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a680 ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21@172.18.1.21: === rd = gateway1.carrierB.com DEBUG: IBG_LOG: 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: === rd = gateway2.carrierB.com DEBUG: IBG_LOG: 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: === rd = carrierB DEBUG: IBG_LOG: 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 Listsr-users@lists.kamailio.orghttps://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
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
-
Cindy Leung -
Daniel-Constantin Mierla