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

Rusty Newton (JIRA) noreply at issues.asterisk.org
Wed Feb 26 17:30:05 CST 2014


Rusty Newton created ASTERISK-23380:
---------------------------------------

             Summary: One way audio issues with WebRTC - PJNATH limits number of ICE candidates
                 Key: ASTERISK-23380
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23380
             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


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



More information about the asterisk-bugs mailing list