<html>

  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <div class="WordSection1">

      <p class="MsoNormal">Hello list,</p>

      <p class="MsoNormal">I have troubles with serial forking in

        kamailio 3.2.4, which is mixed with parallel forking. In the

        scenario that an initial INVITE message, which is addressed to

        <a href="sip:A" target="_blank">sip:A</a>, is coming in to the

        server, it is doing a lookup in the DB and forking (parallel)

        the request to e.g. 3 SIP user agents. I have set the timer to

        20 seconds transaction timeout and after that timeout, the

        server is handling the original request in the

        FAILURE_ROUTE[xy]. In this failure route, the request-URI

        username is overwritten to an alternative one – e.g.

        <a href="sip:B" target="_blank">sip:B</a>. Then the server is

        doing a DB lookup again and forking the request to the number of

        registered user agents.</p>

      <p class="MsoNormal">A specialiy of this scenario is that it can

        be possible, that user agents have registered for username “A”

        and username “B” – in other words: they are members of the

        parallel forking group in serial forking step 1 and step 2. When

        the CANCEL and INVITE message would be sent out (to the user

        agents) in the correct order, then it would be no problem. But

        in my case the server is sending the “new” INVITE message (2<sup>nd</sup>

        step in the serial forking procedure) to user agents BEFORE the

        CANCEL request. Therefore, these user agents are rejecting the

        INVITE message with “500”.<br>

        <br>

        Signalisation scenario<br>

        ==================<br>

      </p>

      <p class="MsoNormal">INVITE -> SRV<br>

        SRV -> INVITE (branch-1)  UA1<br>

        SRV -> INVITE (branch-2)  UA2<br>

        SRV -> INVITE (branch-3)  UA3<br>

        SRV <- 180 (branch-1)       UA1<br>

        SRV <- 180 (branch-2)       UA2<br>

        SRV <- 180 (branch-3)       UA3<br>

        .....  [timeout]<br>

        SRV -> CANCEL (branch-1) UA1<br>

        SRV -> CANCEL (branch-2) UA2<br>

        SRV -> INVITE (branch-4)   UA4<br>

        SRV -> INVITE (branch-5)   UA5<br>

        SRV -> INVITE (branch-6)   UA3    (!!!)<br>

        SRV -> CANCEL (branch-3) UA3<br>

        SRV <- 500 (branch-6)        UA3<br>

      </p>

      <p class="MsoNormal">It was quasi reproduceable that only the last

        branch of the initial transaction had that timing problem

        (INVITE <- vs -> CANCEL).<br>

        My question is:  why does the server send the (last) CANCEL

        message only after the INVITE message for some branch(es)? Could

        this behaviour be prohibited in any way?<br>

      </p>

      <p class="MsoNormal">Thanks in advance!</p>

      <p class="MsoNormal">Klaus</p>

    </div>

  </body>

</html>