Hi David, Those master sound underruns indicate your processor is not able to keep up with media flow. But I don't recall seeing any such messages in your earlier log. To reduce CPU consumption, disable echo cancellation, use fast sample rate conversion, and use PCM codec. And make sure you are running optimized (release) build. Regards, Bill On 3/5/2015 9:43 AM, David Desopper wrote: > Bill, > > I am sorry for my numerous e-mails, but this problem is seriously > bugging me because it is part of my master thesis, deadlines are > creeping in fast. > > When I make a LAN call I get this information: > > Press a to answer or h to reject call > a > Answer with code (100-699) (empty to cancel): 200 > 14:40:39.123 pjsua_call.c !Answering call 0: code=200 > 14:40:39.126 pjsua_media.c ...Call 0: updating media.. > 14:40:39.127 pjsua_aud.c ....Audio channel update.. > 14:40:39.131 strm0x47bb44 .....Encoder stream started > 14:40:39.132 strm0x47bb44 .....Decoder stream started > 14:40:39.140 pjsua_media.c ....Audio updated, stream #0: PCMU (sendrecv) > 14:40:39.141 pjsua_app.c ...Call 0 media 0 [type=audio], status is > Active > 14:40:39.142 pjsua_aud.c ...Conf disconnect: 2 -x- 0 > 14:40:39.144 conference.c ....Port 2 (ring) stop transmitting to > port 0 (Hercules HD Exchange: USB Audio (hw:1,0)) > 14:40:39.146 pjsua_aud.c ...Conf connect: 3 --> 0 > 14:40:39.147 conference.c ....Port 3 (sip:192.168.1.108) > transmitting to port 0 (Hercules HD Exchange: USB Audio (hw:1,0)) > 14:40:39.149 pjsua_aud.c ...Conf connect: 0 --> 3 > 14:40:39.151 conference.c ....Port 0 (Hercules HD Exchange: USB > Audio (hw:1,0)) transmitting to port 3 (sip:192.168.1.108) > 14:40:39.154 Master/sound !Underflow, buf_cnt=0, will generate 1 frame > 14:40:39.153 pjsua_core.c ....TX 889 bytes Response msg > 200/INVITE/cseq=12740 (tdta0x467ad8) to UDP 192.168.1.108:5060: > SIP/2.0 200 OK > Via: SIP/2.0/UDP > 192.168.1.108:5060;rport=5060;received=192.168.1.108;branch=z9hG4bKPj9ErfYX2FuKbD1gEhQCuTMR7bhUmUYzm7 > Call-ID: TR.3BVSkf3YKwlNsrT1D6-P0ffDN.r3X > From: <sip:192.168.1.108>;tag=FJ6rb9ese.ANHOoZ9.CpfWsZxAZxcLzj > To: <sip:192.168.1.124>;tag=mAL2aev6FkoPxy0h2PEHNm6Oi5CaZW90 > CSeq: 12740 INVITE > Contact: <sip:192.168.1.124:5060> > Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, > NOTIFY, REFER, MESSAGE, OPTIONS > Supported: replaces, 100rel, timer, norefersub > Session-Expires: 1800;refresher=uac > Require: timer > Content-Type: application/sdp > Content-Length: 274 > > v=0 > o=- 3634555234 3634555235 IN IP4 192.168.1.124 > s=pjmedia > b=AS:84 > t=0 0 > a=X-nat:0 > m=audio 4000 RTP/AVP 0 96 > c=IN IP4 192.168.1.124 > b=TIAS:64000 > a=rtcp:4001 IN IP4 192.168.1.124 > a=sendrecv > a=rtpmap:0 PCMU/8000 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-16 > > --end msg-- > 14:40:39.161 pjsua_app.c .......Call 0 state changed to CONNECTING > >>> 14:40:39.169 pjsua_core.c .RX 352 bytes Request msg > ACK/cseq=12740 (rdata0x45c2bc) from UDP 192.168.1.108:5060: > ACK sip:192.168.1.124:5060 SIP/2.0 > Via: SIP/2.0/UDP > 192.168.1.108:5060;rport;branch=z9hG4bKPjTBaR1hYODm1YOsSjR9ZXhlQzY211Rw0u > Max-Forwards: 70 > From: <sip:192.168.1.108>;tag=FJ6rb9ese.ANHOoZ9.CpfWsZxAZxcLzj > To: sip:192.168.1.124;tag=mAL2aev6FkoPxy0h2PEHNm6Oi5CaZW90 > Call-ID: TR.3BVSkf3YKwlNsrT1D6-P0ffDN.r3X > CSeq: 12740 ACK > Content-Length: 0 > > > --end msg-- > 14:40:39.171 ec0x46e880 !Underflow, buf_cnt=0, will generate 1 frame > 14:40:39.176 pjsua_app.c ...Call 0 state changed to CONFIRMED > 14:40:39.243 ec0x46e880 !Underflow, buf_cnt=0, will generate 1 frame > 14:40:39.374 Master/sound Underflow, buf_cnt=0, will generate 1 frame > 14:40:39.431 Master/sound Underflow, buf_cnt=0, will generate 1 frame > 14:40:39.488 Master/sound Underflow, buf_cnt=0, will generate 1 frame > 14:40:39.544 Master/sound Underflow, buf_cnt=0, will generate 1 frame > 14:40:39.592 Master/sound Underflow, buf_cnt=0, will generate 1 frame > > > Can this be the cause? > > On 2015-03-05 15:24, David Desopper wrote: >> Never mind my last remark. The sampling rate has nothing to do with it. >> >> Bill, can you tell me how to make calls within the same lan? >> >> >> On 2015-03-05 15:06, David Desopper wrote: >>> Bill, >>> >>> I now believe that this is a audio hardware issue instead of >>> something else. To get my USB headset working, I have to set the >>> clock-rate at 48kHz, can this be causing the problem in your >>> opinion? This would shift the problem from PJSIP to Raspberry Pi >>> hardware. >>> >>> >>> On 2015-03-04 10:36, David Desopper wrote: >>>> Bill, >>>> >>>> I normally did use a turn server in both endpoints. I will try your >>>> solution and get back to you as soon as I did. >>>> >>>> Thank you, >>>> David >>>> >>>> Bill Gardner schreef op 3/03/2015 om 22:29: >>>>> Hi David, >>>>> >>>>> OK. I see the call is connecting via a turn relay. Did you set up >>>>> the ubuntu endpoint to use turn? It's surprising that ice didn't >>>>> negotiate using the local RTP addresses on your LAN. Actually I >>>>> can see that ice tests the local connection and it succeeds: >>>>> >>>>> 15:09:57.513 icetp00 ICE negotiation success after 0s:201 >>>>> 15:09:57.515 icetp00 Comp 1: sending from host candidate 192.168.1.124:4015 to host candidate 192.168.1.110:4033 >>>>> 15:09:57.516 icetp00 Comp 2: sending from host candidate 192.168.1.124:4001 to host candidate 192.168.1.110:4024 >>>>> But then rasberry proceeds to use the media relay which seems >>>>> wrong to me. I don't understand ice well enough to parse the issue >>>>> from the logs. >>>>> >>>>> One suggestion is to drop all the registrar and ice/turn/stun >>>>> options at both endpoints and just make the call between the LAN >>>>> addresses, that should work and will verify you have working >>>>> endpoints. Then you can go through the registrar and enable ice, >>>>> which should negotiate the local RTP addresses. Then add turn >>>>> relay to one or both endpoints. It should still use the local RTP >>>>> addresses I would think. >>>>> >>>>> Regards, >>>>> >>>>> Bill >>>>> >>>>> On 3/3/2015 3:35 PM, David Desopper wrote: >>>>>> Bill, >>>>>> >>>>>> Thanks for your effort. I try to make calls between a pjsua >>>>>> client on a raspberry on one side and a pjsua client on an ubuntu >>>>>> system inside the same lan. I ran through the same steps on both >>>>>> end sytems. It is puzzeling me for a while now and I don't have a >>>>>> doubt in my mind that it's just me that's doing something >>>>>> stupidly wrong. >>>>>> >>>>>> Bill Gardner schreef op 3/03/2015 om 21:28: >>>>>>> Hi David, >>>>>>> >>>>>>> The call stats show 8 packets sent and 449 received during an 8 >>>>>>> second call. Given that you've checked the sound device using cc >>>>>>> 0 0 it's puzzling that you don't hear any audio during calls. >>>>>>> Are you sure the other endpoint is functional? One suggestion is >>>>>>> to first make point to point calls between pjsip clients on >>>>>>> your LAN before trying to connect to external clients. Another >>>>>>> idea is to use wireshark to capture the RTP stream. >>>>>>> >>>>>>> The log looks OK to me, although I would expect more packets to >>>>>>> be sent with vad off. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> On 3/3/2015 10:18 AM, David Desopper wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> For my master thesis I'm trying to use the pjsip libraries for >>>>>>>> incorperated inside my own software project. But I can't seem >>>>>>>> to be able to get pjsua working. Something clearly is going >>>>>>>> wrong, but I have no idea what the problem seems to be. If I >>>>>>>> check the sound quality paramaters during a call, I can see >>>>>>>> that I am not transmitting any sound packets, but also, I can't >>>>>>>> hear any sound that clearly is received. >>>>>>>> >>>>>>>> I did all the steps mentioned here: >>>>>>>> https://trac.pjsip.org/repos/wiki/Audio_Problems/Getting_Around_Nat >>>>>>>> but without succes. >>>>>>>> >>>>>>>> I also checked that my audio device is working by doing the >>>>>>>> command cc 0 0 to echo my microphone input sound to my output. >>>>>>>> >>>>>>>> Pjsua is initialized like this: >>>>>>>> >>>>>>>> ./pjsua-arm-unknown-linux-gnueabihf --clock-rate=48000 >>>>>>>> --capture-dev=0 --playback-dev=0 --use-ice >>>>>>>> --id=sip:XXX at sip.antisip.com --registrar=sip:sip.antisip.com >>>>>>>> --realm=* --username=XXX --password=*** >>>>>>>> --stun-srv=stun.pjsip.org --no-vad >>>>>>>> >>>>>>>> I think that the most important output is this: >>>>>>>> >>>>>>>> 15:10:06.492 pjsua_app_comm ! >>>>>>>> [CONFIRMED] To: >>>>>>>> <sip:XXX at sip.antisip.com>;tag=kiGDpg9qCdBHKMLgabtKNN1RR-6zUtNP >>>>>>>> Call time: 00h:00m:08s, 1st res in 7505 ms, conn in 7779ms >>>>>>>> #0 audio PCMU @8kHz, sendrecv, peer=91.121.78.130:51526 >>>>>>>> SRTP status: Not active Crypto-suite: >>>>>>>> ICE role: Controlled, state: Negotiation Success, >>>>>>>> comp_cnt: 2 >>>>>>>> [0]: L:192.168.1.124:4015 (h) --> >>>>>>>> R:192.168.1.110:4033 (h) >>>>>>>> [1]: L:192.168.1.124:4001 (h) --> >>>>>>>> R:192.168.1.110:4024 (h) >>>>>>>> RX pt=0, last update:00h:00m:08.808s ago >>>>>>>> total 449pkt 71.8KB (89.8KB +IP hdr) >>>>>>>> @avg=62.8Kbps/78.5Kbps >>>>>>>> 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 2.247 9.250 0.750 1.971 >>>>>>>> TX pt=0, ptime=20, last update:00h:00m:04.429s ago >>>>>>>> total 8pkt 1.2KB (1.6KB +IP hdr) @avg=1.1Kbps/1.3Kbps >>>>>>>> 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 : 0.000 0.000 0.000 0.000 0.000 >>>>>>>> RTT msec : 4.425 4.425 4.425 4.425 0.000 >>>>>>>> >>>>>>>> >>>>>>>> I included the full log of the call in attachment. >>>>>>>> >>>>>>>> Thanks for your help >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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/20150305/dfc422a2/attachment.html>
