[sr-dev] Kamailio at SIPit 30

[Iñaki Baz Castillo]

2013/2/20 Peter Dunkley <peter.dunkley at crocodile-rcs.com>:
> 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.

Ok, so maybe this the yesterday "issue"? Note that SDP being sent by
JsSIP contains both audio and video along with ICE stuff... so yes, it
becomes really higher than "legacy" SDPs :)



> 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.

Yeah, good point.


> I haven't gotten around to this yet, but even when
> done it won't help with large SIP or HTTP requests.

And it shouldn't. If somebody uses SIP for sending a big file within
the SIP message body... that's his problem ;)



> In effect, we have kludged our MSRP stack to have flow-control at a level
> higher than just TCP.

As a side note, I'm waiting for WebRTC WG to advance in the data
channel spec. If the data channel offer is sent in the SDP then we
could handle all kinds of media in the same SDP: audio, video and MSRP
over data channel. But not sure if this would be feasible. We must
wait. Otherwise MSRP over WebSocket is nice but receiving an SDP with
audio, video and MSRP and trying to pass it to the WebRTC stack of the
browser will be a pain...


Cheers!


-- 
Iñaki Baz Castillo
<ibc at aliax.net>