powered by Jive Software

Limited to 24 concurrent calls?

Openfire 3.8.2

Redfire 0.0.3.1

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.

Anybody have any suggestions?

Devan

log files are your best friends

1 Like

Figured it out - using the magic of logfiles

voicebridge.rtp.start.port = 3200

voicebridge.rtp.end.port = 3399

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.

I wonder if JVM is limiting things in some way…

Good question. Is openfire using default JVM memory allocation? check JVM settings on openfire web console home page

Hi Dele,

I am with devan in this situation,

We replaced the default JRE built-in with redfire, which suffered significant memory leak, with the newer one. Here is it

*1.6.0_45 Sun Microsystems Inc. – Java HotSpot™ 64-Bit Server VM *

427.63 MB of 8030.25 MB (5.3%) used

It’s never used much memory and CPU (just around 40% usage), but the sound quality is still very choppy with ~30 connections

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.