[SR-Users] t_load_contacts in 5.4.0

Daniel-Constantin Mierla miconda at gmail.com
Thu Aug 20 07:54:19 CEST 2020


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 at gmail.com <mailto:miconda at 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 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
>>     <mailto:u1 at s.com> and do append_branch(u2 at s.com
>>     <mailto:u2 at s.com>) and append_branch(u3 at s.com <mailto: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 <mailto:sr-users at 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
>
-- 
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/20200820/a2161e14/attachment.htm>


More information about the sr-users mailing list