<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 02/09/2020 19.30, Patrick Wakano
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPu3kNXc99tdRPo9mCjB-bWdKp-T+hM_iosefrqVOufvyercWw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Hello list,</div>
        <div>Hope you are all well.</div>
        <div><br>
        </div>
        Under some load test simulations I've been facing cases where
        the command Kamailio sends to RTPEngine times out with such
        message:<br>
        <div><span style="font-family:monospace">send_rtpp_command():
            timeout waiting reply for command "" from RTP proxy</span></div>
        <div>After checking RTPEngine logs, I can see the command was
          received and a reply was sent, so I am thinking the reply
          packet could have been lost somewhere in the network (they are
          in different servers). So my question is, how resilient is the
          RTPEngine NG protocol to handle packet loss situations? I saw
          TCP is not supported, so are there UDP retransmissions in
          place to guarantee packet delivery? Any ideas to make this
          connection more reliable?</div>
      </div>
    </blockquote>
    <p>The module automatically resends the command a number of times if
      no reply was received within the timeout period. The modparam
      `rtpengine_retr` is how many times a command is resent, and
      `rtpengine_tout_ms` is how long it waits (in ms) each time for a
      reply.</p>
    <p>If you don't get a reply even after multiple retries, you might
      have an underlying network issue. Most often this is due to broken
      IP fragmentation in the network.<br>
    </p>
    <p>We're currently working on adding HTTP and Websocket support to
      rtpengine, so this could be used in the future as control protocol
      from Kamailio instead of UDP, even though in a properly
      functioning network there's no reason why UDP shouldn't be as
      reliable as TCP.</p>
    <p>Cheers<br>
    </p>
  </body>
</html>