Hi alaa, I found that with a single bridge I could get around 30 calls playing a wav file (continuous tone) before I would hear a stutter in the tone. So I create a bridge for each call and store them in an array like is done for the players array in pjsua. I tested 96 simultaneous calls with no stutter in the tone. I'm sure it could go much higher. Obviously if the application requires two calls to be bridged then you need to move the calls to the same bridge first and destroy the one that is no longer in use. I wonder if it would be possible to cascade the bridges by making outbound SIP calls back to the server, auto answering and connecting the relevant ports so that two bridges are cascaded via the RTP stream. One thing I found is that if you follow the example http://trac.pjsip.org/repos/wiki/FAQ#pjsua-lib-perf and de-initialize as follows. pjmedia_master_port_stop(cd->m); pjmedia_master_port_destroy(cd->m, PJ_FALSE); There is a thread handle leak as pjmedia_master_port_stop sets the clock thread to NULL. Then pj_thread_destroy is never called in pjmedia_master_port_destroy since the clock thread is already NULL. Regards, Omar On Fri, Mar 4, 2016 at 7:41 PM, alaa <alaa at apliman.com> wrote: > > > Hi Bill , > > Keeping the coding complexity aside , which is the best design > architecture , having a bridge for each call , or a bridge per core. which > will achieve a best result using pjsip and pjmedia? > > On 3/3/2016 5:59 PM, Bill Gardner wrote: > > Hi Alaa, > > I've never tested pjsua with more than about 50 calls but I don't see why > it couldn't scale to thousands. If you are using G711 with bridge running > at 8kHz then the media processing per call is very light, a single core > should be able to handle perhaps 100-200 calls, but I don't know exactly. > But if you are using a high def codec you will get far fewer calls. You > could create one bridge per core, so for example if using an 8 core server > you would create 8 bridges and as calls come in you would assign them to > the least loaded bridge. That may be simpler than one bridge (and one media > processing thread) per call. > > I recommend you code up a single bridge answering system using pjsua, and > then load test it to see what kind of performance you get. > > Regards, > > Bill > > On 3/3/2016 3:47 AM, alaa wrote: > > HI Bill , > > i am trying to create a system that should handle thousands of > simultaneous calls. Can pjsua handle such load? > How much simultaneous calls can pjsip with pjmedia using a bridge for each > call handle? > Thx > On 3/2/2016 5:10 PM, Bill Gardner wrote: > > Hi Alaa, > > It's pretty easy to code an announcement system using pjsua, and if you > don't want to use pjsua you can look at the pjsua code as a guide. > Basically when the call connects you create a wav player object and connect > it to the incoming call via the bridge. See the --auto-play option in > pjsua. You would use --null-audio option so your server doesn't need an > audio device to clock media flow. You can use a single conference bridge > and use this for all calls. However you will then be limited to using a > single processor core which might be a problem if you want to handle > hundreds of simultaneous calls. Creating a bridge for each call is more > complicated but will allow your server to take full advantage of multiple > cores and hence handle more calls. > > Regards, > > Bill > > On 3/2/2016 8:04 AM, alaa wrote: > > I am trying to create a system that can handle Multiple Calls > simultaneously and play announcements to each call. > I need to use PJSIP and PJMedia (not PJSUA). > Is there any document or sample code on how to use pjsip and pjmedia with > multiple calls , and what design structure i should create ? > should i create one conference bridge to handle all calls or a one for > every calls? should i create one pjmedia endpoint or multiple ? > > > > > > > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing listpjsip at lists.pjsip.orghttp://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing listpjsip at lists.pjsip.orghttp://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing listpjsip at lists.pjsip.orghttp://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing listpjsip at lists.pjsip.orghttp://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20160304/ef2c911d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 35 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20160304/ef2c911d/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: img.gif Type: image/gif Size: 35 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20160304/ef2c911d/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 35 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20160304/ef2c911d/attachment-0002.gif>
