<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks Daniel,<div class=""><br class=""></div><div class="">I found that very method 20min ago from examining the source of handle_ruri_alias.</div><div class=""><br class=""></div><div class="">It works… your advice is spot on as usual.</div><div class=""><br class=""></div><div class="">Thanks for your help,</div><div class="">Dave Wilson</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 1 May 2017, at 8:26 pm, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com" class="">miconda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class="">Hello,</p><p class="">failure route is preserving the attributing of the branch that
received the failure reply.</p><p class="">You have to use resetdsturi() in this case -- see the readme of
kex module.</p><p class="">Cheers,<br class="">
Daniel<br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 01.05.17 12:58, David Wilson wrote:<br class="">
</div>
<blockquote cite="mid:47C8CCF1-8ACB-4688-85BA-307BE6A945F5@zaq.com.au" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
Hello All,
<div class=""><br class="">
</div>
<div class="">We use registrar servers (call them A,B) for TLS
connections from clients and a central routing proxy (P) that
authenticates and manages all call routing.</div>
<div class=""><br class="">
</div>
<div class="">On INVITE, P uses lookup(“location”) and
handle_uri_alias() to route the INVITE to A or B depending on
the AOR from REGISTER.</div>
<div class=""><br class="">
</div>
<div class="">In failure_route I’m trying to send INVITE to a
voicemail URI at host (V), using alias_db_lookup to retrieve it
and sending with t_relay(). However, despite showing V as the
host in the URI, the message is sent to A (or B) as if the
handle_uri_alias is still in effect.</div>
<div class=""><br class="">
</div>
<div class="">I’ve tried calling revert_uri() before the
alias_db_lookup(), but this doesn’t seem to help. Is there a
way to reset the uri_alias?</div>
<div class=""><br class="">
</div>
<div class="">The failure_route (simplified) looks like this:</div>
<div class="">
<div class=""><font class="" face="Courier">failure_route[1] {</font></div>
<div class=""><font class="" face="Courier"> if (method
== "INVITE") {</font></div>
<div class=""><span style="font-family: Courier;" class="">
revert_uri(); </span></div>
<div class=""><span style="font-family: Courier;" class="">
if (alias_db_lookup("dbaliases")) {</span></div>
<div class=""><span style="font-family: Courier;" class="">
t_relay();</span></div>
<div class=""><font class="" face="Courier"> }</font></div>
<div class=""><span style="font-family: Courier;" class="">
}</span></div>
<div class=""><font class="" face="Courier">}</font></div>
</div>
<div class=""><br class="">
</div>
<div class="">I have also tried using t_relay(“$rd”, “$rp”) after
confirming (by logging) that the uri contains the desired
values, but kamailio failed to start, with this error logged:</div>
<div class=""><font class="" face="Courier"><span class="Apple-tab-span" style="white-space:pre"> </span>ERROR:
tm [tm.c:672]: fixup_hostport2proxy(): TM
module:fixup_hostport2proxy: bad port number <$rp></font></div>
<div class=""><br class="">
</div>
<div class="">Any suggestions?</div>
<div class=""><br class="">
</div>
<div class="">Best regards,</div>
<div class="">Dave.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
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 class="">
<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 - May 22-24 (USA) - <a class="moz-txt-link-abbreviated" href="http://www.asipto.com/">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a class="moz-txt-link-abbreviated" href="http://www.kamailioworld.com/">www.kamailioworld.com</a></pre>
</div>
_______________________________________________<br class="">Kamailio (SER) - Users Mailing List<br class=""><a href="mailto:sr-users@lists.kamailio.org" class="">sr-users@lists.kamailio.org</a><br class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users<br class=""></div></blockquote></div><br class=""></div></body></html>