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

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@192.168.10.125:5060>;q=0.990"
"<sip:18452259999@192.168.10.125:5060>;q=0.980"
"<sip:18452259999@192.168.10.125:5060>;q=0.970"
"<sip:18452259999@192.168.10.125:5060>;q=0.960"
"<sip:18452259999@192.168.10.125:5060>;q=0.950"
"<sip:18452259999@192.168.10.125:5060>;q=0.940"
"<sip:18452259999@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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users