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

Reply via email to