<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<br>
<div class="moz-cite-prefix">On 25.01.18 21:59, Richard Skidmore
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f640da70-f05a-bc2f-3cf4-47707d365d0c@paladindesigns.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>I managed to work around the problem. I'd love to hear from
anyone who has gotten this module to work correctly.</p>
<p>I found two problems with the module:</p>
<p>(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.</p>
<p>(2) Even though there were multiple different q values, the sip
calls were not serialized.</p>
<p>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:</p>
<p><font face="Courier New, Courier, monospace" size="-1">modparam("tm",
"contacts_avp", "tm_contacts");<br>
modparam("tm", "contact_flows_avp", "tm_contact_flows");<br>
<br>
# redirect with storing acc record<br>
failure_route[REDIRECT_ACC] {<br>
xlog("$var(loglevel)","In failure_route[REDIRECT_ACT]");<br>
if(!t_check_status("3[0-9][0-9]")) {<br>
xlog("$var(loglevel)","In
failure_route[REDIRECT_ACT] - NOT 3nn");<br>
exit;<br>
}<br>
get_redirects("*:*", "redirect");<br>
<br>
t_load_contacts();<br>
t_next_contacts();<br>
t_on_failure("serial");<br>
<br>
t_relay();<br>
}<br>
<br>
failure_route["serial"]<br>
{<br>
xlog("$var(loglevel)","In failure_route serial");<br>
if (!t_next_contacts()) {<br>
exit;<br>
}<br>
<br>
t_on_failure("serial");<br>
t_relay();<br>
}<br>
</font></p>
<p>Rich<br>
</p>
<br>
<div class="moz-cite-prefix">On 1/25/2018 9:31 AM, Richard
Skidmore wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5b3bead1-5307-2280-f921-4afed2f17f5f@paladindesigns.com">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
This is my first post so bear with me if I leave something out.
<blockquote type="cite"
cite="mid:16a0a95d-46af-a9a3-ca07-b5e2e2390b0d@paladindesigns.com">
<p>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?</p>
<p>I've tried changing the get_redirects call to:</p>
<font face="Courier New, Courier, monospace">get_redirects("*:*",
"redirect");</font><br>
<font face="Courier New, Courier, monospace">get_redirects("1:*",
"redirect");</font><br>
<font face="Courier New, Courier, monospace">get_redirects("*:1",
"redirect");</font><br>
<br>
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?<br>
<font face="Courier New, Courier, monospace"> </font><br>
<p>The contact bindings:</p>
<p>"<a class="moz-txt-link-rfc2396E"
href="mailto:sip:18452259999@192.168.10.125:5060"
moz-do-not-send="true"><sip:18452259999@192.168.10.125:5060></a>;q=0.990"<br>
"<a class="moz-txt-link-rfc2396E"
href="mailto:sip:18452259999@192.168.10.125:5060"
moz-do-not-send="true"><sip:18452259999@192.168.10.125:5060></a>;q=0.980"<br>
"<a class="moz-txt-link-rfc2396E"
href="mailto:sip:18452259999@192.168.10.125:5060"
moz-do-not-send="true"><sip:18452259999@192.168.10.125:5060></a>;q=0.970"<br>
"<a class="moz-txt-link-rfc2396E"
href="mailto:sip:18452259999@192.168.10.125:5060"
moz-do-not-send="true"><sip:18452259999@192.168.10.125:5060></a>;q=0.960"<br>
"<a class="moz-txt-link-rfc2396E"
href="mailto:sip:18452259999@192.168.10.125:5060"
moz-do-not-send="true"><sip:18452259999@192.168.10.125:5060></a>;q=0.950"<br>
"<a class="moz-txt-link-rfc2396E"
href="mailto:sip:18452259999@192.168.10.125:5060"
moz-do-not-send="true"><sip:18452259999@192.168.10.125:5060></a>;q=0.940"<br>
"<a class="moz-txt-link-rfc2396E"
href="mailto:sip:18452259999@192.168.10.125:5060"
moz-do-not-send="true"><sip:18452259999@192.168.10.125:5060></a>;q=0.930"<br>
</p>
<p>the on failure route:</p>
<p><font face="Courier New, Courier, monospace">failure_route[REDIRECT_ACC]
{<br>
xlog("$var(loglevel)","In
failure_route[REDIRECT_ACT]");<br>
if(!t_check_status("3[0-9][0-9]")) {<br>
xlog("$var(loglevel)","In
failure_route[REDIRECT_ACT] - NOT 3nn");<br>
exit;<br>
}<br>
get_redirects("*:*", "redirect");<br>
xlog("$var(loglevel)","In failure_route contact
branch index:$branch(count)");<br>
xlog("$var(loglevel)","In failure_route contact
branch q[0]:$(branch(q)[0])");<br>
xlog("$var(loglevel)","In failure_route contact
branch </font><font face="Courier New, Courier,
monospace"><font face="Courier New, Courier, monospace">q[1]</font>:$(branch(q)[1])");<br>
xlog("$var(loglevel)","In failure_route contact
branch </font><font face="Courier New, Courier,
monospace"><font face="Courier New, Courier, monospace">q[2]</font>:$(branch(q)[2])");<br>
xlog("$var(loglevel)","In failure_route contact
branch q[3]:$(branch(q)[3])");</font></p>
<p><font face="Courier New, Courier, monospace"> t_relay();<br>
}<br>
</font>The log shows:</p>
<p> INFO: xlog:In failure_route contact branch index:7<br>
INFO: xlog:In failure_route contact branch q[0]:930<br>
INFO: xlog:In failure_route contact branch q[1]:940<br>
INFO: xlog:In failure_route contact branch q[2]:950<br>
INFO: xlog:In failure_route contact branch q[3]:960<br>
<br>
<br>
</p>
<p>Thanks in advance for any help.</p>
<p>Rich</p>
<p><br>
</p>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - March 5-7, 2018, Berlin - <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 14-16, 2018 - <a class="moz-txt-link-abbreviated" href="http://www.kamailioworld.com">www.kamailioworld.com</a></pre>
</body>
</html>