<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    can you apply attached patch to the rtpproxy module and send again
    the log messages from kamailio? No need for siptrace, I just want to
    see if the to tag is detected properly and the number of paramters
    for rtpproxy command from kamailio point of view.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <div class="moz-cite-prefix">On 9/6/12 8:44 AM, Spencer Thomason
      wrote:<br>
    </div>
    <blockquote
      cite="mid:FDCFBF61-1496-4BA1-A994-303B099F6377@5ninesolutions.com"
      type="cite">Hi Daniel,
      <div><br>
      </div>
      <div>I collected logs and a trace exhibiting this behavior.</div>
      <div><br>
      </div>
      <div>The logs are here:</div>
      <div><a moz-do-not-send="true" href="http://pastebin.com/1rQwLmx9">http://pastebin.com/1rQwLmx9</a></div>
      <div><br>
      </div>
      <div>The trace is here:</div>
      <div><a moz-do-not-send="true" href="http://pastebin.com/sXVL69tD">http://pastebin.com/sXVL69tD</a></div>
      <div><br>
      </div>
      <div>Thanks,</div>
      <div>Spencer</div>
      <div><br>
      </div>
      <div><br>
        <div>
          <div>On Aug 31, 2012, at 1:33 PM, Daniel-Constantin Mierla
            wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <meta content="text/html; charset=windows-1252"
              http-equiv="Content-Type">
            <div bgcolor="#FFFFFF" text="#000000"> Hello,<br>
              <br>
              the command to rtpproxy for the reply seem to miss the
              to-tag, can you grab the ngrep trace for such call and the
              logs for processing it? Having the logs from a different
              call than the ngrep trace you posted on pastebin is not
              helping much.<br>
              <br>
              Cheers,<br>
              Daniel<br>
              <br>
              <br>
              <div class="moz-cite-prefix">On 8/31/12 6:49 PM, Spencer
                Thomason wrote:<br>
              </div>
              <blockquote
                cite="mid:76e2de03d32bc5ec4e07e04bfebb4bdf@mail.5ninesolutions.com"
                type="cite">
                <p>Yes,</p>
                <p>The request (re-INVITE):</p>
                <p>Aug 30 22:38:59 sip /usr/sbin/kamailio[25778]: ERROR:
                  *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=471
                  a=25 n=rtpproxy_manage<br>
                  Aug 30 22:38:59 sip rtpproxy[25671]:
                  DBUG:handle_command: received command "25778_11 U <a
                    moz-do-not-send="true"
                    class="moz-txt-link-abbreviated"
                    href="mailto:1952045641-6076-15@BA.FJ.B.CFC">1952045641-6076-15@BA.FJ.B.CFC</a>
                  184.170.249.3 32122 3ae1Dvgr5vmeg;1 199857477;1"<br>
                  Aug 30 22:38:59 sip rtpproxy[25671]:
                  INFO:handle_command: adding strong flag to existing
                  session, new=1/0/0<br>
                  Aug 30 22:38:59 sip rtpproxy[25671]:
                  INFO:handle_command: lookup on ports 55324/46010,
                  session timer restarted<br>
                  Aug 30 22:38:59 sip rtpproxy[25671]: DBUG:doreply:
                  sending reply "25778_11 46010 184.170.249.8#012"</p>
                <div> <br class="webkit-block-placeholder">
                </div>
                <p>The reply:</p>
                <p>Aug 30 22:38:59 sip /usr/sbin/kamailio[25778]: ERROR:
                  *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=471
                  a=25 n=rtpproxy_manage<br>
                  Aug 30 22:38:59 sip rtpproxy[25671]:
                  DBUG:handle_command: received command "25778_12 L <a
                    moz-do-not-send="true"
                    class="moz-txt-link-abbreviated"
                    href="mailto:1952045641-6076-15@BA.FJ.B.CFC">1952045641-6076-15@BA.FJ.B.CFC</a>
                  71.104.248.48 6016 3ae1Dvgr5vmeg;1"<br>
                  Aug 30 22:38:59 sip rtpproxy[25671]:
                  INFO:handle_command: lookup request failed: session <a
                    moz-do-not-send="true"
                    class="moz-txt-link-abbreviated"
                    href="mailto:1952045641-6076-15@BA.FJ.B.CFC">1952045641-6076-15@BA.FJ.B.CFC</a>,
                  tags 3ae1Dvgr5vmeg;1/NONE not found<br>
                  Aug 30 22:38:59 sip rtpproxy[25671]: DBUG:doreply:
                  sending reply "25778_12 0 184.170.249.8#012"<br>
                  Aug 30 22:38:59 sip /usr/sbin/kamailio[25778]: ERROR:
                  rtpproxy [rtpproxy.c:2260]: incorrect port 0 in reply
                  from rtp proxy</p>
                <div> <br class="webkit-block-placeholder">
                </div>
                <p>I was able to get it working correctly by reworking
                  the config like the 3.1 branch by using rtpproxy_offer
                  instead of force_rtp_proxy.  When I attempted to use
                  rtpproxy_answer in the reply route, I was getting the
                  same lookup request failed error from rtpproxy.  In
                  the request and reply, the tags change.  Could this be
                  the reason that the session lookup is failing?  If I
                  use rtpproxy_offer in both the request and reply,
                  everything works correctly.  Is there any consequence
                  to doing this?</p>
                <p>Thanks,</p>
                <p>Spencer</p>
                <div> <br class="webkit-block-placeholder">
                </div>
                <div> <br class="webkit-block-placeholder">
                </div>
                <p>On 31.08.2012 01:53, Daniel-Constantin Mierla wrote:</p>
                <blockquote type="cite" style="padding-left:5px;
                  border-left:#1010ff 2px solid; margin-left:5px;
                  width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
                  <pre>Hello,

