| Summary: | ASTERISK-27440: Strictrtp has issues to qualify video rtp streams | ||||
| Reporter: | Wim De Vlaminck (wim.devlaminck@eyepea.eu) | Labels: | |||
| Date Opened: | 2017-11-22 02:51:49.000-0600 | Date Closed: | 2017-12-15 12:00:55.000-0600 | ||
| Priority: | Major | Regression? | Yes | ||
| Status: | Closed/Complete | Components: | Resources/res_rtp_asterisk | ||
| Versions: | 13.18.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) example.tgz | |||
| Description: | We have noticed difficulties with video doorphones since the rtpbleed fix.
On this setup we have devices behind nat on a publically hosted asterisk. Incoming calls need to have both audio and video rtp streams qualified. For audio there's never a problem, but video doesn't get qualified. The cli logs non stop "dropping due to strict RTP protection. Will switch to it in 3 packets." After some digging I've found that disabling strictrtp resoved the issue. After some more digging I've found why strictrtp was causing problems. There's a check that compares the arrival time to the arrival time since the last rtp packet. If it's less than 5 ms the rtp packet is rejected and the qualifying counter is reset. For voice rtp you should get an rtp packet every 20 ms so that 5 ms limit seems reasonable. The problem for video is that when a single frame doesn't fit into a single rtp packet, it creates multiple rtp packets and sends them one after the other with no delay, causing the "flood of packets". A possible workaround could be that the option strictrtp is not limited to yes/no but maybe has an extra option audioonly. I'm not sure if it's possible to know if an rtp stream is audio or video? If not, maybe there could be an option in rtp.conf of payload type to not apply strict rtp on? I managed to bypass the qualifying based on payloadtype 99 and added the option in rtp.conf. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-11-22 02:51:50.432-0600 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: Richard Mudgett (rmudgett) 2017-11-22 14:08:45.271-0600 Does the https://gerrit.asterisk.org/#/c/7237/ patch for ASTERISK-27421 help? By: Wim De Vlaminck (wim.devlaminck@eyepea.eu) 2017-11-23 09:09:15.108-0600 Richard, It does seem to help. It takes a few tries but it seems the video stream always gets qualified. I suppose it would still fail when using a high enough bitrate. Will this patch make it into production? By: Richard Mudgett (rmudgett) 2017-11-23 13:46:14.141-0600 Actually, that patch was about to go in until you posted this issue. :) We may have to tweak it some or merge it and create a follow on patch to better accommodate video. Could you attach a pcap with the SIP negotiations and RTP streams as a sample of what is happening? Thanks By: Wim De Vlaminck (wim.devlaminck@eyepea.eu) 2017-11-24 07:14:27.191-0600 As requested. Ive added the logs from res_rtp_asterisk as well. When i applied your patch, I also added a line of logging, that's where the flooding messages come from. Rgds, Wim. By: Wim De Vlaminck (wim.devlaminck@eyepea.eu) 2017-11-24 08:09:35.250-0600 The attachment didn't open, this should be better. By: Richard Mudgett (rmudgett) 2017-11-27 11:05:42.548-0600 Although the ASTERISK-27421 patch improves the learning of video streams, a follow-on patch is needed to more reliably learn video streams. By: Richard Mudgett (rmudgett) 2017-12-13 19:00:53.480-0600 Patch up for review. See the Gerrit Reviews tab. By: Friendly Automation (friendly-automation) 2017-12-15 12:00:56.846-0600 Change 7573 merged by Jenkins2: res_rtp_asterisk.c: Disable packet flood detection for video streams. [https://gerrit.asterisk.org/7573|https://gerrit.asterisk.org/7573] By: Friendly Automation (friendly-automation) 2017-12-15 12:15:57.991-0600 Change 7574 merged by Jenkins2: res_rtp_asterisk.c: Disable packet flood detection for video streams. [https://gerrit.asterisk.org/7574|https://gerrit.asterisk.org/7574] By: Friendly Automation (friendly-automation) 2017-12-15 12:16:44.917-0600 Change 7575 merged by Jenkins2: res_rtp_asterisk.c: Disable packet flood detection for video streams. [https://gerrit.asterisk.org/7575|https://gerrit.asterisk.org/7575] | ||||