<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Maybe there is a parallel forking and one branch gets timed out (in
    this case 408 is selected against 486). How many INVITE requests do
    you see being sent out? Or you can eventually make the sip trace
    available for viewing on this mailing list or some web site/pastebin
    out there.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <div class="moz-cite-prefix">On 15/12/15 12:54, Alexandru Covalschi
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAD_iGr-QQjo2SM7Zit_t5vA=yufYSHLmtBobzN_+VqMVBym-Vw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>I use sngrep to track view the flow and I'm pretty sure
              it's accurate enough to tell me that. <br>
            </div>
            Here's relay route:<br>
            route[RELAY] {<br>
            <br>
                    # enable additional event routes for forwarded
            requests<br>
                    # - serial forking, RTP relaying handling, a.s.o.<br>
                    if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {<br>
                            if(!t_is_set("branch_route"))
            t_on_branch("MANAGE_BRANCH");<br>
                    }<br>
                    if (is_method("INVITE|SUBSCRIBE|UPDATE")) {<br>
                            if(!t_is_set("onreply_route"))
            t_on_reply("MANAGE_REPLY");<br>
                    }<br>
                    if (is_method("INVITE")) {<br>
                            if(!t_is_set("failure_route"))
            t_on_failure("MANAGE_FAILURE");<br>
                    }<br>
                    if (!t_relay()) {<br>
                            sl_reply_error();<br>
                    }<br>
                    exit;<br>
            }<br>
            <br>
          </div>
          and here's reply routes<br>
          <br>
          # Manage outgoing branches<br>
          branch_route[MANAGE_BRANCH] {<br>
                  xdbg("new branch [$T_branch_idx] to $ru\n");<br>
                  route(NATMANAGE);<br>
          }<br>
          <br>
          # Manage incoming replies<br>
          onreply_route[MANAGE_REPLY] {<br>
                  xdbg("incoming reply\n");<br>
                  if(status=~"[12][0-9][0-9]")<br>
                          route(NATMANAGE);<br>
          }<br>
          <br>
          # Manage failure routing cases<br>
          failure_route[MANAGE_FAILURE] {<br>
          <br>
          if (t_check_status("486")) {<br>
              exit;<br>
          }<br>
                  route(NATMANAGE);<br>
          <br>
                  if (t_is_canceled()) {<br>
                          exit;<br>
                  }<br>
          <br>
          }<br>
          <br>
          <br>
        </div>
        <div>However when endpoint replies with 486 BUSY I can't see
          that on FS, Kamailio just sends 408 REQ TERM after some amount
          of time<br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">2015-12-15 13:34 GMT+02:00 Alex
          Balashov <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div
              style="background-color:rgb(255,255,255);line-height:initial">
              <div
                style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">From
                what you describe, the reply should be going back to the
                sender. Are you absolutely sure that it's not? If so,
                are there any other actions you could be taking
                somewhere to drop it, such as in an onreply_route?</div>
              <div
                style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
              </div>
              <div
                style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">ACKs
                to negative final replies are hop-by-hop, so the ACK
                you're seeing directly from the proxy to the UAS is
                normal. <span
                  style="font-size:initial;line-height:initial;text-align:initial;font-family:Calibri,'Slate
                  Pro',sans-serif"></span></div>
              <div
                style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
              </div>
              <div style="font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">--<br>
                Alex Balashov | Principal | Evariste Systems LLC<br>
                303 Perimeter Center North, Suite 300<br>
                Atlanta, GA 30346<br>
                United States<br>
                <br>
                Tel: <a moz-do-not-send="true"
                  href="tel:%2B1-800-250-5920" value="+18002505920"
                  target="_blank">+1-800-250-5920</a> (toll-free) / <a
                  moz-do-not-send="true" href="tel:%2B1-678-954-0671"
                  value="+16789540671" target="_blank">+1-678-954-0671</a> (direct)<br>
                Web: <a moz-do-not-send="true"
                  href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a>, <a
                  moz-do-not-send="true"
                  href="http://www.csrpswitch.com/" target="_blank"><a class="moz-txt-link-freetext" href="http://www.csrpswitch.com/">http://www.csrpswitch.com/</a></a><br>
                <br>
                Sent from my BlackBerry.</div>
              <table style="background-color:white;border-spacing:0px"
                width="100%">
                <tbody>
                  <tr>
                    <td colspan="2"
style="font-size:initial;text-align:initial;background-color:rgb(255,255,255)">
                      <div style="border-style:solid none
                        none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt
                        0in 0in;font-family:Tahoma,'BB Alpha
                        Sans','Slate Pro';font-size:10pt">
                        <div><b>From: </b>Alexandru Covalschi</div>
                        <div><b>Sent: </b>Tuesday, December 15, 2015
                          05:03</div>
                        <div><b>To: </b>Kamailio (SER) - Users Mailing
                          List</div>
                        <div><b>Reply To: </b>Kamailio (SER) - Users
                          Mailing List</div>
                        <div><b>Subject: </b>[SR-Users] Relaying
                          failure codes back to initial server</div>
                      </div>
                    </td>
                  </tr>
                </tbody>
              </table>
              <div>
                <div class="h5"><br>
                  <div>
                    <div dir="ltr">Hello everyone!<br clear="all">
                      <div>I need to relay 486/408/... other failure
                        codes back to initial INVITE server. Here <a
                          moz-do-not-send="true"
href="http://lists.sip-router.org/pipermail/sr-users/2010-November/066382.html"
                          target="_blank"><a class="moz-txt-link-freetext" href="http://lists.sip-router.org/pipermail/sr-users/2010-November/066382.html">http://lists.sip-router.org/pipermail/sr-users/2010-November/066382.html</a></a>
                        is recommended just to exit failure_route, but
                        that didn't work for me. I need that to let
                        Freeswitch know which cause has ended the call.
                        Now Kamailio just sends ACK to endpoint on
                        receiving 486 BUSY. Would you kindly tell me how
                        to achieve that?<br>
                      </div>
                      <div>Thanks in advance<br>
                      </div>
                      <div>-- <br>
                        <div>
                          <div dir="ltr">Alexandru Covalschi<br>
                            ABRISS-Solutions
                            <div>VoIP engineer and system administrator<br>
                              phone: <a moz-do-not-send="true"
                                href="tel:%2B37367398493"
                                value="+37367398493" target="_blank">+37367398493</a><br>
                              web: <a moz-do-not-send="true"
                                href="http://abs-telecom.com/"
                                target="_blank">http://abs-telecom.com/</a></div>
                          </div>
                        </div>
                      </div>
                    </div>
                    <br>
                  </div>
                </div>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
            mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
              rel="noreferrer" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
            <br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        <div class="gmail_signature">
          <div dir="ltr">Alexandru Covalschi<br>
            ABRISS-Solutions
            <div>VoIP engineer and system administrator<br>
              phone: +37367398493<br>
              web: <a moz-do-not-send="true"
                href="http://abs-telecom.com/" target="_blank">http://abs-telecom.com/</a></div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.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-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Book: SIP Routing With Kamailio - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://miconda.eu">http://miconda.eu</a></pre>
  </body>
</html>