On 8/31/12 3:41 AM, Spencer Thomason wrote:</pre>
                  <blockquote type="cite" style="padding-left:5px;
                    border-left:#1010ff 2px solid; margin-left:5px;
                    width:100%">Hi Daniel, I can confirm that
                    rtpproxy_manage is called. See: <a
                      moz-do-not-send="true"
                      href="http://pastebin.com/ZVXjK9ry">http://pastebin.com/ZVXjK9ry</a>
                    I'm seeing ERROR: rtpproxy [rtpproxy.c:2260]:
                    incorrect port 0 in reply from rtp proxy in the logs
                    when processing the 200OK in the re-INVITE. I've
                    included a debug level log from rtpproxy in the log
                    as well.</blockquote>
                  <pre>this can happen because the rtpproxy was not engaged for the request, 
but only for the reply.

As you say, the logs are for the 200OK, what about the ones for request, 
is rtpproxy called there?

Cheers,
Daniel</pre>
                  <blockquote type="cite" style="padding-left:5px;
                    border-left:#1010ff 2px solid; margin-left:5px;
                    width:100%">When handling the re-INVITE there is: •
                    Aug 30 22:38:59 sip /usr/sbin/kamailio[25778]:
                    ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg]
                    l=471 a=25 n=rtpproxy_manage • Aug 30 22:38:59 sip
                    rtpproxy[25671]: DBUG:handle_command: received
                    command "25778_11 U <a moz-do-not-send="true"
                      href="mailto:1952045641-6076-15@BA.FJ.B.CFC">1952045641-6076-15@BA.FJ.B.CFC</a>
                    184.170.249.3 32122 3ae1Dvgr5vmeg;1 199857477;1" •
                    Aug 30 22:38:59 sip rtpproxy[25671]:
                    INFO:handle_command: adding strong flag to existing
                    session, new=1/0/0 • Aug 30 22:38:59 sip
                    rtpproxy[25671]: INFO:handle_command: lookup on
                    ports 55324/46010, session timer restarted • Aug 30
                    22:38:59 sip rtpproxy[25671]: DBUG:doreply: sending
                    reply "25778_11 46010 184.170.249.8#012" but the
                    200OK: • Aug 30 22:38:59 sip
                    /usr/sbin/kamailio[25778]: ERROR: *** cfgtrace:
                    c=[/etc/kamailio/kamailio.cfg] l=471 a=25
                    n=rtpproxy_manage • Aug 30 22:38:59 sip
                    rtpproxy[25671]: DBUG:handle_command: received
                    command "25778_12 L <a moz-do-not-send="true"
                      href="mailto:1952045641-6076-15@BA.FJ.B.CFC">1952045641-6076-15@BA.FJ.B.CFC</a>
                    71.104.248.48 6016 3ae1Dvgr5vmeg;1" • Aug 30
                    22:38:59 sip rtpproxy[25671]: INFO:handle_command:
                    lookup request failed: session <a
                      moz-do-not-send="true"
                      href="mailto:1952045641-6076-15@BA.FJ.B.CFC">1952045641-6076-15@BA.FJ.B.CFC</a>,
                    tags 3ae1Dvgr5vmeg;1/NONE not found • Aug 30
                    22:38:59 sip rtpproxy[25671]: DBUG:doreply: sending
                    reply "25778_12 0 184.170.249.8#012" • Aug 30
                    22:38:59 sip /usr/sbin/kamailio[25778]: ERROR:
                    rtpproxy [rtpproxy.c:2260]: incorrect port 0 in
                    reply from rtp proxy I'm not familiar with the
                    rtpproxy commands to know why it cannot locate the
                    session. Thanks for your assistance, Spencer On Aug
                    30, 2012, at 11:59 AM, Daniel-Constantin Mierla
                    wrote:
                    <blockquote type="cite" style="padding-left:5px;
                      border-left:#1010ff 2px solid; margin-left:5px;
                      width:100%">Hello, I could not spot by quick eye
                      checking what could happen there, the best is to
                      use the debugger module with cfg_trace parameter
                      set and check the execution trace to see what
                      actions of the configuration file are executed and
                      be sure the rtpproxy is called or not. You can
                      post the execution trace here if you need further
                      help with it. Cheers, Daniel On 8/30/12 7:40 PM,
                      Spencer Thomason wrote:
                      <blockquote type="cite" style="padding-left:5px;
                        border-left:#1010ff 2px solid; margin-left:5px;
                        width:100%">Hi Daniel, Thanks for your help with
                        this. Here is a trace: <a
                          moz-do-not-send="true"
                          href="http://pastebin.com/pXeFbwBz">http://pastebin.com/pXeFbwBz</a>
                        I see the nat=yes parameter added to the Route
                        header. I've posted the script here: <a
                          moz-do-not-send="true"
                          href="http://pastebin.com/2qwHYHvj">http://pastebin.com/2qwHYHvj</a>Forgive

                        my ignorance, I can't tell what I'm doing wrong.
                        Thanks! Spencer On Aug 30, 2012, at 12:51 AM,
                        Daniel-Constantin Mierla wrote:
                        <blockquote type="cite" style="padding-left:5px;
                          border-left:#1010ff 2px solid;
                          margin-left:5px; width:100%">Hello, if your
                          config it is based on the default one, the
                          Route header for within dialog requests is
                          marked by a parameter, nat=yes, that is used
                          to decide whether to do rtpproxy or not. So,
                          if you have a custom config, check the default
                          one for the nat traversal handling part.
                          Cheers, Daniel On 8/30/12 12:39 AM, Spencer
                          Thomason wrote:
                          <blockquote type="cite"
                            style="padding-left:5px; border-left:#1010ff
                            2px solid; margin-left:5px; width:100%">Hello,
                            I'm using Kamailio 3.2.4 for NAT traversal
                            using rtpproxy_manage() in a largely stock
                            script. Everything works great until the far
                            end (on a public ip) sends a t.38 re-INVITE.
                            The 200OK from the NATed UAC then doesn't
                            trigger rtpproxy and the private IP in the
                            sdp causes the fax to fail. Any help
                            handling these re-INVITEs would be greatly
                            appreciated. I'm happy to post traces if
                            that helps describe the situation. The
                            network topology looks like this: NATed UAC
                            -&gt; Kamailio on a public IP -&gt; UAS on a
                            public IP Thanks in advance, Spencer
                            Connected by DROID on Verizon Wireless
                            _______________________________________________
                            SIP Express Router (SER) and Kamailio
                            (OpenSER) - sr-users mailing list <a
                              moz-do-not-send="true"
                              href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
                            <a moz-do-not-send="true"
                              href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a></blockquote>
                          -- Daniel-Constantin Mierla - <a
                            moz-do-not-send="true"
                            href="http://www.asipto.com/">http://www.asipto.com</a>
                          <a moz-do-not-send="true"
                            href="http://twitter.com/#">http://twitter.com/#</a>!/miconda

                          - <a moz-do-not-send="true"
                            href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
                          Kamailio Advanced Training, Berlin, Nov 5-8,
                          2012 - <a moz-do-not-send="true"
                            href="http://asipto.com/u/kat">http://asipto.com/u/kat</a></blockquote>
                      </blockquote>
                      -- Daniel-Constantin Mierla - <a
                        moz-do-not-send="true"
                        href="http://www.asipto.com/">http://www.asipto.com</a>
                      <a moz-do-not-send="true"
                        href="http://twitter.com/#">http://twitter.com/#</a>!/miconda

                      - <a moz-do-not-send="true"
                        href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
                      Kamailio Advanced Training, Berlin, Nov 5-8, 2012
                      - <a moz-do-not-send="true"
                        href="http://asipto.com/u/kat">http://asipto.com/u/kat</a></blockquote>
                    _______________________________________________ SIP
                    Express Router (SER) and Kamailio (OpenSER) -
                    sr-users mailing list <a moz-do-not-send="true"
                      href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
                    <a moz-do-not-send="true"
                      href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a></blockquote>
                </blockquote>
              </blockquote>
              <br>
              <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com/">http://www.asipto.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a></pre>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<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>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a></pre>
  </body>
</html>