<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    I would say this an UA issue - OpenSIPS does not do any enforcing on
    the order of outgoing SIP packets, so if the UA sends an INVITE
    immediately followed by an UPDATE, there exists the risk of the
    UPDATE reaching the endpoint first ( even if the proxy would
    maintain the the packet order, since UDP is used as transport, there
    would still be no guarantee that the endpoint receives them in the
    same order ). <br>
    <br>
    Can you configure the UA to only send the UPDATE after the INVITE
    transaction has finished ? This would be the only way to ensure
    there are no races.<br>
    <br>
    Best Regards,<br>
    <pre class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer
</pre>
    <div class="moz-cite-prefix">On 22.10.2015 20:05, Patrick Wakano
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAPu3kNWeThqBKcVQV=t0GCv=GW-FJek1YDBN2a53shxe5yGAkA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hello Opensips list!
        <div><br>
        </div>
        <div>I already explained my scenario in this e-mail (<a
            moz-do-not-send="true"
href="http://lists.opensips.org/pipermail/users/2015-October/032859.html">http://lists.opensips.org/pipermail/users/2015-October/032859.html</a>)
          where the Ack was propagated with wrong CSeq number when using
          the in-dialog ping options. Vlad did a great job and already
          correct this bug! (<a moz-do-not-send="true"
            href="https://github.com/OpenSIPS/opensips/issues/680">https://github.com/OpenSIPS/opensips/issues/680</a>)</div>
        <div><br>
        </div>
        <div>Now in a scenario where I disabled the in-dialog ping, I
          faced another issue. I mentioned that sometimes, due to
          unknown reasons, when I received a Re-Invite immediately
          followed by an Update, the Update gets forwarded first. The
          problem is that, since CSeq numbers are not altered, when this
          inversion happens, my peer rejects the Re-Invite because its
          CSeq number is lower than the Update one.</div>
        <div>Probably Opensips has to respect the ordering of in-dialog
          requests and forward them accordingly, instead of handling
          them asynchronously and forwarding right away...</div>
        <div><br>
        </div>
        <div>Best regards,</div>
        <div>Patrick</div>
        <div><br>
        </div>
      </div>
      <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>