The sdp that I provided is after setLocalDescription, so that extra candidate is not actually removed. I got the final offer/answer SDP after the pc transitioned to the connected state.
I have verified that no handshake happens on the rtcp candidate, so there is no problem that I can see beyond some confusion. On Mon, Oct 28, 2013 at 11:54 AM, Ethan Hugg <[email protected]> wrote: > > Yes, that is what we're doing, the latest bug on it is here - > https://bugzilla.mozilla.org/show_bug.cgi?id=907353 > > We don't decide that we're doing rtcp-mux for sure at CreateAnswer,but > instead at the subsequent call to SetLocalDescription. That's where we > currently disable the second ICE component. Until then we keep advertising > two components in case they're needed. > > I don't know if removing the rtcp-mux line is something we will allow in > editing between CreateAnswer and SetLocalDescription since that is not well > defined yet by the working group, but this behavior would allow that in the > future. If the current behavior is breaking a use case that you have > please file a bug and explain. Thanks. > > -EH > > > > On Mon, Oct 28, 2013 at 11:35 AM, <[email protected]> wrote: > >> Running under latest Aurora (26 a2) I provide an offer containing rtcp-mux >> and a single candidate. >> >> The answer that FF generates also contains rtcp-mux and completes the >> handshake, however, it also contains separate candidates for rtp and rtcp >> as you can see in the following answer candidates: >> a=candidate:0 1 UDP 2130182399 192.168.4.100 55249 typ host >> a=candidate:0 2 UDP 2130182398 192.168.4.100 61662 typ host >> >> So, why is FF still generating separate rtcp candidates even though >> rtcp-mux is negotiated? >> >> Thanks >> >> offer: >> v=0 >> o=- 1 2 IN IP4 0.0.0.0 >> s=- >> t=0 0 >> a=ice-ufrag:w/HHF2TlNbGZREl >> a=ice-pwd:efgUgfL1Q9B8d1+k6n5UnUj9 >> a=fingerprint:sha-256 >> >> 28:AB:43:F1:A5:C3:98:9D:44:39:4E:DF:4A:04:E8:39:42:22:E8:E4:9D:35:D4:70:7F:87:77:B0:75:D8:88:AB >> m=audio 1 RTP/SAVPF 111 >> c=IN IP4 0.0.0.0 >> a=rtcp:1 >> a=rtcp-mux >> a=sendrecv >> a=candidate:0 1 udp 2130714367 192.168.4.101 6028 typ host >> a=rtpmap:111 opus/48000/2 >> a=fmtp:111 >> >> PROFILE=0;LEVEL=0;packetization-mode=0;level-asymmetry-allowed=1;parameter-add=1;maxaveragebitrate=18000;usedtx=0;stereo=0;useinbandfec=0;cbr=0 >> >> answer: >> v=0 >> o=Mozilla-SIPUA-26.0a2 19140 0 IN IP4 0.0.0.0 >> s=SIP Call >> t=0 0 >> a=ice-ufrag:ef806e02 >> a=ice-pwd:9d292b008cddbca8c38f2b3ca2f6c2f0 >> a=fingerprint:sha-256 >> >> 64:9C:D6:C1:C8:7C:BD:C9:C5:9F:D5:26:13:30:55:4B:24:10:48:F5:06:B6:8A:BC:1A:FC:F1:74:65:98:48:F4 >> m=audio 55249 RTP/SAVPF 111 >> c=IN IP4 (redacted) >> a=rtpmap:111 opus/48000/2 >> a=ptime:20 >> a=sendrecv >> a=setup:active >> a=candidate:0 1 UDP 2130182399 192.168.4.100 55249 typ host >> a=candidate:1 1 UDP 1694040063 173.160.212.118 55249 typ srflx raddr >> 192.168.4.100 rport 55249 >> a=candidate:2 1 UDP 2128609535 10.211.55.2 63245 typ host >> a=candidate:4 1 UDP 2128543999 10.37.129.2 59790 typ host >> a=candidate:0 2 UDP 2130182398 192.168.4.100 61662 typ host >> a=candidate:1 2 UDP 1694040062 173.160.212.118 61662 typ srflx raddr >> 192.168.4.100 rport 61662 >> a=candidate:2 2 UDP 2128609534 10.211.55.2 52190 typ host >> a=candidate:4 2 UDP 2128543998 10.37.129.2 61460 typ host >> a=rtcp-mux >> _______________________________________________ >> dev-media mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-media >> > > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
