Buffer problem

[Bugra Cakir]

Hi,

I'm running pjsip-1.6 latest trunk on an beagle board based on ARM processor.
While i'm running pjsua agent it is complaining about


17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443 (eff_cnt=1440)
17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604 (eff_cnt=1440)
17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445 (eff_cnt=1440)
17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286 (eff_cnt=1440)
17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767 (eff_cnt=1320)
17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288 (eff_cnt=1320)
17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129 (eff_cnt=1230)


and after i initiate a call during 180 ringing and after 200 ok


17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292 (eff_cnt=1198)
17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133 (eff_cnt=1198)
17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294 (eff_cnt=1198)
17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135 (eff_cnt=1198)
17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616 (eff_cnt=1198)
17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137 (eff_cnt=1198)
17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298 (eff_cnt=1198)
17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139 (eff_cnt=1198)
17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620 (eff_cnt=1198)
17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141 (eff_cnt=1198)
17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982 (eff_cnt=1138)
17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143 (eff_cnt=1138)
17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.950 sound_port.c EC suspended because of inactivity
17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304 (eff_cnt=1138)
17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300 (eff_cnt=1273)
17:24:10.403 pjsua_core.c RX 423 bytes Request msg BYE/cseq=27568 (rdata0x176f5c) from UDP 2xx.1xx.1xx.xxx:5060:
BYE sip:***@94.54.xx.xx:5060;transport=UDP SIP/2.0
To: <sip:***@telekom.com.tr>;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx
From: <sip:***@telekom.com>;tag=D2055258867AF
Via: SIP/2.0/UDP 212.174.177.33:5060;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Contact: <sip:212.174.177.33:5060>
Max-Forwards: 69
Content-Length: 0


--end msg--
17:24:10.404 pjsua_core.c TX 358 bytes Response msg 200/BYE/cseq=27568 (tdta0x1c3058) to UDP 2xx.1xx.1xx.xxx:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.174.177.33:5060;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
From: <sip:***@telekom.com>;tag=2055258867
To: <sip:***@telekom.com>;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx
CSeq: 27568 BYE
Content-Length: 0


--end msg--
17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal call clearing)]
17:24:10.406 pjsua_app.c
[DISCONNCTD] To: sip:***@telekom.com;tag=2055258867
Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms
#0 iLBC @8KHz, sendrecv, peer=212.174.177.62:12060
RX pt=113, stat last update: 00h:00m:02.478s ago
total 264pkt 13.1KB (23.7KB +IP hdr) @avg=4.5Kbps/8.2Kbps
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 3.042 18.250 1.250 4.373
TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago
total 356pkt 17.8KB (32.0KB +IP hdr) @avg 6.2Kbps/11.1Kbps
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 26.000 39.125 52.250 52.250 13.125
RTT msec : 28.030 32.760 37.490 37.490 4.730


I'm hearing some part of voice activity from A and B party but they are not accurate.
Is the problem related with media infrastructure or the platform it is running on ?

Thank you

[P.Muge Ersoy]

Hi Bugra;

I dont think it is a buffer problem..
I compiled pjsip on arm processor and it was working just fine.. Here what i
did..
I compiled it with PJ_CONFIG_MINIMAL_SIZE at config_site.h..

I ve never used iLBC codec.. coz it is too heavy for the processor.. instead
use G.711.. you will hear more proper voice..

Selamlar Muge :)

Post by Bugra Cakir
Hi,
I'm running pjsip-1.6 latest trunk on an beagle board based on ARM processor.
While i'm running pjsua agent it is complaining about
17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443 (eff_cnt=1440)
17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604 (eff_cnt=1440)
17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445 (eff_cnt=1440)
17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286 (eff_cnt=1440)
17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767 (eff_cnt=1320)
17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288 (eff_cnt=1320)
17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129 (eff_cnt=1230)
and after i initiate a call during 180 ringing and after 200 ok
17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292 (eff_cnt=1198)
17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133 (eff_cnt=1198)
17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294 (eff_cnt=1198)
17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135 (eff_cnt=1198)
17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616 (eff_cnt=1198)
17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137 (eff_cnt=1198)
17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298 (eff_cnt=1198)
17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139 (eff_cnt=1198)
17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620 (eff_cnt=1198)
17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141 (eff_cnt=1198)
17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982 (eff_cnt=1138)
17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143 (eff_cnt=1138)
17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.950 sound_port.c EC suspended because of inactivity
17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304 (eff_cnt=1138)
17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300 (eff_cnt=1273)
17:24:10.403 pjsua_core.c RX 423 bytes Request msg BYE/cseq=27568

Post by Bugra Cakir
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx
;tag=D2055258867AF

Via: SIP/2.0/UDP 212.174.177.33:5060
;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Contact: <sip:212.174.177.33:5060>
Max-Forwards: 69
Content-Length: 0
--end msg--
17:24:10.404 pjsua_core.c TX 358 bytes Response msg 200/BYE/cseq=27568
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.174.177.33:5060
;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD

Post by Bugra Cakir
;tag=2055258867
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx

CSeq: 27568 BYE
Content-Length: 0
--end msg--
17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal call clearing)]
17:24:10.406 pjsua_app.c
;tag=2055258867
Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms
RX pt=113, stat last update: 00h:00m:02.478s ago
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 3.042 18.250 1.250 4.373
TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 26.000 39.125 52.250 52.250 13.125
RTT msec : 28.030 32.760 37.490 37.490 4.730
I'm hearing some part of voice activity from A and B party but they are not accurate.
Is the problem related with media infrastructure or the platform it is running on ?
Thank you
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Angel Of Retributioin]

set echo cancellation parameter to 0 and set default clock rate to 8000

I guess this might help

Regards,
Elangbam Johnson

Post by P.Muge Ersoy
Hi Bugra;
I dont think it is a buffer problem..
I compiled pjsip on arm processor and it was working just fine.. Here what
i did..
I compiled it with PJ_CONFIG_MINIMAL_SIZE at config_site.h..
I ve never used iLBC codec.. coz it is too heavy for the processor..
instead use G.711.. you will hear more proper voice..
Selamlar Muge :)

Post by Bugra Cakir
Hi,
I'm running pjsip-1.6 latest trunk on an beagle board based on ARM processor.
While i'm running pjsua agent it is complaining about
17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443 (eff_cnt=1440)
17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604 (eff_cnt=1440)
17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445 (eff_cnt=1440)
17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286 (eff_cnt=1440)
17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767 (eff_cnt=1320)
17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288 (eff_cnt=1320)
17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129 (eff_cnt=1230)
and after i initiate a call during 180 ringing and after 200 ok
17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292 (eff_cnt=1198)
17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133 (eff_cnt=1198)
17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294 (eff_cnt=1198)
17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135 (eff_cnt=1198)
17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616 (eff_cnt=1198)
17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137 (eff_cnt=1198)
17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298 (eff_cnt=1198)
17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139 (eff_cnt=1198)
17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620 (eff_cnt=1198)
17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141 (eff_cnt=1198)
17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982 (eff_cnt=1138)
17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143 (eff_cnt=1138)
17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.950 sound_port.c EC suspended because of inactivity
17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304 (eff_cnt=1138)
17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300 (eff_cnt=1273)
17:24:10.403 pjsua_core.c RX 423 bytes Request msg BYE/cseq=27568

Post by Bugra Cakir
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx
;tag=D2055258867AF

