[pjsip] Media issue with multiple (parallel) calls

Anshuman S. Rawat arawat at 3clogic.com
Wed Feb 13 09:16:16 EST 2008

>> > Ah okay. In that case increasing PJMEDIA_SOUND_BUFFER_COUNT probably
>> > will help. Try with:
>> > in your config_site.h, and if it's okay, experiment with reducing the
>> > number until you get comfortable latency.
>> I had tried that earlier with a value of 12 and tried again (now) with a
>> value of 16. But that didn't help much besides the fact that it did 
>> reduce
>> the number of 'overflow'/'underflow' log messages. And I seem to see 
>> those
>> messages as frequently with pjmedia's g711 codec too.
> In that case, perhaps you can try with increasing it further to, say,
> 32, or even 64 just for the sake of it, and see if it helps.
> The problem seems to be with the sound device, and not with the codec.
>>From your log, it looks like the sound device is too bursty (meaning
> it calls multiple  get_frame() at once and followed by multiple
> put_frames()) and the burst level is too high to be accommodated by
> pjmedia's default setting, hence we need to increase
> Well that's my suspicion anyway.

I tried your suggestion and went up to a value of 512. Latency was too high 
and media quality didn't improve much. However it improved to a level that 
it seemed that audio frames from the 2 different (G729) calls are 
"interfering". There were 2-3 of us here and all of us are quite sure that 
the 2 streams are somehow "interfering". Point to note - only one call is 
granted mic and speaker at a time which is the last call made. This is 
happenning and can be seen in the log.

19:28:33.171 conference.c Port 0 (Primary Sound Capture Driver) stop 
transmitting to port 1 (sip:+18007860404 at
19:28:33.171 strm021ADBC4 Start talksprut..
19:28:33.171 conference.c Port 4 (sip:+18009363500 at 
transmitting to port 0 (Primary Sound Capture Driver)
19:28:33.171 conference.c Port 0 (Primary Sound Capture Driver) transmitting 
to port 4 (sip:+18009363500 at

I had first made a call to 18007860404 and then to 18009363500. As seen, it 
takes 'focus' away from the first call and gives it to the latest (2nd call 
here) call.

Since CPU doesn't look like the issue and increasing 
PJMEDIA_SOUND_BUFFER_COUNT hasn't helped, maybe something is wrong with our 
G729 integration. We integrated g729 using g711.c as a 'working example'. It 
works fine for single g729 calls at a time.

Is there anything we should do for integration which is not evident from the 
g711 source (g711.c)?

BTW, we dont use PJMEDIA's plc or vad feature for G729.


More information about the pjsip mailing list