My setup is not a bi-directional call. It is uni-directional audio or audio/video involving an mcu. Once sender, many receivers. I had it all working with Chrome, and now reworking it for FF.
In my very first tests with FF 22 as a sender of audio, it seems to stop sending after a few seconds. The MCU is not sending RRs to the sender. Also, since FF does not do STUN refreshes, that would mean that the sender has zero inbound traffic. So, I think that I need to give the sender an RR or binding refresh. This is on a LAN, so NAT is not being used. I will dig into it further, and if it still looks like a problem, then I'll collect the debug info as you suggest, or just provide a working repro. Thanks On Tue, Jul 2, 2013 at 6:40 AM, Randell Jesup <[email protected]> wrote: > On 7/1/2013 11:25 PM, [email protected] wrote: > >> Thank you. >> >> Chrome sends RR on a newly established connection, even when no data is >> being received yet. I don't see FF (22 or nightly) doing this, and I >> don't >> know what the right behavior is. >> > > We shouldn't be generating RR's in a normal call. Since we're doing > bidirectional audio, we'll send SR's (which is what I'm seeing). If we were > to send an RTCP *before* our first audio packet, that one would be an RR. > For video, there may be cases where we'd send two RTCPs inbetween frames, > in which case the second would have an RR (if we're not doing RFC 5506). > However, until bug 864654 lands, Video RTCP will have only RR's (and > PLI's/NACKS, etc). > > > When I set up FF 22 as a sender (to my mcu) I see that it sends out audio >> packets, but stops after a short time. Nightly does not stop sending >> data. >> Does Firefox 22 need to receive binding refreshes or RRs in order to >> keep >> sending data? >> > > Well, in the longer run it will need something like that. However, I'm > not sure what the reason would be (it may be correct, I just can't be sure > from that short description); please try a Debug build of 22 and set > NSPR_LOG_MESSAGES=signaling:5,**mtransport:5 NSPR_LOG_FILE=whatever and > upload logs to a bug. Also please describe the scenario in more detail, > and include a wireshark capture if possible. > > Thanks > > -- > Randell Jesup, Mozilla > > ______________________________**_________________ > dev-media mailing list > [email protected] > https://lists.mozilla.org/**listinfo/dev-media<https://lists.mozilla.org/listinfo/dev-media> > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
