[SR-Users] Behavior of UAC-Redirect module

[Daniel-Constantin Mierla]

The uac module (as well as other, like usrloc) do not apply q value
rules themselves. One has to use t_load_contacts()/t_next_contacts()
from tm for that, as you discovered already. If those functions are not
used, then parallel forking is done, ignoring the q values.

Cheers,
Daniel


On 25.01.18 21:59, Richard Skidmore wrote:
>
> I managed to work around the problem.  I'd love to hear from anyone
> who has gotten this module to work correctly.
>
> I found two problems with the module:
>
> (1) It is not supporting the q value correctly.  It seems to be
> sorting the q value in ascending sequence or is not sorting it at
> all.  I'm not sure which.
>
> (2) Even though there were multiple different q values, the sip calls
> were not serialized.
>
> I was able to get around the problem with the following code that uses
> the UAC Redirect module to gather the Contact Bindings and create the
> branch.  It does this part correctly.  I then used the TM module to
> handle the calls serially and to sort the bindings in descending
> order.  Here's the code:
>
> modparam("tm", "contacts_avp", "tm_contacts");
> modparam("tm", "contact_flows_avp", "tm_contact_flows");
>
> # redirect with storing acc record
> failure_route[REDIRECT_ACC] {
>     xlog("$var(loglevel)","In failure_route[REDIRECT_ACT]");
>     if(!t_check_status("3[0-9][0-9]")) {
>                 xlog("$var(loglevel)","In failure_route[REDIRECT_ACT]
> - NOT 3nn");
>         exit;
>     }
>     get_redirects("*:*", "redirect");
>        
>     t_load_contacts();
>     t_next_contacts();
>     t_on_failure("serial");
>
>     t_relay();
> }
>
> failure_route["serial"]
> {
>   xlog("$var(loglevel)","In failure_route serial");
>   if (!t_next_contacts()) {
>     exit;
>   }
>
>   t_on_failure("serial");
>   t_relay();
> }
>
> Rich
>
>
> On 1/25/2018 9:31 AM, Richard Skidmore wrote:
>> This is my first post so bear with me if I leave something out.
>>>
>>> I'm attempting to handle a 302 redirect being returned from another
>>> sip switch.  The 302 message contacts contains 6 redirect bindings
>>> with a different q value for each.  I'm using the UAC_redirect
>>> module to handle the redirect.  My problem is that it does not
>>> serialize the sip calls.  Instead it calls each in turn without
>>> waiting for a response from the previous.  I'm unable to configure
>>> the redirect module to serialize the calls.   What am I missing?
>>>
>>> I've tried changing the get_redirects call to:
>>>
>>> get_redirects("*:*", "redirect");
>>> get_redirects("1:*", "redirect");
>>> get_redirects("*:1", "redirect");
>>>
>>> In debugging, I did notice that the q value seems to be
>>> misinterpreted?  The code that follows shows q values of 
>>> 930,940,950 and 960.  Is the module interpreting the decimal point
>>> as a thousands separator?
>>>
>>> The contact bindings:
>>>
>>> "<sip:18452259999 at 192.168.10.125:5060>;q=0.990"
>>> "<sip:18452259999 at 192.168.10.125:5060>;q=0.980"
>>> "<sip:18452259999 at 192.168.10.125:5060>;q=0.970"
>>> "<sip:18452259999 at 192.168.10.125:5060>;q=0.960"
>>> "<sip:18452259999 at 192.168.10.125:5060>;q=0.950"
>>> "<sip:18452259999 at 192.168.10.125:5060>;q=0.940"
>>> "<sip:18452259999 at 192.168.10.125:5060>;q=0.930"
>>>  
>>>
>>> the on failure route:
>>>
>>> failure_route[REDIRECT_ACC] {
>>>     xlog("$var(loglevel)","In failure_route[REDIRECT_ACT]");
>>>     if(!t_check_status("3[0-9][0-9]")) {
>>>                 xlog("$var(loglevel)","In
>>> failure_route[REDIRECT_ACT] - NOT 3nn");
>>>         exit;
>>>     }
>>>     get_redirects("*:*", "redirect");
>>>         xlog("$var(loglevel)","In failure_route contact branch
>>> index:$branch(count)");
>>>         xlog("$var(loglevel)","In failure_route contact branch
>>> q[0]:$(branch(q)[0])");
>>>         xlog("$var(loglevel)","In failure_route contact branch
>>> q[1]:$(branch(q)[1])");
>>>         xlog("$var(loglevel)","In failure_route contact branch
>>> q[2]:$(branch(q)[2])");
>>>         xlog("$var(loglevel)","In failure_route contact branch
>>> q[3]:$(branch(q)[3])");
>>>
>>>     t_relay();
>>> }
>>> The log shows:
>>>
>>>  INFO: xlog:In failure_route contact branch index:7
>>>  INFO: xlog:In failure_route contact branch q[0]:930
>>>  INFO: xlog:In failure_route contact branch q[1]:940
>>>  INFO: xlog:In failure_route contact branch q[2]:950
>>>  INFO: xlog:In failure_route contact branch q[3]:960
>>>
>>>
>>> Thanks in advance for any help.
>>>
>>> Rich
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> 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.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180126/ee1c9874/attachment.html>