[asterisk-bugs] [JIRA] (ASTERISK-23337) One way audio issues with WebRTC

Tue Feb 25 10:20:03 CST 2014

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215640#comment-215640 ] 

NITESH BANSAL commented on ASTERISK-23337:
------------------------------------------

Hi Matt,

I figured out the root cause.
PJNATH imposes a limit on number of ICE candidates (16) and number of ICE checks (32).
In my case, 14 candidates are proposed and during ICE handshake, 6 new peer reflexive candidates are discovered and PJNATH stops accepting candidates after
it reaches the limit of 16 and hence ICE handshake doesn't happen.
I have increased the limit for number of remote candidates and number of ICE checks and it seems fine.
We still need to do few more tests, if those tests are okay, i can submit the patch here, if required.
Since the patch is concerned with PJNATH, i am not sure if it is required as i understand that PJNATH will be removed from asterisk source in future.

Regards,
Nitesh Bansal

> One way audio issues with WebRTC 
> ---------------------------------
>
>                 Key: ASTERISK-23337
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23337
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 11.4.0
>         Environment: Debian wheezy x86 64
>            Reporter: NITESH BANSAL
>         Attachments: webrtc.pcap
>
>
> Hello ,
> I am using Asterisk 11.4 to make WebRTC calls.
> I am having one way audio issues in certain scenarios.
> Analysis Failure case:
> --------------------------------
> INVITE sent from browser:
> v=0^M
> o=- 546074467646554532 2 IN IP4 127.0.0.1^M
> s=-^M
> t=0 0^M
> a=group:BUNDLE audio^M
> a=msid-semantic: WMS 9oVZAJxsBQKy0FFy9FyYvp3OlN4xNHHknuuC^M
> m=audio 33746 RTP/SAVPF 111 103 104 0 8 106 105 13 126^M
> c=IN IP4 194.183.244.5^M
> a=rtcp:33746 IN IP4 194.183.244.5^M
> a=candidate:1679965505 1 udp 2113937151 10.1.5.116 50461 typ host generation 0^M
> a=candidate:1679965505 2 udp 2113937151 10.1.5.116 50461 typ host generation 0^M
> a=candidate:2999745851 1 udp 2113937151 192.168.56.1 42208 typ host generation 0^M
> a=candidate:2999745851 2 udp 2113937151 192.168.56.1 42208 typ host generation 0^M
> a=candidate:3890964107 1 udp 2113937151 10.1.65.38 47247 typ host generation 0^M
> a=candidate:3890964107 2 udp 2113937151 10.1.65.38 47247 typ host generation 0^M
> a=candidate:2265168813 1 udp 1845501695 194.183.244.5 33746 typ srflx raddr 10.1.5.116 rport 50461 generation 0^M
> a=candidate:2265168813 2 udp 1845501695 194.183.244.5 33746 typ srflx raddr 10.1.5.116 rport 50461 generation 0^M
> a=candidate:715243953 1 tcp 1509957375 10.1.5.116 0 typ host generation 0^M
> a=candidate:715243953 2 tcp 1509957375 10.1.5.116 0 typ host generation 0^M
> a=candidate:4233069003 1 tcp 1509957375 192.168.56.1 0 typ host generation 0^M
> a=candidate:4233069003 2 tcp 1509957375 192.168.56.1 0 typ host generation 0^M
> a=candidate:2842204795 1 tcp 1509957375 10.1.65.38 0 typ host generation 0^M
> a=candidate:2842204795 2 tcp 1509957375 10.1.65.38 0 typ host generation 0^M
> a=ice-ufrag:olXlAxnuMOs4Lro/^M
> a=ice-pwd:5XHaFtt6AnMTGzGEH838T+vP^M
> a=ice-options:google-ice^M
> a=fingerprint:sha-256 2A:89:A9:D9:08:1B:56:1F:68:91:51:46:98:02:95:38:65:C3:F2:6E:DC:FD:F5:7D:C2:BD:8F:D9:4B:CC:39:61^M
> a=setup:actpass^M
> a=mid:audio^M
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level^M
> a=sendrecv^M
> a=rtcp-mux^M
> a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:jY2eb+Kf9rWU8RrD0c0A/MEef/M15jAiTMkx/XaZ^M
> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:vj3FFZX3DEIKpS+FcHgp89aqPuHvSGdMEICgKaeQ^M
> a=rtpmap:111 opus/48000/2^M
> a=fmtp:111 minptime=10^M
> a=rtpmap:103 ISAC/16000^M
> a=rtpmap:104 ISAC/32000^M
> a=rtpmap:0 PCMU/8000^M
> a=rtpmap:8 PCMA/8000^M
> a=rtpmap:106 CN/32000^M
> a=rtpmap:105 CN/16000^M
> a=rtpmap:13 CN/8000^M
> a=rtpmap:126 telephone-event/8000
> a=maxptime:60^M
> a=ssrc:2744681183 cname:A3AoKceVBFkjBBi0^M
> a=ssrc:2744681183 msid:9oVZAJxsBQKy0FFy9FyYvp3OlN4xNHHknuuC 9oVZAJxsBQKy0FFy9FyYvp3OlN4xNHHknuuCa0^M
> a=ssrc:2744681183 mslabel:9oVZAJxsBQKy0FFy9FyYvp3OlN4xNHHknuuC^M
> a=ssrc:2744681183 label:9oVZAJxsBQKy0FFy9FyYvp3OlN4xNHHknuuCa0
> Asterisk 2xx response ::
> v=0^M
> o=root 972456278 972456278 IN IP4 81.201.82.213^M
> s=Inum^M
> c=IN IP4 81.201.82.213^M
> t=0 0^M
> m=audio 12256 RTP/SAVPF 8 0 126^M
> a=rtpmap:8 PCMA/8000^M
> a=rtpmap:0 PCMU/8000^M
> a=rtpmap:126 telephone-event/8000^M
> a=fmtp:126 0-16^M
> a=silenceSupp:off - - - -^M
> a=ptime:20^M
> a=ice-ufrag:2a1217a53e86c40c66e149bd57f769d6^M
> a=ice-pwd:6eb2a7476f494b160d39df395af10d01^M
> a=candidate:H51c952d5 1 UDP 2130706431 x.x.x.x 12256 typ host^M
> a=candidate:H51c952d5 2 UDP 2130706430 x.x.x.x 12257 typ host^M
> a=connection:new^M
> a=setup:active^M
> a=fingerprint:SHA-256 F2:F6:3F:50:01:EF:89:B3:D5:8C:9B:D2:A9:FA:3A:5B:61:0C:67:E1:8B:AA:65:4C:A0:14:45:49:BE:F0:42:69^M
> a=sendrecv^M
> Call is connected, but i observed in chrome://webrtc-internals and saw that packets received by the browser is "ZERO".
> Analysing it further with a PCAP trace, i realized that asterisk is STUN binding request to one of the host candidates (which is a private IP) proposed in the incoming INVITE.
> It doesn't attmept other candidates.
> Interesting observation if i disable one of my local interface created by Oracle VM virtual box(192.168.56.1), everything is fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira