<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello again,</p>
    <p>Thank you for your answer. I guess the only chance I have is
      upgrading the builds from bottom to top progressively (4.5.4
      --> 5.x --> 6.x --> 7.x --> 8.5), since databases from
      such diferent versions are not compatible (I mean backing up from
      4.5.4 and restoring on a brand new 8.5). Is there any feasible way
      I could do this other than what I suggested?</p>
    <p>Thank you very much.</p>
    <div class="moz-cite-prefix">El 11/09/2020 a las 15:09, Alex Lutay
      escribió:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0ffa3193-1051-2ff1-5b9a-f21842f20478@sipwise.com">
      <pre class="moz-quote-pre" wrap="">Hi David,

It is a hard to say something from this side without logs,
debug and environment to reproduce the issue.

On the first looks it is a Sems issue. The CE release mr4.5.4
is based on GPL sems 1.6. As the next step I  would recommend
you to fire the latest mr8.5 LTS VM and repeat your tests
there. With a good chance your issue can be addressed there
already. The release mr4.5.4 is 3+ years old.

As the last resort your can contact Sipwise sales@ and repeat
your test with PRO based system, which is based on commercial
Sems 2.3 with a LOT of different fixes we cannot publish due to the
license limitation.

Sure you are always welcome for pull request to GPL sems 1.6:
<a class="moz-txt-link-freetext" href="https://github.com/sipwise/sems">https://github.com/sipwise/sems</a>

Have a nice day!

On 9/10/20 11:32 AM, David Pareja | Ingeniero de Red - Telmi Telecom wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Hello,

I am using SPCE mr4.5.4 and I have the following problem: When receiving
a call from the PSTN and then performing a call forward to the PSTN
again, if there is Early ACM involved (RFC 3398 Sec. 7.2.5) in the call
(and therefore the SPCE reveives an 183 Session Progress from the peer
before the 200 OK to the INVITE), the SPCE responds with a PRACK and
after that it doesn't respond to the 200 OK corresponding to the INVITE.
The call is stablished and RTP starts flowing, but the peer keeps
sending the 200 OK since we didn't respond with the corresponding ACK,
and after a while (about 20 seconds) it does timeout and the call drops.

When the the call is originated from a subscriber (instead of the PSTN)
the call forward is performed correctly. Looking at the traces it's like
the SPCE ignores the 183 and just waits until it receives the 200 OK
corresponding to the INVITE. In this case, it does respond with the
usual ACK and the call doesn't drop.

I don't know if there's a known issue regarding this specific aspect of
the Early ACM with call forwards from and to the PSTN. I already deeply
searched in the documentation, the internet and the files within the
SPCE, so I ran out of options. I would greatly appreciate any feedback
regarding this topic.

Thank you very much.

</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
    </blockquote>
    <div class="moz-signature">-- <br>
      <img src="cid:part1.270FA01D.193E07C0@telmi.es" border="0"></div>
  </body>
</html>