| Summary: | ASTERISK-28200: res_rtp_asterisk: Duplicate DTMF with endpoint when media received in between | ||||
| Reporter: | Aiden Donnelly (237aidend) | Labels: | |||
| Date Opened: | 2018-12-07 04:29:29.000-0600 | Date Closed: | 2019-04-18 09:32:35 | ||
| Priority: | Minor | Regression? | Yes | ||
| Status: | Closed/Complete | Components: | Resources/res_rtp_asterisk | ||
| Versions: | 13.24.0 | Frequency of Occurrence | Frequent | ||
| Related Issues: |
| ||||
| Environment: | Asterisk Realtime, chan_sip, web_rtc components, rfc2833, alaw | Attachments: | ( 0) rtp_debug.txt | ||
| Description: | See Support from jcolp. https://community.asterisk.org/t/dtmf-issue-since-upgrade-from-11-21-to-13-24-1/77517/9
There seems to be an extra packet of audio in the middle of DTMF on confbridge pin. 13.23.1 has no problems. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2018-12-07 04:29:30.835-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: Joshua C. Colp (jcolp) 2018-12-07 04:45:44.545-0600 [~alexei gradinari] This is the issue I was referencing on your Gerrit review a few minutes ago. By: Alexei Gradinari (alexei gradinari) 2018-12-07 09:30:32.506-0600 Aiden Donnelly, can you provide pcap of rtp stream, which is causing a duplicate DTMF? By: Alexei Gradinari (alexei gradinari) 2018-12-07 10:51:14.006-0600 I'm very interesting what are these packets {noformat} [Dec 6 21:40:08] Got RTP packet from xx.xx.xx.xx:16658 (type 08, seq 013726, ts 1912421673, len 000040) [Dec 6 21:40:08] Got RTP packet from xx.xx.xx.xx:16658 (type 08, seq 013738, ts 1912423185, len 000040) [Dec 6 21:40:08] Got RTP packet from xx.xx.xx.xx:16658 (type 08, seq 013749, ts 1912424465, len 000040) [Dec 6 21:40:08] Got RTP packet from xx.xx.xx.xx:16658 (type 08, seq 013761, ts 1912425897, len 000040) [Dec 6 21:40:09] Got RTP packet from xx.xx.xx.xx:16658 (type 08, seq 013783, ts 1912429017, len 000040) {noformat} Is VAD enabled at SIP client? By: Joshua C. Colp (jcolp) 2018-12-10 14:28:25.981-0600 Can you provide the information [~alexei gradinari] asked for? By: Alexei Gradinari (alexei gradinari) 2018-12-19 16:13:44.936-0600 The RTP marker bit is also normally set on Comfort Noise packets. So my patch is wrong. We must not rely on marker bit to reset DTMF last sequence number and timestamp. A new patch https://gerrit.asterisk.org/10829 is on review, which reset DTMF last sequence number and timestamp on RTP renegotiation. By: Benjamin Keith Ford (bford) 2019-04-17 16:09:05.958-0500 Hey [~237aidend], I'm currently looking in to this issue but would like to know if you are still experiencing problems and if so, can you provide relevant configs? I've tested with a simple conference bridge, but no luck reproducing the issue, so more details would help. By: Joshua C. Colp (jcolp) 2019-04-18 09:32:35.382-0500 After further digging what happened is that the original change which caused this regression was reverted. A new change was done in a different manner which did not suffer from this problem. If you are still experiencing a problem comment with the details [~bford] mentioned and this will re-open. If all is good, you don't need to do anything! | ||||