[sr-dev] Kamailio at SIPit 30
Peter Dunkley
peter.dunkley at crocodile-rcs.com
Wed Feb 20 17:49:28 CET 2013
On 20/02/13 16:28, Iñaki Baz Castillo wrote:
> 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?
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.
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.
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.
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.
At the moment we work-around this with our Javascript MSRP stack by
doing chunking there and:
1. Limiting the chunk size to something small
2. Limiting the number of outstanding chunks (that is chunks for which
we have not received a 200 response) for a particular file transfer
In effect, we have kludged our MSRP stack to have flow-control at a
level higher than just TCP.
Regards,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130220/cef61fb8/attachment.htm>
More information about the sr-dev
mailing list