Via: SIP/2.0/UDP 212.174.177.33:5060
;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Contact: <sip:212.174.177.33:5060>
Max-Forwards: 69
Content-Length: 0
--end msg--
17:24:10.404 pjsua_core.c TX 358 bytes Response msg 200/BYE/cseq=27568
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.174.177.33:5060
;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD

Post by Bugra Cakir
;tag=2055258867
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx

CSeq: 27568 BYE
Content-Length: 0
--end msg--
17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal call clearing)]
17:24:10.406 pjsua_app.c
;tag=2055258867
Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms
RX pt=113, stat last update: 00h:00m:02.478s ago
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 3.042 18.250 1.250 4.373
TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 26.000 39.125 52.250 52.250 13.125
RTT msec : 28.030 32.760 37.490 37.490 4.730
I'm hearing some part of voice activity from A and B party but they are not accurate.
Is the problem related with media infrastructure or the platform it is running on ?
Thank you
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Bugra Cakir]

No way out with PCMU and clockrate ! Shoulda try something else.

./pjsua-armv7l-unknown-linux-gnu --username=test7 --password=123 --proxy=sip:85.123.66.44 --registrar sip:telekom.com --id sip:***@turktelekom.com.tr --add-codec pcmu --dis-codec speex --dis-codec ilbc --dis-codec GSM --dis-codec G722 --clock-rate=8000 --snd-clock-rate=8000 --capture-dev=1 --playback-dev=0


19:20:06.402 pjsua_app.c Call 0 is DISCONNECTED [reason=200 (Normal call clearing)]
19:20:06.403 pjsua_app.c
[DISCONNCTD] To: sip:***@telekom.com;tag=632633610
Call time: 00h:00m:28s, 1st res in 6678 ms, conn in 10920ms
#0 PCMU @8KHz, sendrecv, peer=78.223.11.23:12240
RX pt=0, stat last update: 00h:00m:15.501s ago
total 1.4Kpkt 230.2KB (288.0KB +IP hdr) @avg=57.0Kbps/71.3Kbps
pkt loss=6 (0.4%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 20.000 20.000 20.000 0.000
jitter : 0.000 0.313 11.625 0.125 0.824
TX pt=0, ptime=20ms, stat last update: 00h:00m:00.150s ago
total 364pkt 58.2KB (72.8KB +IP hdr) @avg 14.4Kbps/18.0Kbps
pkt loss=7 (1.9%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 46.667 100.000 20.000 32.731
jitter : 50.250 70.161 87.125 87.125 10.734
RTT msec : 12.054 15.701 17.456 12.054 2.131
19:20:06.404 pjsua_media.c Media session for call 0 is destroyed
19:20:06.467 ec0x165cf8 Buffer size adjusted from 7194 to 6025 (eff_cnt=5512)
19:20:06.669 ec0x165cf8 Buffer size adjusted from 7208 to 5784 (eff_cnt=5512)
19:20:06.881 ec0x165cf8 Buffer size adjusted from 7527 to 6098 (eff_cnt=5512)
19:20:07.037 ec0x165cf8 Buffer size adjusted from 7310 to 5871 (eff_cnt=5512)

Post by P.Muge Ersoy
Hi Bugra;
I dont think it is a buffer problem..
I compiled pjsip on arm processor and it was working just fine.. Here what i did..
I compiled it with PJ_CONFIG_MINIMAL_SIZE at config_site.h..
I ve never used iLBC codec.. coz it is too heavy for the processor.. instead use G.711.. you will hear more proper voice..
Selamlar Muge :)
Hi,
I'm running pjsip-1.6 latest trunk on an beagle board based on ARM processor.
While i'm running pjsua agent it is complaining about
17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443 (eff_cnt=1440)
17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604 (eff_cnt=1440)
17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445 (eff_cnt=1440)
17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286 (eff_cnt=1440)
17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767 (eff_cnt=1320)
17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288 (eff_cnt=1320)
17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129 (eff_cnt=1230)
and after i initiate a call during 180 ringing and after 200 ok
17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292 (eff_cnt=1198)
17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133 (eff_cnt=1198)
17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294 (eff_cnt=1198)
17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135 (eff_cnt=1198)
17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616 (eff_cnt=1198)
17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137 (eff_cnt=1198)
17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298 (eff_cnt=1198)
17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139 (eff_cnt=1198)
17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620 (eff_cnt=1198)
17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141 (eff_cnt=1198)
17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982 (eff_cnt=1138)
17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143 (eff_cnt=1138)
17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.950 sound_port.c EC suspended because of inactivity
17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304 (eff_cnt=1138)
17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300 (eff_cnt=1273)
Via: SIP/2.0/UDP 212.174.177.33:5060;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Contact: <sip:212.174.177.33:5060>
Max-Forwards: 69
Content-Length: 0
--end msg--
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.174.177.33:5060;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Content-Length: 0
--end msg--
17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal call clearing)]
17:24:10.406 pjsua_app.c
Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms
RX pt=113, stat last update: 00h:00m:02.478s ago
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 3.042 18.250 1.250 4.373
TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 26.000 39.125 52.250 52.250 13.125
RTT msec : 28.030 32.760 37.490 37.490 4.730
I'm hearing some part of voice activity from A and B party but they are not accurate.
Is the problem related with media infrastructure or the platform it is running on ?
Thank you
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Olle Frimanson]

Hi Bugra,



We have also used pjsip on several different ARM's so that is not the issue,
what might be worth checking is what samplings rates your codec (AD/DA)
supports. If it's doesn't supports 8000 resampling will be done in ALSA
driver I think and this could be a problem.



Also have you tried the basic stuff like connect a local call in PJSUA, play
out a file and record from file does that work?



BR/Olle



_____

From: pjsip-***@lists.pjsip.org [mailto:pjsip-***@lists.pjsip.org]
On Behalf Of Bugra Cakir
Sent: den 25 april 2010 10:03
To: pjsip list
Subject: Re: [pjsip] Buffer problem



No way out with PCMU and clockrate ! Shoulda try something else.



./pjsua-armv7l-unknown-linux-gnu --username=test7 --password=123
--proxy=sip:85.123.66.44 --registrar sip:telekom.com --id
sip:***@turktelekom.com.tr --add-codec pcmu --dis-codec speex --dis-codec
ilbc --dis-codec GSM --dis-codec G722 --clock-rate=8000
--snd-clock-rate=8000 --capture-dev=1 --playback-dev=0





19:20:06.402 pjsua_app.c Call 0 is DISCONNECTED [reason=200 (Normal call
clearing)]

19:20:06.403 pjsua_app.c

[DISCONNCTD] To: sip:***@telekom.com;tag=632633610

Call time: 00h:00m:28s, 1st res in 6678 ms, conn in 10920ms

#0 PCMU @8KHz, sendrecv, peer=78.223.11.23:12240

RX pt=0, stat last update: 00h:00m:15.501s ago

total 1.4Kpkt 230.2KB (288.0KB +IP hdr) @avg=57.0Kbps/71.3Kbps

pkt loss=6 (0.4%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)

(msec) min avg max last dev

loss period: 20.000 20.000 20.000 20.000 0.000

jitter : 0.000 0.313 11.625 0.125 0.824

TX pt=0, ptime=20ms, stat last update: 00h:00m:00.150s ago

total 364pkt 58.2KB (72.8KB +IP hdr) @avg 14.4Kbps/18.0Kbps

pkt loss=7 (1.9%), dup=0 (0.0%), reorder=0 (0.0%)

(msec) min avg max last dev

loss period: 20.000 46.667 100.000 20.000 32.731

