Summary:	ASTERISK-27845: Codec-Change Re-INVITE during DTMF can cause marker bit error
Reporter:	Torrey Searle (tsearle)	Labels:	patch
Date Opened:	2018-05-09 08:20:59	Date Closed:	2018-05-24 14:56:59
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_rtp_asterisk
Versions:	13.20.0	Frequency of Occurrence	Occasional
Related Issues:
Environment:		Attachments:	( 0) codec_B.log ( 1) dtmf_reinvite_race.tgz ( 2) full.txt ( 3) patch
Description:	There is a race condition between Codec changing re-invites and DTMF. If a call is transcoding (in simple_bridge) and during relaying a DTMF digit a RE-INVITE that caused a migration to native bridge arrives the marker bit could be set on the wrong packet. What happens is that re-invite arrives and the local bridge is activated.  At this time FLAG_NEED_MARKER_BIT gets set on the B leg by ast_rtp_local_bridge the A leg afterwards stops sending the DTMF and resumes sending audio.  This packet arrives into bridge_p2p_rtp_write  however as the B leg is still in the middle of the DTMF (it still has to send the 3 end frames) the function returns -1 and the packet is forwarded via the simple bridge with the old ssrc.  However despite this packet still being associated with the old source,  the FLAG_NEED_MARKER_BIT will get cleared in rtp_raw_write. When the next packet  of audio get sent by the A leg, it will be forwarded by the local bridge as the DTMF is over.  This will be the first RTP packet B receives with the SSRC of A but the marker bit won't be set because the flag has already been consumed by the previous packet
Comments:	By: Asterisk Team (asteriskteam) 2018-05-09 08:21:00.996-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: Torrey Searle (tsearle) 2018-05-09 08:22:11.033-0500 attached is a test that can (sometimes) reproduce the issue.  For this test to work the rtpdump tool must be installed By: Torrey Searle (tsearle) 2018-05-09 08:25:30.743-0500 Attached is a dump of the RTP received from asterisk. Line 29 is the packet with the incorrect marker bit By: Torrey Searle (tsearle) 2018-05-09 08:26:21.034-0500 attached is the asterisk log corresponding to the issue By: Torrey Searle (tsearle) 2018-05-09 08:36:28.052-0500 attached is a patch that resolves the issue By: Friendly Automation (friendly-automation) 2018-05-24 14:57:00.466-0500 Change 8948 merged by Joshua Colp: res/res_rtp_asterisk: ensure marker bit is correctly set on ssrc change [https://gerrit.asterisk.org/8948|https://gerrit.asterisk.org/8948] By: Friendly Automation (friendly-automation) 2018-05-24 15:10:58.461-0500 Change 8989 merged by Joshua Colp: res/res_rtp_asterisk: ensure marker bit is correctly set on ssrc change [https://gerrit.asterisk.org/8989|https://gerrit.asterisk.org/8989] By: Friendly Automation (friendly-automation) 2018-05-24 15:11:19.560-0500 Change 8988 merged by Joshua Colp: res/res_rtp_asterisk: ensure marker bit is correctly set on ssrc change [https://gerrit.asterisk.org/8988|https://gerrit.asterisk.org/8988]