Malformed RTCP on AppRTC

[James Criscuolo]

Hi,

  I've been trying to improve video quality through our FreeSWITCH servers (where some of our WebRTC traffic may end up going), and the problem seems to be related to RTCP. The further I get from a key frame, the more artifacts I get, whether I am in Chrome or Firefox.

Upon doing a few Wiresharks, I noticed that malformed RTCP packets are coming from the browser as well as FreeSWITCH. Taking FreeSWITCH out of the picture, I still see these malformed packets when  I use https://apprtc.appspot.com/. There doesn't seem to be any specific pattern to which packets are malformed, and for all I know I may need to tweak Wireshark to correctly interpret some packets (I was thinking it was all compound packets, but the malformed ones are the same length as some correctly parsed ones).

The artifacts and degrading quality are worse in Firefox, but they also appear in Chrome. I was not able to see any discernible difference in the malformed RTCP packets between them, but I need to investigate that further. The degrading quality does not seem to affect straight browser-to-browser calls (no server in the middle), so I'm guessing FreeSWITCH can probably deal with the malformed packets in a more appropriate manner, but I'm still curious if there is a way to avoid malformed packets altogether.

I'm still wading through understanding RTCP, so is there anybody who knows if this is expected, or how it's supposed to be dealt with?

Thanks,
James

[Byron Campen]

    How specifically are these packets malformed?

Best regards,
Byron Campen

--

---
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/d/optout.

[Randell Jesup]

On 5/20/2015 5:04 PM, James Criscuolo wrote:
> Hi,
> I've been trying to improve video quality through our FreeSWITCH
> servers (where some of our WebRTC traffic may end up going), and the
> problem seems to be related to RTCP. The further I get from a key
> frame, the more artifacts I get, whether I am in Chrome or Firefox.
>
> Upon doing a few Wiresharks, I noticed that malformed RTCP packets are
> coming from the browser as well as FreeSWITCH. Taking FreeSWITCH out
> of the picture, I still see these malformed packets when I
> use https://apprtc.appspot.com/.

You can't use Wireshark to look into the innards of RTCP packets (or
beyond the header of an RTP packet) with WebRTC. The reason:
encryption. Basically you're looking at TTY noise....

Turn on internal logs (in firefox NSPR_LOG_MODULES=webrtc_trace:65535
WEBRTC_TRACE_FILE=whatever), but that doesn't dump RTCP per se, though a
number of things in RTCP do get logged.

--
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randel...@jesup.org! Way too much spam

[Matthew Hodgson]

On 20/05/2015 23:09, Randell Jesup wrote:
> On 5/20/2015 5:04 PM, James Criscuolo wrote:
>> Hi,
>> I've been trying to improve video quality through our FreeSWITCH
>> servers (where some of our WebRTC traffic may end up going), and the
>> problem seems to be related to RTCP. The further I get from a key
>> frame, the more artifacts I get, whether I am in Chrome or Firefox.
>>
>> Upon doing a few Wiresharks, I noticed that malformed RTCP packets are
>> coming from the browser as well as FreeSWITCH. Taking FreeSWITCH out
>> of the picture, I still see these malformed packets when I use
>> https://apprtc.appspot.com/.
>
> You can't use Wireshark to look into the innards of RTCP packets (or
> beyond the header of an RTP packet) with WebRTC. The reason:
> encryption. Basically you're looking at TTY noise....
>
> Turn on internal logs (in firefox NSPR_LOG_MODULES=webrtc_trace:65535
> WEBRTC_TRACE_FILE=whatever), but that doesn't dump RTCP per se, though a
> number of things in RTCP do get logged.

Alternatively, you can presumably use FreeSWITCH to turn the SRTP into
plain SIP+RTP, assuming it bridges the RTP/RTCP through intact. A pcap
the broken stream might be revealing, if the contents isn't too sensitive :)

Incremental corruption of inter frames sounds like you might be hitting
particularly nasty packet loss or MTU problems.

M

--
Matthew Hodgson
Matrix.org

[James Criscuolo]

> How specifically are these packets malformed?

Wireshark does not really give much good information. I've attached a few packets from the AppRTC case as an example. The first packet is one of the error cases, the second is a valid packet, and the third received a warning (make sure to hit Analyze -> Decode As -> 'RTP' or 'RTCP'). It should be noted that while the types of the packets are 'Generic RTCP feedback' and 'Unknown,' The malformed packets come in many different types.

> You can't use Wireshark to look into the innards of RTCP packets (or 
> beyond the header of an RTP packet) with WebRTC.  The reason: 
> encryption.  Basically you're looking at TTY noise.... 

When you say 'innards' would that include the extra pieces of a compound packet? For instance, it looks like I can send a Sender Report from FreeSWITCH with an FIR as well as a PLI, yet I never seem to see anything after the fact that it's a Sender Report. Also, the warning packet I've attached references something about the frame length check coming out different than expected. This seems to be the best information that these packets hold, but does it mean anything helpful?

> Turn on internal logs (in firefox NSPR_LOG_MODULES=webrtc_trace:65535 
> WEBRTC_TRACE_FILE=whatever), but that doesn't dump RTCP per se, though a 
> number of things in RTCP do get logged.

I've tried using the firefox logs and have only really seen messages about RTCP initializing, or something to that effect, but nothing really mid call. Is there anything specifically I should look for?

> Alternatively, you can presumably use FreeSWITCH to turn the SRTP into 
> plain SIP+RTP, assuming it bridges the RTP/RTCP through intact.  A pcap 
> the broken stream might be revealing, if the contents isn't too sensitive :) 
> 
> Incremental corruption of inter frames sounds like you might be hitting 
> particularly nasty packet loss or MTU problems. 

The packets I've attached are from the AppRTC example, which is very easily reproducible. If you'd like, I can also post a pcap of my FreeSWITCH instance, but as far as I could tell the information wasn't any different. I could also post a more complete log, if necessary.

In terms of my FreeSWITCH case, I'm using a box that doesn't have any other traffic on it besides the one video call. I haven't looked into pulling out the RTCP data there, but I'll start on that now. I'll also try to confirm if it bridges the RTP/RTCP through untouched, as I would expect it to. Routing the packets through this server would lead to longer round-trip times, but as long as the round-trip times are properly calculated that shouldn't be a factor, right?

James

[Peter Boström]

If you're wiresharking encrypted packets you're essentially trying to decode white noise. SRTCP doesn't encrypt the first 64 bits of a RTCP packet, see RFC3711, section 3.4 for a nice graph.

--