jitter : 50.250 70.161 87.125 87.125 10.734

RTT msec : 12.054 15.701 17.456 12.054 2.131

19:20:06.404 pjsua_media.c Media session for call 0 is destroyed

19:20:06.467 ec0x165cf8 Buffer size adjusted from 7194 to 6025
(eff_cnt=5512)

19:20:06.669 ec0x165cf8 Buffer size adjusted from 7208 to 5784
(eff_cnt=5512)

19:20:06.881 ec0x165cf8 Buffer size adjusted from 7527 to 6098
(eff_cnt=5512)

19:20:07.037 ec0x165cf8 Buffer size adjusted from 7310 to 5871
(eff_cnt=5512)





On Apr 24, 2010, at 9:44 AM, P.Muge Ersoy wrote:





Hi Bugra;

I dont think it is a buffer problem..
I compiled pjsip on arm processor and it was working just fine.. Here what i
did..
I compiled it with PJ_CONFIG_MINIMAL_SIZE at config_site.h..

I ve never used iLBC codec.. coz it is too heavy for the processor.. instead
use G.711.. you will hear more proper voice..

Selamlar Muge :)





On Sat, Apr 24, 2010 at 9:09 AM, Bugra Cakir <***@argela.com.tr>
wrote:

Hi,

I'm running pjsip-1.6 latest trunk on an beagle board based on ARM
processor.
While i'm running pjsua agent it is complaining about


17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443
(eff_cnt=1440)
17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604
(eff_cnt=1440)
17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445
(eff_cnt=1440)
17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286
(eff_cnt=1440)
17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767
(eff_cnt=1320)
17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288
(eff_cnt=1320)
17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129
(eff_cnt=1230)


and after i initiate a call during 180 ringing and after 200 ok


17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292
(eff_cnt=1198)
17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133
(eff_cnt=1198)
17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294
(eff_cnt=1198)
17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135
(eff_cnt=1198)
17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616
(eff_cnt=1198)
17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137
(eff_cnt=1198)
17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298
(eff_cnt=1198)
17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139
(eff_cnt=1198)
17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620
(eff_cnt=1198)
17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141
(eff_cnt=1198)
17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982
(eff_cnt=1138)
17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143
(eff_cnt=1138)
17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.950 sound_port.c EC suspended because of inactivity
17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304
(eff_cnt=1138)
17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300
(eff_cnt=1273)
17:24:10.403 pjsua_core.c RX 423 bytes Request msg BYE/cseq=27568

Post by Bugra Cakir
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx
;tag=D2055258867AF

Via: SIP/2.0/UDP
212.174.177.33:5060;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Contact: <sip:212.174.177.33:5060 <http://212.174.177.33:5060/> >
Max-Forwards: 69
Content-Length: 0


--end msg--
17:24:10.404 pjsua_core.c TX 358 bytes Response msg 200/BYE/cseq=27568
(tdta0x1c3058) to UDP 2xx.1xx.1xx.xxx:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
212.174.177.33:5060;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543
-297e466706249ce1-1--d87543-
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD

Post by Bugra Cakir
;tag=2055258867
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx

CSeq: 27568 BYE
Content-Length: 0


--end msg--
17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal
call clearing)]
17:24:10.406 pjsua_app.c
[DISCONNCTD] To: sip:***@telekom.com
<mailto:sip%***@telekom.com> ;tag=2055258867
Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms
#0 iLBC @8KHz, sendrecv, peer=212.174.177.62:12060
<http://212.174.177.62:12060/>
RX pt=113, stat last update: 00h:00m:02.478s ago
total 264pkt 13.1KB (23.7KB +IP hdr) @avg=4.5Kbps/8.2Kbps
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 3.042 18.250 1.250 4.373
TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago
total 356pkt 17.8KB (32.0KB +IP hdr) @avg 6.2Kbps/11.1Kbps
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 26.000 39.125 52.250 52.250 13.125
RTT msec : 28.030 32.760 37.490 37.490 4.730


I'm hearing some part of voice activity from A and B party but they are not
accurate.
Is the problem related with media infrastructure or the platform it is
running on ?

Thank you







_______________________________________________
Visit our blog: http://blog.pjsip.org <http://blog.pjsip.org/>

pjsip mailing list
***@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org


_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Régis Montoya]

Sorry to update this topic but I think that I have some new clues on this
issue.

(As reminder I'm the developer of the port of pjsip for android).
I have made a build with ilbc enabled. And I get the same logs that the one
described on this thread. It's also on arm architecture but devices have a
correct CPU (1Ghz).
The result is that if I use ilbc with mode 20ms, things are really good, but
if set mode to 30ms get exactly the same buffer resizing logs and sound is
really bad.
Maybe my audio driver is not well designed but don't think so since works
well with all other codecs (and when ilbc mode is 20).
Is there some constraints about buffers size/chunk read size on the audio
driver?

Regis

Post by Olle Frimanson
Hi Bugra,
We have also used pjsip on several different ARM’s so that is not the
issue, what might be worth checking is what samplings rates your codec
(AD/DA) supports. If it’s doesn’t supports 8000 resampling will be done in
ALSA driver I think and this could be a problem.
Also have you tried the basic stuff like connect a local call in PJSUA,
play out a file and record from file does that work?
BR/Olle
------------------------------
*Sent:* den 25 april 2010 10:03
*To:* pjsip list
*Subject:* Re: [pjsip] Buffer problem
No way out with PCMU and clockrate ! Shoulda try something else.
./pjsua-armv7l-unknown-linux-gnu --username=test7 --password=123
--proxy=sip:85.123.66.44 --registrar sip:telekom.com --id
--dis-codec ilbc --dis-codec GSM --dis-codec G722 --clock-rate=8000
--snd-clock-rate=8000 --capture-dev=1 --playback-dev=0
19:20:06.402 pjsua_app.c Call 0 is DISCONNECTED [reason=200 (Normal call clearing)]
19:20:06.403 pjsua_app.c
Call time: 00h:00m:28s, 1st res in 6678 ms, conn in 10920ms
RX pt=0, stat last update: 00h:00m:15.501s ago
pkt loss=6 (0.4%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 20.000 20.000 20.000 0.000
jitter : 0.000 0.313 11.625 0.125 0.824
TX pt=0, ptime=20ms, stat last update: 00h:00m:00.150s ago
pkt loss=7 (1.9%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 46.667 100.000 20.000 32.731
jitter : 50.250 70.161 87.125 87.125 10.734
RTT msec : 12.054 15.701 17.456 12.054 2.131
19:20:06.404 pjsua_media.c Media session for call 0 is destroyed
19:20:06.467 ec0x165cf8 Buffer size adjusted from 7194 to 6025 (eff_cnt=5512)
19:20:06.669 ec0x165cf8 Buffer size adjusted from 7208 to 5784 (eff_cnt=5512)
19:20:06.881 ec0x165cf8 Buffer size adjusted from 7527 to 6098 (eff_cnt=5512)
19:20:07.037 ec0x165cf8 Buffer size adjusted from 7310 to 5871 (eff_cnt=5512)
Hi Bugra;
I dont think it is a buffer problem..
I compiled pjsip on arm processor and it was working just fine.. Here what i did..
I compiled it with PJ_CONFIG_MINIMAL_SIZE at config_site.h..
I ve never used iLBC codec.. coz it is too heavy for the processor..
instead use G.711.. you will hear more proper voice..
Selamlar Muge :)
Hi,
I'm running pjsip-1.6 latest trunk on an beagle board based on ARM processor.
While i'm running pjsua agent it is complaining about
17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443 (eff_cnt=1440)
17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604 (eff_cnt=1440)
17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445 (eff_cnt=1440)
17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286 (eff_cnt=1440)
17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767 (eff_cnt=1320)
17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288 (eff_cnt=1320)
17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129 (eff_cnt=1230)
and after i initiate a call during 180 ringing and after 200 ok
17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292 (eff_cnt=1198)
17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133 (eff_cnt=1198)
17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294 (eff_cnt=1198)
17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135 (eff_cnt=1198)
17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616 (eff_cnt=1198)
17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137 (eff_cnt=1198)
17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298 (eff_cnt=1198)
17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139 (eff_cnt=1198)
17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620 (eff_cnt=1198)
17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141 (eff_cnt=1198)
17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982 (eff_cnt=1138)
17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143 (eff_cnt=1138)
17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.950 sound_port.c EC suspended because of inactivity
17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304 (eff_cnt=1138)
17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300 (eff_cnt=1273)
17:24:10.403 pjsua_core.c RX 423 bytes Request msg BYE/cseq=27568

Post by Bugra Cakir
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx
;tag=D2055258867AF

Via: SIP/2.0/UDP 212.174.177.33:5060
;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Contact: <sip:212.174.177.33:5060>
Max-Forwards: 69
Content-Length: 0
--end msg--
17:24:10.404 pjsua_core.c TX 358 bytes Response msg 200/BYE/cseq=27568
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.174.177.33:5060
;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD

Post by Bugra Cakir
;tag=2055258867
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx

CSeq: 27568 BYE
Content-Length: 0
--end msg--
17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal call clearing)]
17:24:10.406 pjsua_app.c
;tag=2055258867
Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms
RX pt=113, stat last update: 00h:00m:02.478s ago
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 3.042 18.250 1.250 4.373
TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 26.000 39.125 52.250 52.250 13.125
RTT msec : 28.030 32.760 37.490 37.490 4.730
I'm hearing some part of voice activity from A and B party but they are not accurate.
Is the problem related with media infrastructure or the platform it is running on ?
Thank you
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[M.Ali VARDAR]

