Re: Full Intraframe Request (FIR) being ignored in latest Chrome?

[Bryan]

Try turning on chrome's debug logging on the receiving end to see what is happening with the FIRs. 

I saw a similar issue with PLIs not being processed and the solution was that the server had to continue sending reverse binds:

https://groups.google.com/forum/?fromgroups=#!topic/discuss-webrtc/rWmkZndd_ds

[Justin Uberti]

One thing that was mentioned (I believe) in the M27 release notes is that Chrome now requires the "a=rtcp-fb:* ccm fir" attribute to request use of FIR, as indicated in RFC 5104. Same thing for "nack" as specified in RFC 4585. (I don't think this went into M26 though.)

This won't affect normal applications, as these lines are included by default in createOffer/createAnswer-generated SDPs, but if you are rolling your own you'll need to make sure these lines are present.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bryan]

I'm glad you mentioned this -- I had no idea it had changed.

From http://tools.ietf.org/html/rfc4585#section-6.3 -- it looks like I need a=rtcp-fb:* nack pli in my offer if I want to use PLI?

What is the consequence of ignoring the application specific feedback that Chrome generates?

[Mark]

Thanks Bryan, I've not done much debugging of Chrome but I don't seem to get the level of events necessary to see the actual RTP/RTCP processing... I'm using "chrome.exe --enable-logging --v=4 --vmodule=*libjingle/source/talk/*=3" (also tried several other variations)... do you know what params are necessary for that level?

I am continuing the periodic ICE bindings, although in my testing, even a very early FIR is ignored...

[Mark]

Thanks Justin, yeah I had read about that as well, but I'm not seeing Chrome 26 put out any rtcp SDP attributes, other than "a=rtcp:1 IN IP4 0.0.0.0" and "a=rtcp-mux"... right, I realize I'm not a "normal application" per se, so I'm having to deal with this from an interop standpoint... I'll definitely add the attribute for the next release... Mark.

[Bryan]

Mark,

I don't recall the exact command that I used but it sure looked a lot like yours.  And I don't think that the logs were detailed about RTCP handling -- it's just that there was an error about a non-stun packet from an unreadable connection.  Not the clearest error ever.

And I was sending PLIs not FIRs but that should not matter.

However, when I execute the following JS:

(new webkitRTCPeerConnection(null)).createOffer(function(o){console.log(o.sdp)},function(){},{mandatory:{OfferToReceiveAudio:true,OfferToReceiveVideo:true}});

I see that the offer contains FIR and NACK, but no PLI -- does this mean Chrome is not supporting PLI by default after M27?

a=rtcp-fb:100 ccm fir

a=rtcp-fb:100 nack

[Mark]

Ok, I do see "Sending STUN ping" and "Received STUN ping response" log events, but no stun-related or connection errors...

My Chrome 26 is definitely *not* putting out rtcp-fb attributes... switching to Beta channel Chrome 27 definitely *does* give me the same two attributes.

I modified my SDP response to include:
a=rtcp-fb:{X} ccm fir
a=rtcp-fb:{X} nack
but it doesn't seem to have an impact, i.e. no apparent errors in the debug, and no key-frame kicked back.

One thing to note is I'm not doing DTLS, I'm using SRTP... I wonder if that's having an impact on this (I'm sending SRTCP FIR instead of some unknown -to me- way of doing that in DTLS).

At least I know that my 3000 frames number was right:
webrtcvideoengine.cc(3373)] VP8 options : picture loss indication = 0, feedback mode = 0, complexity = normal, resilience = off, denoising = 0, error concealment = 0, automatic resize = 0, frame dropping = 1, key frame interval = 3000

I'd like to just do the FIR, but I'm wondering if there's a script/app way of reducing that key frame interval anyway... I'll guess not...

[Bryan]

I discovered a hack to force a key frame from script and also a bug in SRTP handling.  On an established connection, on the sender side, do the following:

pc.setRemoteDescription(pc.remoteDescription,function(){

  pc.setLocalDescription(pc.localDescription,function(){});

});

that causes the sender to emit a key frame, with the side effect that it [incorrectly] resets the rollover count.  Were it not for the ROC bug, that would be a good way to get a key from script.  

