<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    Think a SIP trace would help a lot in debugging this situation - my
    guess is that there is sort of a "race" between the RE-INVITE being
    sent out, and in-dialog options pings ( eg. Re-INVITE goes out, then
    OpenSIPS sends in-dialog OPTION pings, then the ACK comes in and
    it's CSEQ is wrongly increased ).<br>
    <br>
    Can you please provide a SIP trace for your scenario ?<br>
    <br>
    Best Regards,<br>
    <pre class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer
</pre>
    <div class="moz-cite-prefix">On 21.10.2015 12:32, Vlad Paiu wrote:<br>
    </div>
    <blockquote cite="mid:56275BA2.5070802@opensips.org" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      Hello,<br>
      <br>
      Yes, if you are using in-dialog OPTIONS pings, OpenSIPS will
      mangle the CSEQs of all in-dialog requests, after it has sent the
      first pings.<br>
      <br>
      Just making sure I understand the scenario... so the client is
      sending a Re-INVITE and immediately after that it sends an UPDATE,
      and the ACK for the RE-INVITE gets propagated with the CSEQ of the
      UPDATE ? <br>
      <br>
      Best Regards,<br>
      <pre class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer
</pre>
      <div class="moz-cite-prefix">On 20.10.2015 21:28, Patrick Wakano
        wrote:<br>
      </div>
      <blockquote
cite="mid:CAPu3kNWUnMUB2VOp8vMaTom8Ua__osRT2cv1sPChBnzCZU81Xg@mail.gmail.com"
        type="cite">
        <div dir="ltr">Hi list,
          <div>An update about this issue.</div>
          <div>The behavior I mentioned about Opensips incrementing the
            CSeq values only after second Re-Invite is incorrect. More
            tests showed me that this happens after the in-dialog
            Options the dialog module sends (I am creating it with "pP"
            options). This also explains why Opensips is changing the
            CSeq number, because it has to couple the CSeq numbering of
            the local generated Options with the original requests of
            the dialog!<br>
          </div>
          <div>The problem regarding the Ack with wrong CSeq number
            still occurs anyways. It seems that Opensips is not matching
            the Ack with the correct Invite transaction...</div>
          <div><br>
          </div>
          <div>Patrick</div>
          <div><br>
          </div>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Tue, Oct 20, 2015 at 12:31 PM,
            Patrick Wakano <span dir="ltr">&lt;<a
                moz-do-not-send="true" href="mailto:pwakano@gmail.com"
                target="_blank">pwakano@gmail.com</a>&gt;</span> wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">Hello Opensips list!
                <div><br>
                </div>
                <div>Hope you all doing fine!</div>
                <div><br>
                </div>
                <div>The purpose of this e-mail is to explain a problem
                  I am facing and to understand a little bit more about
                  the handling done by Opensips over the CSeq number
                  when forwarding messages to the destination. I
                  couldn't find any real good explanation over this
                  subject so I wrote this huge e-mail, sorry for that...</div>
                <div><br>
                </div>
                <div>I am trying to use the remote ID feature of
                  Asterisk, but in some transfer scenarios the call gets
                  dropped and after digging the problem I think it is
                  related to the CSeq handling done by Opensips.</div>
                <div>This remote ID feature is configured to use the
                  P-Asserted-Identity header to transmit the callee ID
                  to the caller and it causes the exchange of Re-Invites
                  and/or Updates during the call. The transfer scenario
                  I mentioned is entirely handled by Asterisk, and as a
                  result of the transfer it sends to Opensips the
                  identity of the new peer, using a Re-Invite and an
                  Update.</div>
                <div>First I would like to know how Opensips handles the
                  CSeq number when proxying the Invite from one side to
                  the other? My tests showed me that Opensips does not
                  change the CSeq for the first Invite and first
                  Re-invite, however for the second Re-invite and for
                  requests after that it is always incrementing the
                  value by one when forwarding it. Although it haven't
                  caused any errors so far, I am not sure if this is
                  correct. Why is Opensips incrementing it? My
                  understanding is that the proxy was not supposed to
                  change this field...</div>
                <div><br>
                </div>
                <div>Now the problem I am facing: In a blind transfer
                  scenario, the remote ID feature causes Asterisk to
                  send a Re-Invite and right after an Update. Opensips
                  increments the CSeq of both(because this happens to be
                  the second Re-Invite of the dialog) and forward them
                  to the destination. Both messages are answered with
                  200 Ok. This follows by Asterisk sending an Ack with
                  the same CSeq number used in the Re-Invite. This is
                  the point where Opensips fails, it gets this Ack and
                  forward it using the CSeq number of the Update and not
                  the one of the Re-Invite. Because of this the
                  destination discards this Ack and keeps retransmitting
                  the 200 Ok for the Re-Invite, eventually the call is
                  dropped by timeout or because some other Re-Invite
                  happens without the prior one being properly handled.</div>
                <div><br>
                </div>
                <div>Useful information:</div>
                <div>- If the Re-Invite followed by the Update is the
                  first of the dialog, then the problem does not happen.
                  The CSeq numbers are not incremented and the CSeq for
                  the Ack is correct.</div>
                <div>- If due to unknown timing reasons, the Update gets
                  forwarded before the Re-Invite (even though the
                  Re-Invite is received first) the problem also does not
                  happen. The CSeq numbers are incremented but the CSeq
                  for the Ack gets the correct value. So it seems to me
                  that the Ack is getting the last CSeq used to forward,
                  and not the one of the corresponding Invite.</div>
                <div>- When I enable more traces(debug=4), I always fall
                  in the case where the Update is forwarded before the
                  Re-Invite and then the problem doesn't happen.</div>
                <div>- In an attended transfer, Asterisk does not send
                  the Update so the problem does not happen.<br>
                </div>
                <div>- Not sure why Asterisk is sending the Re-Invite
                  immediately followed by an Update, nevertheless
                  technically I couldn't see a problem with it.</div>
                <div>- I am using Opensips 1.11.3</div>
                <div><br>
                </div>
                <div><br>
                </div>
                <div>Best regards for all and sorry again for such a
                  huge e-mail.</div>
                <span class="HOEnZb"><font color="#888888">
                    <div><br>
                    </div>
                    <div>Patrick</div>
                  </font></span></div>
            </blockquote>
          </div>
          <br>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>