Hi,

Dont use ilbc please use pcma or pcmu and you have to compile with MINIMAL
settings in config_site.

http://svn.pjsip.org/repos/pjproject/branches/projects/iphone/pjlib/include/pj/config_site_sample.h

You can find more information in README file for compiling

Best Regards
M.Ali VARDAR

Post by Régis Montoya
Sorry to update this topic but I think that I have some new clues on this
issue.
(As reminder I'm the developer of the port of pjsip for android).
I have made a build with ilbc enabled. And I get the same logs that the one
described on this thread. It's also on arm architecture but devices have a
correct CPU (1Ghz).
The result is that if I use ilbc with mode 20ms, things are really good,
but if set mode to 30ms get exactly the same buffer resizing logs and sound
is really bad.
Maybe my audio driver is not well designed but don't think so since works
well with all other codecs (and when ilbc mode is 20).
Is there some constraints about buffers size/chunk read size on the audio
driver?
Regis

Post by Olle Frimanson
Hi Bugra,
We have also used pjsip on several different ARM’s so that is not the
issue, what might be worth checking is what samplings rates your codec
(AD/DA) supports. If it’s doesn’t supports 8000 resampling will be done in
ALSA driver I think and this could be a problem.
Also have you tried the basic stuff like connect a local call in PJSUA,
play out a file and record from file does that work?
BR/Olle
------------------------------
*Sent:* den 25 april 2010 10:03
*To:* pjsip list
*Subject:* Re: [pjsip] Buffer problem
No way out with PCMU and clockrate ! Shoulda try something else.
./pjsua-armv7l-unknown-linux-gnu --username=test7 --password=123
--proxy=sip:85.123.66.44 --registrar sip:telekom.com --id
--dis-codec ilbc --dis-codec GSM --dis-codec G722 --clock-rate=8000
--snd-clock-rate=8000 --capture-dev=1 --playback-dev=0
19:20:06.402 pjsua_app.c Call 0 is DISCONNECTED [reason=200 (Normal call clearing)]
19:20:06.403 pjsua_app.c
Call time: 00h:00m:28s, 1st res in 6678 ms, conn in 10920ms
RX pt=0, stat last update: 00h:00m:15.501s ago
pkt loss=6 (0.4%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 20.000 20.000 20.000 0.000
jitter : 0.000 0.313 11.625 0.125 0.824
TX pt=0, ptime=20ms, stat last update: 00h:00m:00.150s ago
pkt loss=7 (1.9%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 46.667 100.000 20.000 32.731
jitter : 50.250 70.161 87.125 87.125 10.734
RTT msec : 12.054 15.701 17.456 12.054 2.131
19:20:06.404 pjsua_media.c Media session for call 0 is destroyed
19:20:06.467 ec0x165cf8 Buffer size adjusted from 7194 to 6025 (eff_cnt=5512)
19:20:06.669 ec0x165cf8 Buffer size adjusted from 7208 to 5784 (eff_cnt=5512)
19:20:06.881 ec0x165cf8 Buffer size adjusted from 7527 to 6098 (eff_cnt=5512)
19:20:07.037 ec0x165cf8 Buffer size adjusted from 7310 to 5871 (eff_cnt=5512)
Hi Bugra;
I dont think it is a buffer problem..
I compiled pjsip on arm processor and it was working just fine.. Here what i did..
I compiled it with PJ_CONFIG_MINIMAL_SIZE at config_site.h..
I ve never used iLBC codec.. coz it is too heavy for the processor..
instead use G.711.. you will hear more proper voice..
Selamlar Muge :)
Hi,
I'm running pjsip-1.6 latest trunk on an beagle board based on ARM processor.
While i'm running pjsua agent it is complaining about
17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443 (eff_cnt=1440)
17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604 (eff_cnt=1440)
17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445 (eff_cnt=1440)
17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286 (eff_cnt=1440)
17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767 (eff_cnt=1320)
17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288 (eff_cnt=1320)
17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129 (eff_cnt=1230)
and after i initiate a call during 180 ringing and after 200 ok
17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292 (eff_cnt=1198)
17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133 (eff_cnt=1198)
17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294 (eff_cnt=1198)
17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135 (eff_cnt=1198)
17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616 (eff_cnt=1198)
17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137 (eff_cnt=1198)
17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298 (eff_cnt=1198)
17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139 (eff_cnt=1198)
17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620 (eff_cnt=1198)
17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141 (eff_cnt=1198)
17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982 (eff_cnt=1138)
17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143 (eff_cnt=1138)
17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.950 sound_port.c EC suspended because of inactivity
17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304 (eff_cnt=1138)
17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300 (eff_cnt=1273)
17:24:10.403 pjsua_core.c RX 423 bytes Request msg BYE/cseq=27568

Post by Bugra Cakir
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx
;tag=D2055258867AF

Via: SIP/2.0/UDP 212.174.177.33:5060
;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Contact: <sip:212.174.177.33:5060>
Max-Forwards: 69
Content-Length: 0
--end msg--
17:24:10.404 pjsua_core.c TX 358 bytes Response msg 200/BYE/cseq=27568
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.174.177.33:5060
;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD

Post by Bugra Cakir
;tag=2055258867
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx

CSeq: 27568 BYE
Content-Length: 0
--end msg--
17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal call clearing)]
17:24:10.406 pjsua_app.c
;tag=2055258867
Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms
RX pt=113, stat last update: 00h:00m:02.478s ago
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 3.042 18.250 1.250 4.373
TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 26.000 39.125 52.250 52.250 13.125
RTT msec : 28.030 32.760 37.490 37.490 4.730
I'm hearing some part of voice activity from A and B party but they are not accurate.
Is the problem related with media infrastructure or the platform it is running on ?
Thank you
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Régis Montoya]