[Justin Uberti]

:-0

The ROC thing you mention is a pretty nasty bug; we've heard isolated reports of it, but you just pointed out the core problem. We will try to fix this ASAP.

[Justin Uberti]

https://code.google.com/p/webrtc/issues/detail?id=1657

[Mark]

Glad you all uncovered a ROC issue... I can't tell you the time I wasted on a device mishandling a crypto context reset when coming off hold.

As far as the FIR being ignored, I uncovered the issue... apparently I was establishing the media stream at our server at the time of the ICE binding instead of upon media reception - so I didn't have a proper sender SSRC... the correct sender SSRC is required for the FIR.  It's not clear how the timing changed but in the end, I was able to resolve (As an aside, I can get the proper SSRC from the SDP if "a=ssrc:" is present... I may update that as well)... thanks for the comments! 

[Lorenzo Miniero]

I've started to get this issue as well... I've checked what happened to both you and Bryan and it doesn't seem to apply to me. Connectivity checks work fine (no ICE-lite), the RTCP FIR is constructed using the correct SSRCs, audio and video work fine in both way using both SDES and DTLS, but Chrome simply seems to ignore RTCP FIR messages, which means that, as pointed out, I only seem to be able to get a key frame every 3000 frames. I've tried debugging in Chrome using the  --enable-logging --v=4 --vmodule=*libjingle/source/talk/*=3 arguments, but there's no output after the media starts flowing.

This worked up until a few days/weeks ago, but it seems to be failing for me in both Chrome 27 and 28, on Linux. Has anything changed that may be causing this issue?

Thanks,

Lorenzo

[Sergio Garcia Murillo]

Hi Lorenzo,

I have seen this issue also from time to time but have not been able to isolate it. In some cases it even seems that it stopped working at the middle of an established call.

By the way, does chrome handles FIR and PLI exactly the same way or what are the differences in behavior?

Best regards
Sergio

[Mark Pietras]

FYI the FIR seems to be OK working for me currently on Chrome 27.0.1453.93 on Windows but I haven't done exhaustive testing on it...

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/PLbYI6we7hY/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Gustavo García]

There is a change in Chrome 27 in the NACK/PLI support. Now it is negotiated in the SDP. I don't know how are you testing it but make sure you have "a=rtcp-fb" lines in your SDP.
https://code.google.com/p/webrtc/issues/detail?id=1727

[Justin Uberti]

Yes - if you are generating your own SDP (i.e. not using createOffer/Answer, or sending from a non-browser device) you need to properly signal a=rtcp-fb:ccm fir to enable FIR support. See the beginning of this thread, or the M27 release notes.

[Dennis E. Dowhy]

A few questions related to this discussion -

- Does PLI need to be signaled?  I keep the default 'a=rtcp-fb:100 ccm fir' & 'a=rtcp-fb:100 nack' in my SDP and in all my testing, I've seen NACKs and PLI's and TMMBN's but I've never seen chrome generate any FIR before, though I'm not quite sure how to 'trigger' it.  I can usually get PLI's triggered though be introducing some packet loss.

- in a 'late joiner' scenario with an RTP translator, how does one signal the current ROC to the late joiner?  Does WebRTC support signaling of ROC in any way or are all middleboxes forced to basically recrypt everything for each output?  I've seen some IETF drafts on EKT but I didn't see whether or not if WebRTC supported this or planned on supporting it.

Also, I am assuming that the ROC fix described above is in all versions now 27+ and canary, correct?

[Justin Uberti]

On Thu, May 23, 2013 at 7:27 PM, Dennis E. Dowhy <ddo...@gmail.com> wrote:

A few questions related to this discussion -

- Does PLI need to be signaled?  I keep the default 'a=rtcp-fb:100 ccm fir' & 'a=rtcp-fb:100 nack' in my SDP and in all my testing, I've seen NACKs and PLI's and TMMBN's but I've never seen chrome generate any FIR before, though I'm not quite sure how to 'trigger' it.  I can usually get PLI's triggered though be introducing some packet loss.

- in a 'late joiner' scenario with an RTP translator, how does one signal the current ROC to the late joiner?  Does WebRTC support signaling of ROC in any way or are all middleboxes forced to basically recrypt everything for each output?  I've seen some IETF drafts on EKT but I didn't see whether or not if WebRTC supported this or planned on supporting it.

You can't. I suggest simply re-encrypting - it's not that expensive, and it prevents having to rekey when someone leaves the conference. 

Also, I am assuming that the ROC fix described above is in all versions now 27+ and canary, correct?

Yes. 

[Lorenzo Miniero]

Yes, I forgot t mention that we do negotiate it in the SDP as suggested some time ago. Anyway, I may have found some more debugging information on the Chrome side, so I'll let you know if I find anything relevant when I get to the lab.

[Lorenzo Miniero]

I just looked at a log I generated on Windows (apparently I can't seem to enable the same debug on Linux? at least that's why I couldn't find anyting there), and there actually is something that is most definitely causing the issue, that is a bunch of:

[3364:2972:0523/174219:VERBOSE3:srtpfilter.cc(627)] SRTP event: SSRC collision

[3364:2972:0523/174219:VERBOSE2:srtpfilter.cc(542)] Failed to unprotect SRTCP packet, err=7

[3364:2972:0523/174219:VERBOSE1:channel.cc(814)] Failed to unprotect video RTCP packet: size=78, type=200

[3364:2972:0523/174219:VERBOSE2:srtpfilter.cc(542)] Failed to unprotect SRTCP packet, err=7

[3364:2972:0523/174219:VERBOSE1:channel.cc(814)] Failed to unprotect video RTCP packet: size=34, type=206

that appear from time to time. Apparently Chrome fails to decide the SRTCP messages we send. Looking into this, I verified that SRTCP packets can be decoded fine when using SDES, but not if DTLS-SRTP is used: I only noticed it now since we made the DTLS-SRTP constraint the default as soon as we got it working on our side. Any hint on that?

I also found a post in this group which may be related, even if the post is quite old (January) and so it may be a long shot:

      https://groups.google.com/forum/#!msg/discuss-webrtc/-IBw4kMW-n8/htd_7ACQjNIJ

The cause there was an older version of libsrtp than the one Chrome used. Which version is Chrome currently using? We use 1.4.4 wth the rdb.c patch that fixes a well known issue in the library:

      http://srtp.cvs.sourceforge.net/viewvc/srtp/srtp/crypto/replay/rdb.c?r1=1.4&r2=1.5

is Chrome using 1.5 instead, and may this be the cause of the problem, or should I be looking somewhere else?

Thanks,

Lorenzo

[Justin Uberti]

It's unlikely that the version of libsrtp is the issue. Did you use different keys for RTCP? DTLS-SRTP has separate keying for RTP and RTCP, whereas SDES uses the same keys for both.

[Bryan]

Justin, Would RTP and RTCP get different crypto contexts if they are MUX'd on the same port?  

I have not yet implemented DTLS so I'm not sure I understand how that could happen.

[Bossiel]

Single crypto if mux'd.

Sent from my iPhone

On May 28, 2013, at 19:02, Bryan <bryand...@gmail.com> wrote:

Justin, Would RTP and RTCP get different crypto contexts if they are MUX'd on the same port?  

I have not yet implemented DTLS so I'm not sure I understand how that could happen.

[Mamadou]

missing word is "key" -> single/same "key".

On May 28, 7:39 pm, Bossiel <boss...@yahoo.fr> wrote:
> Single crypto if mux'd.
>
> Sent from my iPhone
>

[Justin Uberti]

If rtcp-mux is used, they will share the same crypto context, regardless of SDES/DTLS.

From Lorenzo's message, I couldn't tell if rtcp-mux was being used.

[Lorenzo Miniero]

That's definitely is, then, we don't use rtcp-mux, which is why we needed to set up DTLS for both RTP and RTCP in order to get the call to work in the first place. I gave for granted that, despite the separate key exchange, the key would eventually be the same, considering it would when muxed: I'll work in that direction to get this fixed.

Thanks,

Lorenzo