<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    How did you grab the pcap? All the variants (including the zip via
    http download) are not recognized by ngrep or wireshark.<br>
    <br>
    Anyhow, I looked with a text editor inside the and I could see that
    the ACK is changing the r-uri -- it comes to kamailio with the
    contact from 200ok, but goes out with a different hostname. You have
    some rules in kamailio.cfg that do that -- you should let the r-uri
    unchanged for ack -- routing is done via record-routing.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <div class="moz-cite-prefix">On 29/08/14 16:12, Daniel-Constantin
      Mierla wrote:<br>
    </div>
    <blockquote cite="mid:54008A6A.4090505@gmail.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      The last .zip file is also showing only 3 packets (different ones)
      -- can you check the trace has all the packet before you compress?
      Maybe you can put it somewhere on a server for download and send
      me the link, so I get it over http.<br>
      <br>
      Cheers,<br>
      Daniel<br>
      <br>
      <div class="moz-cite-prefix">On 29/08/14 09:36, Daniel-Constantin
        Mierla wrote:<br>
      </div>
      <blockquote cite="mid:54002D94.7010803@gmail.com" type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        I don't mind to receive directly attachments that can contain
        sensitive data. But you have to write an email via mailing list
        saying you do/did so.<br>
        <br>
        With gmail I am checking mostly the emails that are filtered
        with various rules, otherwise, the rest land together with a lot
        of spam/advertising and check them very rarely, if ever.<br>
        <br>
        So, as a reminder to anyone that did it -- if a conversation
        from mailing list was turned into a direct email to me only, it
        very unlikely to get answered soon, given the load I have --
        better resend to mailing list.<br>
        <br>
        I had no time to look yet at the trace.<br>
        <br>
        Cheers,<br>
        Daniel<br>
        <br>
        <div class="moz-cite-prefix">On 29/08/14 07:08, Yuriy
          Gorlichenko wrote:<br>
        </div>
        <blockquote