Don't worry, I have already the good config_site set. (And recently
optimized).
Everything is just fine with all other codecs (and even better, I have also
ported the g729 port from samuel and also work really fine) GSM, speex etc
are fine too. Nexus One has a 1GHz CPU and should be enough to support ilbc.

My point is just a report to help the developer to find out what is going
wrong with ilbc. There is maybe a regression or something bad with it.
That's really strange that 20ms is really good and 30ms become absolutely
unusable? Isn't it?
But if we can support ilbc (as it is announced on the main page of pjsip),
it would be really cool. Well not a necessity but if somebody has an idea on
how to quickly fix it.

Btw, I'll try to dive into the ilbc code to see were things can go wrong but
if somebody else (with better knownledge of ilbc has any clue he will be
welcome ;) )

Regards,
Régis

Post by M.Ali VARDAR
Hi,
Dont use ilbc please use pcma or pcmu and you have to compile with MINIMAL
settings in config_site.
http://svn.pjsip.org/repos/pjproject/branches/projects/iphone/pjlib/include/pj/config_site_sample.h
You can find more information in README file for compiling
Best Regards
M.Ali VARDAR
Sorry to update this topic but I think that I have some new clues on this

Post by Régis Montoya
issue.
(As reminder I'm the developer of the port of pjsip for android).
I have made a build with ilbc enabled. And I get the same logs that the
one described on this thread. It's also on arm architecture but devices have
a correct CPU (1Ghz).
The result is that if I use ilbc with mode 20ms, things are really good,
but if set mode to 30ms get exactly the same buffer resizing logs and sound
is really bad.
Maybe my audio driver is not well designed but don't think so since works
well with all other codecs (and when ilbc mode is 20).
Is there some constraints about buffers size/chunk read size on the audio
driver?
Regis

Post by Olle Frimanson
Hi Bugra,
We have also used pjsip on several different ARM’s so that is not the
issue, what might be worth checking is what samplings rates your codec
(AD/DA) supports. If it’s doesn’t supports 8000 resampling will be done in
ALSA driver I think and this could be a problem.
Also have you tried the basic stuff like connect a local call in PJSUA,
play out a file and record from file does that work?
BR/Olle
------------------------------
*Sent:* den 25 april 2010 10:03
*To:* pjsip list
*Subject:* Re: [pjsip] Buffer problem
No way out with PCMU and clockrate ! Shoulda try something else.
./pjsua-armv7l-unknown-linux-gnu --username=test7 --password=123
--proxy=sip:85.123.66.44 --registrar sip:telekom.com --id
--dis-codec ilbc --dis-codec GSM --dis-codec G722 --clock-rate=8000
--snd-clock-rate=8000 --capture-dev=1 --playback-dev=0
19:20:06.402 pjsua_app.c Call 0 is DISCONNECTED [reason=200 (Normal call clearing)]
19:20:06.403 pjsua_app.c
Call time: 00h:00m:28s, 1st res in 6678 ms, conn in 10920ms
RX pt=0, stat last update: 00h:00m:15.501s ago
pkt loss=6 (0.4%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 20.000 20.000 20.000 0.000
jitter : 0.000 0.313 11.625 0.125 0.824
TX pt=0, ptime=20ms, stat last update: 00h:00m:00.150s ago
pkt loss=7 (1.9%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 20.000 46.667 100.000 20.000 32.731
jitter : 50.250 70.161 87.125 87.125 10.734
RTT msec : 12.054 15.701 17.456 12.054 2.131
19:20:06.404 pjsua_media.c Media session for call 0 is destroyed
19:20:06.467 ec0x165cf8 Buffer size adjusted from 7194 to 6025 (eff_cnt=5512)
19:20:06.669 ec0x165cf8 Buffer size adjusted from 7208 to 5784 (eff_cnt=5512)
19:20:06.881 ec0x165cf8 Buffer size adjusted from 7527 to 6098 (eff_cnt=5512)
19:20:07.037 ec0x165cf8 Buffer size adjusted from 7310 to 5871 (eff_cnt=5512)
Hi Bugra;
I dont think it is a buffer problem..
I compiled pjsip on arm processor and it was working just fine.. Here what i did..
I compiled it with PJ_CONFIG_MINIMAL_SIZE at config_site.h..
I ve never used iLBC codec.. coz it is too heavy for the processor..
instead use G.711.. you will hear more proper voice..
Selamlar Muge :)
Hi,
I'm running pjsip-1.6 latest trunk on an beagle board based on ARM processor.
While i'm running pjsua agent it is complaining about
17:22:12.483 ec0x165cf8 Buffer size adjusted from 1922 to 1443 (eff_cnt=1440)
17:22:12.609 ec0x165cf8 Buffer size adjusted from 2083 to 1604 (eff_cnt=1440)
17:22:12.643 ec0x165cf8 Buffer size adjusted from 1924 to 1445 (eff_cnt=1440)
17:22:12.843 ec0x165cf8 Buffer size adjusted from 1765 to 1286 (eff_cnt=1440)
17:22:14.623 ec0x165cf8 Buffer size adjusted from 2246 to 1767 (eff_cnt=1320)
17:22:14.643 ec0x165cf8 Buffer size adjusted from 1767 to 1288 (eff_cnt=1320)
17:22:15.663 ec0x165cf8 Buffer size adjusted from 1608 to 1129 (eff_cnt=1230)
and after i initiate a call during 180 ringing and after 200 ok
17:24:04.540 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.689 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.740 ec0x165cf8 Buffer size adjusted from 1771 to 1292 (eff_cnt=1198)
17:24:04.814 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:04.865 ec0x165cf8 Buffer size adjusted from 1612 to 1133 (eff_cnt=1198)
17:24:04.917 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.046 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.070 ec0x165cf8 Buffer size adjusted from 1773 to 1294 (eff_cnt=1198)
17:24:05.157 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.186 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.259 ec0x165cf8 Buffer size adjusted from 1614 to 1135 (eff_cnt=1198)
17:24:05.321 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.449 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.526 ec0x165cf8 Buffer size adjusted from 2095 to 1616 (eff_cnt=1198)
17:24:05.559 ec0x165cf8 Buffer size adjusted from 1616 to 1137 (eff_cnt=1198)
17:24:05.575 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.694 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.759 ec0x165cf8 Buffer size adjusted from 1777 to 1298 (eff_cnt=1198)
17:24:05.834 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:05.880 ec0x165cf8 Buffer size adjusted from 1618 to 1139 (eff_cnt=1198)
17:24:05.947 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.064 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.227 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.299 ec0x165cf8 Buffer size adjusted from 2099 to 1620 (eff_cnt=1198)
17:24:06.322 ec0x165cf8 Buffer size adjusted from 1620 to 1141 (eff_cnt=1198)
17:24:06.409 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.436 ec0x165cf8 Buffer size adjusted from 1461 to 982 (eff_cnt=1138)
17:24:06.533 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.667 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.716 ec0x165cf8 Buffer size adjusted from 1622 to 1143 (eff_cnt=1138)
17:24:06.787 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.891 Master/sound Underflow, buf_cnt=0, will generate 1 frame
17:24:06.950 sound_port.c EC suspended because of inactivity
17:24:06.954 ec0x165cf8 Buffer size adjusted from 1783 to 1304 (eff_cnt=1138)
17:24:09.474 Master/sound Buffer size adjusted from 1600 to 1300 (eff_cnt=1273)
17:24:10.403 pjsua_core.c RX 423 bytes Request msg BYE/cseq=27568

Post by Bugra Cakir
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx
;tag=D2055258867AF

Via: SIP/2.0/UDP 212.174.177.33:5060
;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-;rport
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD
CSeq: 27568 BYE
Contact: <sip:212.174.177.33:5060>
Max-Forwards: 69
Content-Length: 0
--end msg--
17:24:10.404 pjsua_core.c TX 358 bytes Response msg
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.174.177.33:5060
;rport=5060;received=212.174.177.33;branch=z9hG4bK-d87543-297e466706249ce1-1--d87543-
Call-ID: YBw7zbEzXBcctw-kYRH10mwveLf-WYsD

Post by Bugra Cakir
;tag=2055258867
;tag=xvy7KGP82TYBfYWJlAAMobbbHClKLJOx

CSeq: 27568 BYE
Content-Length: 0
--end msg--
17:24:10.405 pjsua_app.c Call 1 is DISCONNECTED [reason=200 (Normal
call clearing)]
17:24:10.406 pjsua_app.c
;tag=2055258867
Call time: 00h:00m:22s, 1st res in 5599 ms, conn in 12939ms
RX pt=113, stat last update: 00h:00m:02.478s ago
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.000 3.042 18.250 1.250 4.373
TX pt=100, ptime=30ms, stat last update: 00h:00m:15.268s ago
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 26.000 39.125 52.250 52.250 13.125
RTT msec : 28.030 32.760 37.490 37.490 4.730
I'm hearing some part of voice activity from A and B party but they are not accurate.
Is the problem related with media infrastructure or the platform it is running on ?
Thank you
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

--
--------------------
Saygılarımla
M.Ali VARDAR
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Benny Prijono]

Post by Régis Montoya
Don't worry, I have already the good config_site set. (And recently
optimized).
Everything is just fine with all other codecs (and even better, I have also
ported the g729 port from samuel and also work really fine) GSM, speex etc
are fine too. Nexus One has a 1GHz CPU and should be enough to support ilbc.
My point is just a report to help the developer to find out what is going
wrong with ilbc. There is maybe a regression or something bad with it.
That's really strange that 20ms is really good and 30ms become absolutely
unusable? Isn't it?
But if we can support ilbc (as it is announced on the main page of pjsip),
it would be really cool. Well not a necessity but if somebody has an idea on
how to quickly fix it.

