
<html>

  <head>

    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

  </head>

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

    <br>

    <div class="moz-cite-prefix">On 20/02/13 16:28, Iñaki Baz Castillo

      wrote:<br>

    </div>

    <blockquote

cite="mid:CALiegfk=bCQz0nn01Jy+4ONCiJAXZ8VACb-NMFS6E9fZyQPb-g@mail.gmail.com"

      type="cite">Let me a question: does not the TCP buffer size affect

      to the WS

      module? This is, if I send via SIP over WS or MSRP over MSRP a

      very

      big WebSocket messsage (i.e. an ISO image) does it not deal with

      Kamailio's TCP buffer settings?<br>

    </blockquote>

    <br>

    Kamailio has fixed size TCP receive buffers.  The size can be set in

    the configuration file and changed live (using an MI command), but

    has to be manually set.  If you want to receive any request (SIP,

    HTTP, or MSRP) on Kamailio that exceeds the buffer size that is

    currently in use you will have problems.<br>

    <br>

    It is currently the case that receiving large HTTP (for example, for

    XCAP), SIP, and MSRP messages requires this buffer to be increased

    from the default.  WebSocket is no different at all, and the problem

    is no different here than it is for anything else in Kamailio.<br>

    <br>

    The reason it is noticed more with WebSockets is that SIP over

    WebSocket tends to be using WebRTC generated SDP - which is quite a

    bit larger than that produced by most clients.<br>

    <br>

    I plan to modify the TCP receive code and MSRP module so that when

    large MSRP SEND requests (for example, a single SEND containing an

    ISO image) are received Kamailio will chunk them into smaller

    outgoing SENDs at a size that is less than the TCP receive buffer

    size.  This chunking by a relay is permitted by RFC4576.  I haven't

    gotten around to this yet, but even when done it won't help with

    large SIP or HTTP requests.<br>

    <br>

    At the moment we work-around this with our Javascript MSRP stack by

    doing chunking there and:<br>

    <ol>

      <li>Limiting the chunk size to something small</li>

      <li>Limiting the number of outstanding chunks (that is chunks for

        which we have not received a 200 response) for a particular file

        transfer<br>

      </li>

    </ol>

    In effect, we have kludged our MSRP stack to have flow-control at a

    level higher than just TCP.<br>

    <br>

    Regards,<br>

    <br>

    Peter<br>

    <br>

  </body>

</html>