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

Sun Feb 23 22:18:03 CST 2014

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

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

Asterisk doesn't do much other than present pjnath with the candidates that it received. I will say that it seems odd that all of the candidates have the same priority:

{noformat}
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
{noformat}

I'd say the next step is to dig into pjproject's {{pj_ice_sess_create_check_list}}. My guess - from looking at that particular function - is that you have a local candidate with an address of 192.x.x.x and that it thinks there might be a path between the two private networks. Since I'm not sure what local candidates you had, that's just a wild guess, however.

I know that Jonathan has a patch on ASTERISK-23213 that fixes some aspects of how remote and local candidates are matched up, but I think that had implications more with re-INVITEs than the initial offer/answer. It may be worth trying.

> 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