2013/2/20 Peter Dunkley peter.dunkley@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!