19 Feb
2013
19 Feb
'13
6:40 p.m.
Hi!
We're doing fine. Yesterday, I used Kamailio 4.0 in the SPIRAL multiparty test.
Everything worked as expected.
Today I used Kamailio heavily during the RTCweb test. Kamailio was the core proxy for all
tests done with developers from Firefox and Google Chrome in the room, as well as Iñaki
and Peter available on the Jabber channel. I found one small bug that I believe I fixed, a
missing Contact in a CANCEL that caused Kamailio segfault and core dump.
It took a while to configure everything properly and the examples in the READMEs where a
bit confusing so I'll try to document and update later.
Thank you to Iñaki; jose and Peter for the assistance!
Greetings from North Carolina!
/O
20 Feb
20 Feb
11:13 a.m.
2013/2/20 Olle E. Johansson <oej(a)edvina.net>et>:
Kamailio was the core proxy for all tests done with
developers from Firefox and Google Chrome in the room
Well, not exactly true. After a while, when you were not in place, a
browser developer told me about errors in the WebSocket connection
(due to default TCP buffer in Kamailio which IMHO should be
increased). And then they continued testing their WebRTC stack using
OverSIP as SIP+WS proxy in the "Tryit JsSIP" servers ;)
But the most important thing IMHO:
Kamailio, OverSIP and JsSIP were the "tools" used by browsers vendors
for testing their WebRTC stacks !
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:20 a.m.
On 20/02/13 16:13, Iñaki Baz Castillo wrote:
2013/2/20 Olle E. Johansson <oej(a)edvina.net>et>:
I would like to
point out that the default TCP buffer size in Kamailio
has nothing to do with the Kamailio WebSocket implementation. So far (I
may regret saying this) no-one at SIPit has actually pointed out any
bugs in the Kamailio WebSocket stack itself ;-)
I agree that the buffer size should be increased because any "modern"
INVITE with lots of ICE candidates and different m-lines and codec
options will easily exceed the default of 4kb for TCP or TLS.
Kamailio was the core proxy for all tests done
with developers from Firefox and Google Chrome in the room
Well, not exactly true.
After a while, when you were not in place, a
browser developer told me about errors in the WebSocket connection
(due to default TCP buffer in Kamailio which IMHO should be
increased). And then they continued testing their WebRTC stack using
OverSIP as SIP+WS proxy in the "Tryit JsSIP" servers ;)
11:28 a.m.
2013/2/20 Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
I would like to point out that the default TCP buffer
size in Kamailio has
nothing to do with the Kamailio WebSocket implementation. So far (I may
regret saying this) no-one at SIPit has actually pointed out any bugs in the
Kamailio WebSocket stack itself ;-)
Sure, I did not mean the opposite ;)
I just mean that, at some point, there was some kind of problem and I
told browser vendors to use my server in "Tryit JsSIP" application
(since it has a heavily tested OverSIP + Kamailio infrastructure). I
should re-read the entire chat, maybe I am wrong and the issue was not
related to the TCP buffer (too much activity yesterday, too much
parallel chats in both XMPP and SIP-over-WS lands, too much hot
commits to JsSIP to help in Firefox's WebRTC implementation...). :)
I agree that the buffer size should be increased
because any "modern" INVITE
with lots of ICE candidates and different m-lines and codec options will
easily exceed the default of 4kb for TCP or TLS.
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?
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:49 a.m.
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
12:06 p.m.
2013/2/20 Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
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(a)aliax.net>
12:16 p.m.
On 20/02/13 17:06, Iñaki Baz Castillo wrote:
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!
At the moment when we use JsSIP (with the session object overridden to
use with our MSRP stack) we do either audio/video sessions or MSRP
sessions. Putting all of this in the same signalling session is
something I don't want to think about right now - so we just create
multiple SIP sessions when we need to.
BTW, the architecture of JsSIP makes this really easy to do - so thanks :-)
Peter
12:49 p.m.
2013/2/20 Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
At the moment when we use JsSIP (with the session
object overridden to use
with our MSRP stack) we do either audio/video sessions or MSRP sessions.
Putting all of this in the same signalling session is something I don't want
to think about right now
Neither me! :)
so we just create multiple SIP sessions when we need
to.
Sure. The problem is: what would you do if another SIP client (i.e.
Blinks) offers you (JsSIP) an SDP with audio/video and MSRP? :)
NOTE: I have not the response for this scenario, honestly I consider a
IETF failure to allow mixing in the same SDP audio/video + MSRP.
BTW, the architecture of JsSIP makes this really easy
to do - so thanks :-)
Note however that the Session.js and MediaSession.js modifications
used yesterday in SIPit were removed later from JsSIP master branch
(they still exist in a fork in which Firefox developers have commit
rights to test Firefox's WebRTC stack). This is because changes were
applied too soon and all those changes will be refactorized soon and
commited into master.
Cheers!
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:55 p.m.
On 20/02/13 17:49, Iñaki Baz Castillo wrote:
BTW, the architecture of JsSIP makes this really easy
to do - so thanks :-)
Note however that the Session.js and MediaSession.js modifications
used yesterday in SIPit were removed later from JsSIP master branch
(they still exist in a fork in which Firefox developers have commit
rights to test Firefox's WebRTC stack). This is because changes were
applied too soon and all those changes will be refactorized soon and
commited into master.
Thanks for the warning. For the work we are doing internally with JsSIP
we are tracking the stable branch, so it shouldn't affect us in the
short-term.
4337
days inactive
4338
days old
8 comments
3 participants
participants (3)
-
Iñaki Baz Castillo -
Olle E. Johansson -
Peter Dunkley