PJSUA on Raspberry sound issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150303/a8eef98e/attachment.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux