[Home]

Summary:ASTERISK-25897: RTCP feedback broken for video streams
Reporter:Jacek Konieczny (jkonieczny)Labels:
Date Opened:2016-04-07 07:31:29Date Closed:2020-01-14 11:13:51.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:
Versions:13.8.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Video streaming over RTP relies on RTCP feedback messages for error connection and stream integrity. The messages used to be defined for a specific payload (RFC 2032 for H.261), but now more generic protocol is available: AVPF (RFC 4585 – transport layer NACK and payload specific: PLI, SLI, RPSI) and RFC 5104 adding more on top of AVPF, including FIR.

Of all those asterisk has some minimal support for RFC 2032 FIR for H.261 and RFC 5104 FIR for VP8. In fact, every other RFC 4585 payload specific feedback message is treated like it is FIR.

This kind of works, but is inefficient and wrong, as RFC 5104 explicitly states:

{quote}
Using the FIR command to recover from errors is explicitly
disallowed, and instead the PLI message defined in AVPF \[RFC4585\]
should be used.  The PLI message reports lost pictures and has been
included in AVPF for precisely that purpose.
{quote}

If AVPF PLI or NACK is received due to a lost packet, Asterisk would translate it to FIR and request a whole key frame. The video source might comply and waste bandwidth or ignore too frequent FIR messages and provide no correction for the error.

On the other hand, neither PLI or NACK should be sent to Asterisk if Asterisk negotiated only {{ccm fir}} for {{a=rtcp-fb}} in the SDP.

Asterisk doesn't handle video directly (only passes it through), so it cannot react to payload-specific feedback directly. It doesn't  keep forwarded frames, so it won't be able to react to generic NACKs  either. What is left is forwarding the feedback to the video source, but this should not be limited to FIR messages.

How should it be handled? A new frame type? Data added to the AST_CONTROL_VIDUPDATE frames (currently used for FIR messages)? A new AST_FRAME_CONTROL subclass?

Raw RTCP packages cannot be forwarded, as SSRC and sequence numbers are different on the two legs of the stream, the packets would have to be recreated. What should be the format for the data in the forwarded frames?

Note, that a single incoming RTCP packed may be a compound packet and contain multiple feedback messages together with RR/SR and SDES and currently {{ast_rtcp_read()}} can return only a single frame.

How can we compute original RTP packet sequence number for a forwarded feedback message (which referenced sequence number generated by asterisk, in the forwarded RTP stream)?

How should the SDP negotiation be handled for {{rtcp-fb}} parameters? Should asterisk announce every message type it can forward? It is not known in advance what the other party (where the stream is to be forwarded) can handle.
Comments:By: Asterisk Team (asteriskteam) 2016-04-07 07:31:29.691-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Joshua C. Colp (jcolp) 2016-04-07 08:00:24.896-0500

I think this would be a discussion to have on the asterisk-dev mailing list where everyone can see. Not many peruse the issue tracker for such things.

By: Jacek Konieczny (jkonieczny) 2016-04-07 08:52:46.682-0500

Ok, I will move the discussion, as soon as I am subscribed there.

By: Rusty Newton (rnewton) 2016-04-11 20:35:48.814-0500

I'm going to set this for Waiting on Feedback. Remember to update this issue in the couple weeks with the results of the discussion. Thanks!

By: Asterisk Team (asteriskteam) 2016-04-26 12:00:01.456-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines