[pjsip] Media issue with multiple (parallel) calls

Benny Prijono bennylp at pjsip.org
Fri Feb 8 08:36:39 EST 2008


On 2/8/08, Anshuman S. Rawat <arawat at 3clogic.com> wrote:
> Hi,
>
> We have integrated G729 codec with PJSIP 0.7.0 (revision 1538) and media
> flow works fine for 1 call at a time. However, if we make multiple (even 2)
> G729 calls in parallel the media becomes very choppy and choppiness seems to
> increase with increasing number of parallel G729 calls. The root cause of
> the problem seems to be the fact that encoding and decoding happen in a
> single thread for all the calls (I printed out thread IDs in the encode and
> decode routine of G729 - thread ID was same). The small verification I did
> was that I placed 2 parallel (G729) calls and heard choppy media. On plaving
> of the calls on hold the choppiness dissappeared and reappeared when the
> held call was unheld.
>

When conference bridge is used, then most media processing will be
done in the context of the sound device thread indeed, because audio
sources need to be mixed at the same time.

Are you really tight on CPU? If so, then perhaps this was caused by
the lack of power to run more than one simultaneous G729 calls rather
than encode/decode being done in a single thread.

> I tried increasing the number of worker threads being created in endpoint.c
> to no effect. I was contemplating of how to put encode and decode in
> seperate threads. Maybe Benny or someone whose faced a similar problem could
> give some suggestions?
>

You can create a media port with a worker thread in it, so that:
  - when get_frame() is called on this port, you call get_frame() to the stream.
  - when put_frame() is called, you copy the frame and instruct the
worker thread to call put_frame() to the stream.

Then instead of registering the stream to the bridge, you register
this port to the bridge instead.

cheers,
 -benny


> Thanks,
> Anshuman




More information about the pjsip mailing list