| Summary: | ASTERISK-23337: One way audio issues with WebRTC - PJNATH limits number of ICE candidates | ||||
| Reporter: | NITESH BANSAL (nbansal) | Labels: | |||
| Date Opened: | 2014-02-21 03:03:33.000-0600 | Date Closed: | 2017-12-18 10:40:04.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Resources/res_rtp_asterisk | ||
| Versions: | 11.4.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Debian wheezy x86 64 | Attachments: | ( 0) webrtc.pcap | ||
| Description: | 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. | ||||
| Comments: | By: NITESH BANSAL (nbansal) 2014-02-21 03:05:30.462-0600 attached is the PCAP trace for this issue. I would really appreciate if i could get a pointer on how and where to start debugging for this issue. By: Matt Jordan (mjordan) 2014-02-23 22:16:24.735-0600 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. By: NITESH BANSAL (nbansal) 2014-02-25 10:19:47.144-0600 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 By: Matt Jordan (mjordan) 2014-02-25 11:14:10.136-0600 So, this is partially similar at least to the problem Jonathan is working on. I'd propose a patch here for Asterisk 11 that increases the number of allowed candidates. That we can put into the embedded pjproject. For the other, go ahead and create a patch for pjproject and push it up stream to them. It's still worthwhile to fix, even if we don't fix it in Asterisk itself. By: Rusty Newton (rnewton) 2014-02-26 17:31:24.843-0600 Nitesh, I've opened the issue and assigned it to you. By: Matt Jordan (mjordan) 2014-02-27 16:49:21.343-0600 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). By: Joshua C. Colp (jcolp) 2017-12-18 10:40:04.485-0600 We now use a bundled PJSIP and our configuration allows a maximum of 32 candidates, thus resolving this issue. | ||||