18 Aug
2020
18 Aug
'20
9:05 a.m.
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(a)172.18.1.21: === branch 0:
sip:1001@gateway2.carrierB.com;transport=udp, 200
ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23(a)172.18.1.21: === branch 1:
sip:1001@gateway1.carrierB.com;transport=tcp, 300
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)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(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66608
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66350
ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23(a)172.18.1.21: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66078
ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23(a)172.18.1.21: === rd =
gateway2.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)172.18.1.21: === branch 0:
sip:1001@gateway2.carrierB.com;transport=udp, 200
ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: === branch 1:
sip:1001@gateway1.carrierB.com;transport=tcp, 300
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec078
ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: === rd =
gateway1.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec350
ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: === rd =
gateway2.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec608
ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)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(a)172.18.1.21: === branch 0:
sip:1001@gateway2.carrierB.com;transport=udp, 200
ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: === branch 1:
sip:1001@gateway1.carrierB.com;transport=tcp, 300
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)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(a)172.18.1.21: <core>
[core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a680
ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: === rd =
gateway1.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: <core>
[core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a3a8
ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: === rd =
gateway2.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: <core>
[core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a0d0
ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)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
19 Aug
19 Aug
5:12 p.m.
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(a)s.com and do
append_branch(u2(a)s.com) and append_branch(u3(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)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(a)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
5:18 p.m.
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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
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(a)s.com and do
append_branch(u2(a)s.com) and append_branch(u3(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)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(a)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
7:43 p.m.
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(a)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(a)s.com and do append_branch(u2(a)s.com) and
append_branch(u3(a)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(a)172.18.1.21: === branch 0:
sip:1001@gateway2.carrierB.com;transport=udp, 200
ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23(a)172.18.1.21: === branch 1:
sip:1001@gateway1.carrierB.com;transport=tcp, 300
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)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(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66608
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66350
ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23(a)172.18.1.21: === rd =
carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f983cb66078
ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23(a)172.18.1.21: === rd =
gateway2.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)172.18.1.21: === branch 0:
sip:1001@gateway2.carrierB.com;transport=udp, 200
ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: === branch 1:
sip:1001@gateway1.carrierB.com;transport=tcp, 300
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec078
ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: === rd =
gateway1.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec350
ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: === rd =
gateway2.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: <core>
[core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7f6e457ec608
ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21(a)172.18.1.21: === rd =
carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)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(a)172.18.1.21: === branch 0:
sip:1001@gateway2.carrierB.com;transport=udp, 200
ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: === branch 1:
sip:1001@gateway1.carrierB.com;transport=tcp, 300
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)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(a)172.18.1.21: <core>
[core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a680
ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: === rd =
gateway1.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: <core>
[core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a3a8
ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: === rd =
gateway2.carrierB.com
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: <core>
[core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7fe13146a0d0
ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21(a)172.18.1.21: === rd =
carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)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
20 Aug
20 Aug
8: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(a)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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hello,
On 18.08.20 08:05, Cindy Leung wrote:
--
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
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(a)s.com
<mailto:u1@s.com> and do append_branch(u2(a)s.com
<mailto:u2@s.com>) and append_branch(u3(a)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,
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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818053427-1-23@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818054736-1-21@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)172.18.1.21
<mailto:sipp-ci1-20200818055736-1-21@172.18.1.21>: === rd = carrierB
DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21(a)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(a)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
1555
days inactive
1557
days old
4 comments
2 participants
participants (2)
-
Cindy Leung -
Daniel-Constantin Mierla