| Summary: | ASTERISK-25867: [patch] Video delay on app_echo | ||||
| Reporter: | Jacek Konieczny (jkonieczny) | Labels: | |||
| Date Opened: | 2016-03-25 10:32:53 | Date Closed: | 2016-04-19 09:24:41 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Applications/app_echo | ||
| Versions: | 13.7.2 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | SIPML5 WebRTC client in Firefox or Chrome browser. | Attachments: | |||
| Description: | After patching around broken DTLS SRTP for RTCP (ASTERISK-25642) app_echo, started after an audio prompt is played, would still not work correctly. Video would show only after a few minutes, when a new full reference frame is sent.
This is because video frames are forwarded only after all DTLS handshakes are finished and app_echo is started. Any reference frame received earlier would be lost and the caller is not informed about it in any way. Chrome would send FIR requests immediately, but those would not be forwarded by app_echo. Other clients might not even send the FIR request and expect the reference frame to come on time. I have made a patch which fixes this behaviour in both cases. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-03-25 10:32:53.893-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]. | ||||