[asterisk-bugs] [JIRA] (ASTERISK-23337) One way audio issues with WebRTC - PJNATH limits number of ICE candidates

Thu Feb 27 16:50:05 CST 2014

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

Matt Jordan commented on ASTERISK-23337:
----------------------------------------

Nitesh - Jonathan just fixed a number of one way audio issues in r409129/409130. There's also another patch to fix an issue with a new offer containing new remote candidates being handled properly - see https://reviewboard.asterisk.org/r/3275. There's a pretty decent chance that one or the other of these fixes your bug (in particular, the second).

> One way audio issues with WebRTC - PJNATH limits number of ICE candidates
> -------------------------------------------------------------------------
>
>                 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
>            Assignee: 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