The iLBC mode is set to 30ms by default, and I don't recall having any
problems with this mode..

What peer did you use for the test?

According to the spec, if any of the agent uses mode 30, then the
other must also use mode 30, even though it initially indicates that
it uses mode 20 in its SDP. It could be that the peer is still using
mode 20 even though you've set your mode to 30.

And yes we used to have this problem in the past, but this was fixed
months/year ago, so as long as you have relatively recent pjsip
version you should be okay.

This can be easily verified by looking at the .pcap capture.

Cheers
Benny

[Régis Montoya]

The two agent used mode 30. (Both are using pjsip with the same config)

But I've just made a test that seems to really improve things :
I've disabled the enhancer (attr->setting.penh = 0;) of ilbc... and by
miracle things are really better now!
I've asked a tester to confirm the behavior but regarding my tests it really
seems to be the reason of the problem.

I did this test because I had a look into the Asterisk code and see that
they *always* disable the enhancer : that's an non configurable flag set to
0 (and they also use

So... good news, and maybe can helps other people with ilbc and low cpu if
confirmed.

To anticipate, if it is really the cause of the issue :
I think that there is no way to disable penh neither in config_site.h nor in
pjsua. Can it be an evolution? I quickely search into the project and saw
that it is enabled for ilbc and speex
(I'll also try to disable it with speex and see if sound is better since
actually it is not as better as I would expect on android - but by far
better than it was with ilbc).

As for me, I can afford to change by hand, but I would suggest you to add an
option for penh.
I assume that a setting in pjsua is not so easy to add, but a precompil flag
to globaly enable / disable enhancers for codecs could be great (or by
codec?)

Thx
Regis

Post by Régis Montoya

Post by Régis Montoya
Don't worry, I have already the good config_site set. (And recently
optimized).
Everything is just fine with all other codecs (and even better, I have

also

Post by Régis Montoya
ported the g729 port from samuel and also work really fine) GSM, speex

etc

Post by Régis Montoya
are fine too. Nexus One has a 1GHz CPU and should be enough to support

ilbc.

Post by Régis Montoya
My point is just a report to help the developer to find out what is going
wrong with ilbc. There is maybe a regression or something bad with it.
That's really strange that 20ms is really good and 30ms become absolutely
unusable? Isn't it?
But if we can support ilbc (as it is announced on the main page of

pjsip),

Post by Régis Montoya
it would be really cool. Well not a necessity but if somebody has an idea

on

Post by Régis Montoya
how to quickly fix it.

The iLBC mode is set to 30ms by default, and I don't recall having any
problems with this mode..
What peer did you use for the test?
According to the spec, if any of the agent uses mode 30, then the
other must also use mode 30, even though it initially indicates that
it uses mode 20 in its SDP. It could be that the peer is still using
mode 20 even though you've set your mode to 30.
And yes we used to have this problem in the past, but this was fixed
months/year ago, so as long as you have relatively recent pjsip
version you should be okay.
This can be easily verified by looking at the .pcap capture.
Cheers
Benny
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Régis Montoya]

Some news about the issue :

Enhancer was probably not the good solution. It reduce used cpu so,
sometimes things are going better.
I've increased the log level and here are new observations :

Sometimes everything goes fine (it is the case when I disable switch board
and remove everything that use CPU). But in most case, it becomes choppy.
With log level set to 5 there is a noticeable difference between the case
where everything is ok and the case were cpu grow up and sound become choppy
:
the difference is that when things are going wrong I get logs like that :

08-18 14:05:13.444: VERBOSE/libpjsip(3151): 14:05:13.445 strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.444: VERBOSE/libpjsip(3151): 14:05:13.452 strm0x40f884
Frame lost!
08-18 14:05:13.503: VERBOSE/libpjsip(3151): 14:05:13.507 strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.513: VERBOSE/libpjsip(3151): 14:05:13.522 strm0x40f884
Frame lost!
08-18 14:05:13.553: VERBOSE/libpjsip(3151): 14:05:13.560 strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.563: VERBOSE/libpjsip(3151): 14:05:13.572 strm0x40f884
Frame lost!

Looping again and again.... (Here plc is disabled else plc also try to do
things and CPU usage is higher and sound more choppy)
And then about each 2/3sec I get something like that :
08-18 14:05:13.843: VERBOSE/libpjsip(3151): 14:05:13.852 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.843: VERBOSE/libpjsip(3151): 14:05:13.852 strm0x40f884
Jitter buffer is bufferring (prefetch=12)
08-18 14:05:13.863: VERBOSE/libpjsip(3151): 14:05:13.868 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.913: VERBOSE/libpjsip(3151): 14:05:13.922 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.934: VERBOSE/libpjsip(3151): 14:05:13.937 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.993: VERBOSE/libpjsip(3151): 14:05:13.997 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.993: VERBOSE/libpjsip(3151): 14:05:13.998 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:14.023: VERBOSE/libpjsip(3151): 14:05:14.027 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:14.053: VERBOSE/libpjsip(3151): 14:05:14.062 strm0x40f884
GET prefetch_cnt=0/12
During this time there is no sound.

I tried to play with jitter buffer init parameter but without any chance. I
don't know exactly what it affects and so it's a little bit foggy for me.
Maybe you'll have a suggestion on what I should try.

What is really really strange is that when things starts well, voice is
really clear and cpu usage is about 15% instead of 80% when it is choppy.

Post by Régis Montoya
The two agent used mode 30. (Both are using pjsip with the same config)
I've disabled the enhancer (attr->setting.penh = 0;) of ilbc... and by
miracle things are really better now!
I've asked a tester to confirm the behavior but regarding my tests it
really seems to be the reason of the problem.
I did this test because I had a look into the Asterisk code and see that
they *always* disable the enhancer : that's an non configurable flag set to
0 (and they also use
So... good news, and maybe can helps other people with ilbc and low cpu if
confirmed.
I think that there is no way to disable penh neither in config_site.h nor
in pjsua. Can it be an evolution? I quickely search into the project and saw
that it is enabled for ilbc and speex
(I'll also try to disable it with speex and see if sound is better since
actually it is not as better as I would expect on android - but by far
better than it was with ilbc).
As for me, I can afford to change by hand, but I would suggest you to add
an option for penh.
I assume that a setting in pjsua is not so easy to add, but a precompil
flag to globaly enable / disable enhancers for codecs could be great (or by
codec?)
Thx
Regis

Post by Régis Montoya

Post by Régis Montoya
Don't worry, I have already the good config_site set. (And recently
optimized).
Everything is just fine with all other codecs (and even better, I have

also

Post by Régis Montoya
ported the g729 port from samuel and also work really fine) GSM, speex

etc

Post by Régis Montoya
are fine too. Nexus One has a 1GHz CPU and should be enough to support

ilbc.

Post by Régis Montoya
My point is just a report to help the developer to find out what is

going

Post by Régis Montoya
wrong with ilbc. There is maybe a regression or something bad with it.
That's really strange that 20ms is really good and 30ms become

absolutely

Post by Régis Montoya
unusable? Isn't it?
But if we can support ilbc (as it is announced on the main page of

pjsip),

Post by Régis Montoya
it would be really cool. Well not a necessity but if somebody has an

idea on

Post by Régis Montoya
how to quickly fix it.

The iLBC mode is set to 30ms by default, and I don't recall having any
problems with this mode..
What peer did you use for the test?
According to the spec, if any of the agent uses mode 30, then the
other must also use mode 30, even though it initially indicates that
it uses mode 20 in its SDP. It could be that the peer is still using
mode 20 even though you've set your mode to 30.
And yes we used to have this problem in the past, but this was fixed
months/year ago, so as long as you have relatively recent pjsip
version you should be okay.
This can be easily verified by looking at the .pcap capture.
Cheers
Benny
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Benny Prijono]

From your description, it looks like you're running out of CPU power,

and there's little if not nothing we can do to help, other than to
suggest to look for more optimized codec version, if you can find one
(like on iPhone we support the built-in iLBC codec). Of all the codecs
that we have, iLBC is the heaviest (due to the implementation that we
have), and we normally disable it on small systems.

-benny

Enhancer was probably not the good solution. It reduce used cpu so,
sometimes things are going better.
Sometimes everything goes fine (it is the case when I disable switch board
and remove everything that use CPU). But in most case, it becomes choppy.
With log level set to 5 there is a noticeable difference between the case
where everything is ok and the case were cpu grow up and sound become choppy
08-18 14:05:13.444: VERBOSE/libpjsip(3151):  14:05:13.445   strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.444: VERBOSE/libpjsip(3151):  14:05:13.452   strm0x40f884
Frame lost!
08-18 14:05:13.503: VERBOSE/libpjsip(3151):  14:05:13.507   strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.513: VERBOSE/libpjsip(3151):  14:05:13.522   strm0x40f884
Frame lost!
08-18 14:05:13.553: VERBOSE/libpjsip(3151):  14:05:13.560   strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.563: VERBOSE/libpjsip(3151):  14:05:13.572   strm0x40f884
Frame lost!
Looping again and again.... (Here plc is disabled else plc also try to do
things and CPU usage is higher and sound more choppy)
08-18 14:05:13.843: VERBOSE/libpjsip(3151):  14:05:13.852   strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.843: VERBOSE/libpjsip(3151):  14:05:13.852   strm0x40f884
Jitter buffer is bufferring (prefetch=12)
08-18 14:05:13.863: VERBOSE/libpjsip(3151):  14:05:13.868   strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.913: VERBOSE/libpjsip(3151):  14:05:13.922   strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.934: VERBOSE/libpjsip(3151):  14:05:13.937   strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.993: VERBOSE/libpjsip(3151):  14:05:13.997   strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.993: VERBOSE/libpjsip(3151):  14:05:13.998   strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:14.023: VERBOSE/libpjsip(3151):  14:05:14.027   strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:14.053: VERBOSE/libpjsip(3151):  14:05:14.062   strm0x40f884
GET prefetch_cnt=0/12
During this time there is no sound.
I tried to play with jitter buffer init parameter but without any chance. I
don't know exactly what it affects and so it's a little bit foggy for me.
Maybe you'll have a suggestion on what I should try.
What is really really strange is that when things starts well, voice is
really clear and cpu usage is about 15% instead of 80% when it is choppy.

[Régis Montoya]

What is strange is that linphone that has also an android version and use
the same ilbc implementation and it works fine :
The begin is choppy but after 3 seconds things become as fine as it is using
pjsip when it works properly.

Is that possible that when things are going wrong at the beggining (when CPU
is the more used) it goes in a state where pjsip try to correct things which
consume more cpu and so it goes worse.
Probably, when things goes wrong, linphone just ignore this (and doesn't try
to restablish things) and as then cpu is less used everything is better
after 2 or 3 seconds of choppy sound.

I repeat but it is really strange that with pjsip sometimes it works
perfectly (and with a better quality than linphone).
Is there a pjsua method I can test that (while in call) reset the rtp stream
reader/writer? (I tried to stop / restart the stream but doesn't seems to
affect network data processing, just the audio one)

From your description, it looks like you're running out of CPU power,
and there's little if not nothing we can do to help, other than to
suggest to look for more optimized codec version, if you can find one
(like on iPhone we support the built-in iLBC codec). Of all the codecs
that we have, iLBC is the heaviest (due to the implementation that we
have), and we normally disable it on small systems.
-benny

Post by Régis Montoya
Enhancer was probably not the good solution. It reduce used cpu so,
sometimes things are going better.
Sometimes everything goes fine (it is the case when I disable switch

board

Post by Régis Montoya
and remove everything that use CPU). But in most case, it becomes choppy.
With log level set to 5 there is a noticeable difference between the case
where everything is ok and the case were cpu grow up and sound become

choppy

Post by Régis Montoya
08-18 14:05:13.444: VERBOSE/libpjsip(3151): 14:05:13.445 strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.444: VERBOSE/libpjsip(3151): 14:05:13.452 strm0x40f884
Frame lost!
08-18 14:05:13.503: VERBOSE/libpjsip(3151): 14:05:13.507 strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.513: VERBOSE/libpjsip(3151): 14:05:13.522 strm0x40f884
Frame lost!
08-18 14:05:13.553: VERBOSE/libpjsip(3151): 14:05:13.560 strm0x40f884
Jitter buffer starts returning normal frames (after 1 empty/lost)
08-18 14:05:13.563: VERBOSE/libpjsip(3151): 14:05:13.572 strm0x40f884
Frame lost!
Looping again and again.... (Here plc is disabled else plc also try to do
things and CPU usage is higher and sound more choppy)
08-18 14:05:13.843: VERBOSE/libpjsip(3151): 14:05:13.852 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.843: VERBOSE/libpjsip(3151): 14:05:13.852 strm0x40f884
Jitter buffer is bufferring (prefetch=12)
08-18 14:05:13.863: VERBOSE/libpjsip(3151): 14:05:13.868 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.913: VERBOSE/libpjsip(3151): 14:05:13.922 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.934: VERBOSE/libpjsip(3151): 14:05:13.937 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.993: VERBOSE/libpjsip(3151): 14:05:13.997 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:13.993: VERBOSE/libpjsip(3151): 14:05:13.998 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:14.023: VERBOSE/libpjsip(3151): 14:05:14.027 strm0x40f884
GET prefetch_cnt=0/12
08-18 14:05:14.053: VERBOSE/libpjsip(3151): 14:05:14.062 strm0x40f884
GET prefetch_cnt=0/12
During this time there is no sound.
I tried to play with jitter buffer init parameter but without any chance.

I

Post by Régis Montoya
don't know exactly what it affects and so it's a little bit foggy for me.
Maybe you'll have a suggestion on what I should try.
What is really really strange is that when things starts well, voice is
really clear and cpu usage is about 15% instead of 80% when it is choppy.

_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Benny Prijono]

Post by Régis Montoya
What is strange is that linphone that has also an android version and use
The begin is choppy but after 3 seconds things become as fine as it is using
pjsip when it works properly.
Is that possible that when things are going wrong at the beggining (when CPU
is the more used) it goes in a state where pjsip try to correct things which
consume more cpu and so it goes worse.

The only thing I can imagine is the log, which the jitter buffer could
write too aggresively on certain circumstances, which may take out
precious processing power since writing to file is a blocking
operation.

Other than that, have a look at config_site_sample.h for suitable
settings for mobile devices, and also
https://trac.pjsip.org/repos/wiki/FAQ#cpu on optimizing PJSIP in
general.

Post by Régis Montoya
Probably, when things goes wrong, linphone just ignore this (and doesn't try
to restablish things) and as then cpu is less used everything is better
after 2 or 3 seconds of choppy sound.
I repeat but it is really strange that with pjsip sometimes it works
perfectly (and with a better quality than linphone).
Is there a pjsua method I can test that (while in call) reset the rtp stream
reader/writer? (I tried to stop / restart the stream but doesn't seems to
affect network data processing, just the audio one)

Doing re-INVITE or UPDATE should restart the stream.

-benny

[Régis Montoya]

Thanks Benny for all this information.

Well at least now I have something absolutely optimized :) (but as I already
found something really similar on the wiki almost all flags was already well
set).
But unfortunately doesn't solve completely the issue - even if CPU usage is
now really reduced (about 20% even when it is going wrong and with iLBC).
There is maybe something to see with floating point build (thanks to Samuel
for the idea, I'll check that) or with my audio driver or the android
streams.

But still a little bit amazing : when it works even if I stop/start audio
stream or hold/reinvite it still works then. And the same consistancy can be
observed when it doesn't work (choppy sound).
I'll do more profiling on my current work and keep you informed if something
new found and that has something to do with pjsip.

Thanks again !
Régis

P.S. : any news about my feature request on penh (voice enhancer) settings
within psjua or/and config site? I still think that it could be really
interesting

Post by Benny Prijono

Post by Régis Montoya
What is strange is that linphone that has also an android version and use
The begin is choppy but after 3 seconds things become as fine as it is

using

Post by Régis Montoya
pjsip when it works properly.
Is that possible that when things are going wrong at the beggining (when

CPU

Post by Régis Montoya
is the more used) it goes in a state where pjsip try to correct things

which

Post by Régis Montoya
consume more cpu and so it goes worse.

The only thing I can imagine is the log, which the jitter buffer could
write too aggresively on certain circumstances, which may take out
precious processing power since writing to file is a blocking
operation.
Other than that, have a look at config_site_sample.h for suitable
settings for mobile devices, and also
https://trac.pjsip.org/repos/wiki/FAQ#cpu on optimizing PJSIP in
general.

Post by Régis Montoya
Probably, when things goes wrong, linphone just ignore this (and doesn't

try

Post by Régis Montoya
to restablish things) and as then cpu is less used everything is better
after 2 or 3 seconds of choppy sound.
I repeat but it is really strange that with pjsip sometimes it works
perfectly (and with a better quality than linphone).
Is there a pjsua method I can test that (while in call) reset the rtp

stream

Post by Régis Montoya
reader/writer? (I tried to stop / restart the stream but doesn't seems to
affect network data processing, just the audio one)

Doing re-INVITE or UPDATE should restart the stream.
-benny
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Nanang Izzuddin]

Hi Régis,

Changing codec penh (perceptual enhancement) default setting at
runtime can be done using pjsua_codec_set_param() or
pjmedia_codec_mgr_set_default_param(), please check the docs for the
details.

BR,
nanang

Post by Régis Montoya
Thanks Benny for all this information.
Well at least now I have something absolutely optimized :) (but as I already
found something really similar on the wiki almost all flags was already well
set).
But unfortunately doesn't solve completely the issue - even if CPU usage is
now really reduced (about 20% even when it is going wrong and with iLBC).
There is maybe something to see with floating point build (thanks to Samuel
for the idea, I'll check that) or with my audio driver or the android
streams.
But still a little bit amazing : when it works even if I stop/start audio
stream or hold/reinvite it still works then. And the same consistancy can be
observed when it doesn't work (choppy sound).
I'll do more profiling on my current work and keep you informed if something
new found and that has something to do with pjsip.
Thanks again !
Régis
P.S. : any news about my feature request on penh (voice enhancer) settings
within psjua or/and config site? I still think that it could be really
interesting

Post by Benny Prijono

Post by Régis Montoya
What is strange is that linphone that has also an android version and use
The begin is choppy but after 3 seconds things become as fine as it is using
pjsip when it works properly.
Is that possible that when things are going wrong at the beggining (when CPU
is the more used) it goes in a state where pjsip try to correct things which
consume more cpu and so it goes worse.

The only thing I can imagine is the log, which the jitter buffer could
write too aggresively on certain circumstances, which may take out
precious processing power since writing to file is a blocking
operation.
Other than that, have a look at config_site_sample.h for suitable
settings for mobile devices, and also
https://trac.pjsip.org/repos/wiki/FAQ#cpu on optimizing PJSIP in
general.

Post by Régis Montoya
Probably, when things goes wrong, linphone just ignore this (and doesn't try
to restablish things) and as then cpu is less used everything is better
after 2 or 3 seconds of choppy sound.
I repeat but it is really strange that with pjsip sometimes it works
perfectly (and with a better quality than linphone).
Is there a pjsua method I can test that (while in call) reset the rtp stream
reader/writer? (I tried to stop / restart the stream but doesn't seems to
affect network data processing, just the audio one)

Doing re-INVITE or UPDATE should restart the stream.
 -benny
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org