[SR-Users] t_load_contacts in 5.4.0

Daniel-Constantin Mierla miconda at gmail.com
Wed Aug 19 16:18:26 CEST 2020 

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 at 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 at s.com and do
> append_branch(u2 at s.com) and append_branch(u3 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 172.18.1.21>: === branch 0:
>> sip:1001 at gateway2.carrierB.com
>> <mailto:sip%3A1001 at gateway2.carrierB.com>;transport=udp, 200
>> ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 172.18.1.21>: === branch 1:
>> sip:1001 at gateway1.carrierB.com
>> <mailto:sip%3A1001 at gateway1.carrierB.com>;transport=tcp, 300
>> DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 172.18.1.21>: <core>
>> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list
>> 0x7f983cb66608
>> DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 172.18.1.21>: tm
>> [t_serial.c:890]: ki_t_next_contacts(): Appending branch
>> uri-'sip:1001 at gateway1.carrierB.com
>> <mailto:uri-%27sip%3A1001 at gateway1.carrierB.com>;transport=tcp'
>> dst-'' path-'' inst-'' ruid-'' location_ua-''
>> DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 172.18.1.21>: <core>
>> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list
>> 0x7f983cb66350
>> ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 172.18.1.21>: === rd = carrierB
>> DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 172.18.1.21>: <core>
>> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list
>> 0x7f983cb66078
>> ERROR: IBG_LOG: sipp-ci1-20200818053427-1-23 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 172.18.1.21>: === rd =
>> gateway2.carrierB.com <http://gateway2.carrierB.com>
>> DEBUG: IBG_LOG: sipp-ci1-20200818053427-1-23 at 172.18.1.21
>> <mailto:sipp-ci1-20200818053427-1-23 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: === branch 0:
>> sip:1001 at gateway2.carrierB.com
>> <mailto:sip%3A1001 at gateway2.carrierB.com>;transport=udp, 200
>> ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: === branch 1:
>> sip:1001 at gateway1.carrierB.com
>> <mailto:sip%3A1001 at gateway1.carrierB.com>;transport=tcp, 300
>> DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: tm
>> [t_serial.c:280]: t_load_contacts_proportional(): proportionally
>> selected contact with uri: sip:1001 at gateway1.carrierB.com
>> <mailto:sip%3A1001 at gateway1.carrierB.com>;transport=tcp (q: 300,
>> random: 287, q_index: 500, q_total: 500)
>> DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: tm
>> [t_serial.c:280]: t_load_contacts_proportional(): proportionally
>> selected contact with uri: sip:1001 at gateway2.carrierB.com
>> <mailto:sip%3A1001 at gateway2.carrierB.com>;transport=udp (q: 200,
>> random: 157, q_index: 200, q_total: 200)
>> DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: tm
>> [t_serial.c:303]: t_load_contacts_proportional(): proportionally
>> added backup contact with uri: sip:1001 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: <core>
>> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list
>> 0x7f6e457ec078
>> ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: === rd =
>> gateway1.carrierB.com <http://gateway1.carrierB.com>
>> DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: <core>
>> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list
>> 0x7f6e457ec350
>> ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: === rd =
>> gateway2.carrierB.com <http://gateway2.carrierB.com>
>> DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: <core>
>> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list
>> 0x7f6e457ec608
>> ERROR: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 172.18.1.21>: === rd = carrierB
>> DEBUG: IBG_LOG: sipp-ci1-20200818054736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818054736-1-21 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 172.18.1.21>: === branch 0:
>> sip:1001 at gateway2.carrierB.com
>> <mailto:sip%3A1001 at gateway2.carrierB.com>;transport=udp, 200
>> ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 172.18.1.21>: === branch 1:
>> sip:1001 at gateway1.carrierB.com
>> <mailto:sip%3A1001 at gateway1.carrierB.com>;transport=tcp, 300
>> DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 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 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 172.18.1.21>: <core>
>> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list
>> 0x7fe13146a680
>> ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 172.18.1.21>: === rd =
>> gateway1.carrierB.com <http://gateway1.carrierB.com>
>> DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 172.18.1.21>: <core>
>> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list
>> 0x7fe13146a3a8
>> ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 172.18.1.21>: === rd =
>> gateway2.carrierB.com <http://gateway2.carrierB.com>
>> DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 172.18.1.21>: <core>
>> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list
>> 0x7fe13146a0d0
>> ERROR: IBG_LOG: sipp-ci1-20200818055736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 172.18.1.21>: === rd = carrierB
>> DEBUG: IBG_LOG: sipp-ci1-20200818055736-1-21 at 172.18.1.21
>> <mailto:sipp-ci1-20200818055736-1-21 at 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 at 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

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200819/06225c33/attachment.htm>

More information about the sr-users mailing list