cite="mid:CABSP_VfUKhCS9H8SaT6ogF4cTDcuwDfp2ZoqKRA6jzJS_gji8A@mail.gmail.com"
          type="cite">
          <div dir="ltr">My pcap file. Daniel sorry for first time
            sended message to your private mail. Was a mistake.  </div>
          <div class="gmail_extra"><br>
            <br>
            <div class="gmail_quote">2014-08-28 17:27 GMT+04:00
              Daniel-Constantin Mierla <span dir="ltr"><<a
                  moz-do-not-send="true" href="mailto:miconda@gmail.com"
                  target="_blank">miconda@gmail.com</a>></span>:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div bgcolor="#FFFFFF" text="#000000">
                  <div class=""> <br>
                    <div>On 28/08/14 15:11, Olle E. Johansson wrote:<br>
                    </div>
                    <blockquote type="cite"> <br>
                      <div>
                        <div>On 28 Aug 2014, at 14:57, Daniel-Constantin
                          Mierla <<a moz-do-not-send="true"
                            href="mailto:miconda@gmail.com"
                            target="_blank">miconda@gmail.com</a>>
                          wrote:</div>
                        <br>
                        <blockquote type="cite">
                          <div bgcolor="#FFFFFF" text="#000000"> <br>
                            <div>On 28/08/14 14:45, Olle E. Johansson
                              wrote:<br>
                            </div>
                            <blockquote type="cite"> <br>
                              <div>
                                <div>On 28 Aug 2014, at 14:14, Yuriy
                                  Gorlichenko <<a
                                    moz-do-not-send="true"
                                    href="mailto:ovoshlook@gmail.com"
                                    target="_blank">ovoshlook@gmail.com</a>>




                                  wrote:</div>
                                <br>
                                <blockquote type="cite">
                                  <div dir="ltr">Hello. I try to provide
                                    call scheme:<br>
                                    <br>
                                    internal client  -> asterisk
                                    -> Kamailio -> provider ->
                                    external endpoint call<br>
                                    <br>
                                    when I make call I see this:<br>
                                    <br>
                                    asterisk     kamailio   provider<br>
                                    invite -->       invite -->   <br>
                                                                   
                                    <--     407<br>
                                                           ACK   -->
                                       <br>
                                                           invite w/Auth
                                    --><br>
                                                  <--    100  <--
                                       100<br>
                                                  <--    180  <--
                                       180
                                    <div>              <--    183
                                       <--    183</div>
                                    <div>               <--    200
                                       <--      200</div>
                                    <div>   ACK  -->   ACK  --></div>
                                    <div><br>
                                      My problem with last ACK, that I
                                      send to provider. Provider ignores
                                      it, and sends me some OK packets.
                                      As resultI can notend session (
                                      answer to BYE 481 - transaction
                                      does not exists). I think it is
                                      wrong ACK but can not undrtand
                                      where I do mistake.<br>
                                    </div>
                                  </div>
                                </blockquote>
                                Well, by letting the proxy handle
                                authentication the INVITE tranction i
                                closed without Asterisk knowing about
                                it. So the ACK sent from the proxy and
                                from Asterisk is for the same
                                transaction, which messes things up.
                                Asterisk does not know anything about
                                the second invite. Letting the proxy
                                handle authentiction breaks the SIP
                                protocol in bad ways and is generally
                                not a good solution.</div>
                              <div>You may want to send another response
                                to asterisk when you get the 407 so
                                Asterisk retries and use the retry as a
                                trigger for the second INVITE and add
                                auth to that.</div>
                            </blockquote>
                            While breaking the cseq incrementation for
                            authentication (mentioned in the readme of
                            uac), the Asterisk seems to do ok here,
                            because the ACK is coming from asterisk, but
                            it is not accepted by the provider.<br>
                          </div>
                        </blockquote>
                        You are missing the fact that the ACK sent by
                        Asterisk is already sent by the proxy. The
                        INVITE w/AUth have a different cseq than the
                        ACK. <br>
                      </div>
                    </blockquote>
                  </div>
                  Kamailio is doing serial forking in this case, so the
                  first ack is for the first branch that gets 407. This
                  should be as usual for serial/parallel forking.<br>
                  <br>
                  Then, Kamailio is not increasing the cseq here --
                  that's the limitation with uac auth module, because
                  the authenticator should normally reject it. But if it
                  is authentication against another kamailio, should
                  just work.
                  <div class=""><br>
                    <br>
                    <blockquote type="cite">
                      <div>
                        <blockquote type="cite">
                          <div bgcolor="#FFFFFF" text="#000000"> <br>
                            The provider (having a plivo platform, based
                            on the responses) is running kamailio 4.1.2
                            in front (looking at 100 trying).<br>
                            <br>
                            Authentication from kamailio to another
                            kamailio using uac module should work fine,
                            as kamailio doesn't act as end user UAC and
                            doesn't care much of cseq.<br>
                          </div>
                        </blockquote>
                        Won't the second ACK on the same transaction
                        just be ignored, while it waits for an ACK on
                        the new transaction?<br>
                      </div>
                    </blockquote>
                  </div>
                  It is the same transaction in this case, just two
                  branches from kamailio downstream, which is serial
                  forking case, as mentioned above.
                  <div class=""><br>
                    <br>
                    Cheers,<br>
                    Daniel<br>
                    <br>
                    <pre cols="72">-- 
Daniel-Constantin Mierla
<a moz-do-not-send="true" href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a moz-do-not-send="true" href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
                  </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"
                  target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
                <br>
              </blockquote>
            </div>
            <br>
          </div>
        </blockquote>
        <br>
        <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla
<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>
Next Kamailio Advanced Trainings 2014 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla
<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>
Next Kamailio Advanced Trainings 2014 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</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>
Next Kamailio Advanced Trainings 2014 - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
  </body>
</html>