I have an embedded widget that makes use of the Flash (Red5+RTMP) method to place a SIP call to my VOIP Gateway. This works very well for anything up to 24 concurrent calls. Anything after caller number 25 gets an valid Openfire session, but no audio via the widget. The server is not experiencing any significant load, and should be able to handle far more than 25 concurrent calls.
It seems that Openfire accepts the XMPP but Redfire just doesn’t play anything after 24 calls.
Seems to have done the trick… although now audio exceeding 30 things get very choppy, yet the server still has 60% free on 4 cores and about 30GB of memory to play with.
The SIP and audio conferencing engine in Redfire is red5-voicebridge based on jVoiceBridge which is rated to handle over 400 concurrent calls before it starts to suffer from software synching issues.
It generates some very useful stats at the end of each call. Look at those figures closely for the poor quality calls. I have not used it with that many calls, so I do not have any experience to assist you with.
The problem on the other hand could be with the Flash side of things. RTMP with TCP is not ideal protocol for voice calls and that is why I have moved away from Flash to WebRTC
Thanks for the info Dele -always nice to see an actively maintained community around a project.
For the time being we’re on Flash+XMPP for browser compatility reasons. The way things are currently running is that each client starts a new (seperate) conference to an outbound SIP call - We’re looking into how to put multiple XMPP+Flash clients into the same SIP conference (if they’re requesting the same media) - This should help with the load. Any pointers or suggestions for this method? I was reading some CANDY documentation and it said it was do-able, I’m wondering if this translates to Red5.