Summary:	ASTERISK-30428: bridging: Music on hold continues after INVITE with replaces
Reporter:	David Middleton (dave-midd)	Labels:
Date Opened:	2023-02-14 17:11:06.000-0600	Date Closed:	2023-04-10 12:07:21
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Bridges/bridge_native_rtp Bridges/bridge_simple Bridges/bridge_softmix
Versions:	18.14.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) 20230130_teams-pstn_teams-pstn_merge_pjsip_nok_asterisk_anon.pcap ( 1) 20230214_pcap_breakdown.txt ( 2) 2023022000_debug_log_ASTERISK-30428.txt ( 3) 2023022100_debug_log_ASTERISK-30428.txt
Description:	Party A calls Party B. Party A puts Party B on hold and Asterisk plays moh to Party B. Party A then calls Party C. Party A then merges the two calls (to Party B and Party C) - a new INVITE is received by asterisk replacing the original held call to Party B. Asterisk continues to send music on hold to Party B, as well as the media from the new replacement call, all using the same SSRC and UDP ports, but with different timestamps and sequence numbers (causing Party B to hear broken moh and audio). Media from party B is ok, as well as media to/from Parties A and C. I've attached an anonymised pcap that shows all the SIP signalling, but for simplification, just the egress RTP (to/from Party B and C). I've also attached a pcap breakdown text file. I did try unloading 'bridge_simple' as suggested in ASTERISK-29273 but the issue remained.
Comments:	By: Asterisk Team (asteriskteam) 2023-02-14 17:11:08.969-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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. 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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: David Middleton (dave-midd) 2023-02-14 17:11:59.376-0600 Attached pcap and description. By: Joshua C. Colp (jcolp) 2023-02-15 05:42:53.664-0600 We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: David Middleton (dave-midd) 2023-02-20 11:39:07.537-0600 Please find attached '2023022000_debug_log_ASTERISK-30428.txt'. (Apologies for the delay - I've been away.) By: Joshua C. Colp (jcolp) 2023-02-21 08:57:53.637-0600 Can you please provide a mapping of the of the channel name to the party identifier in your description? As well, this does not appear to be debug level logging but merely verbose and a spot of notice. By: David Middleton (dave-midd) 2023-02-21 10:01:15.383-0600 Thanks Joshua. That's odd about the logging - I ran 'logger add channel 2023022000_debug_log_ASTERISK-30428 notice,warning,error,debug,verbose,dtmf' from the asterisk CLI. Did I miss something? In '2023022000_debug_log_ASTERISK-30428.txt': Party A calling Party B ingress: PJSIP/219-astpjsip-00000006 egress: PJSIP/proxy-00000007 Party A calling Party C ingress: PJSIP/proxy-00000008 egress: PJSIP/proxy-00000009 By: David Middleton (dave-midd) 2023-02-21 10:18:53.661-0600 Apologies. I hadn't set the log levels. This is more helpful - 2023022100_debug_log_ASTERISK-30428.txt Party A calling Party B ingress: PJSIP/219-astpjsip-00000014 egress: PJSIP/proxy-00000015 Party A calling Party C ingress: PJSIP/219-astpjsip-00000016 egress: PJSIP/proxy-00000017 By: David Middleton (dave-midd) 2023-02-21 10:34:42.944-0600 Should have added to the above: When Party A merges the two calls ingress: PJSIP/219-astpjsip-00000018 (replaces PJSIP/219-astpjsip-00000014) PJSIP/proxy-00000015 is the channel that now has two RTP streams with the same SSRC; the music on hold continued from when PJSIP/219-astpjsip-00000014 put the call on hold plus the media from the replacement PJSIP/219-astpjsip-00000018, resulting in the called party hearing broken bits of both streams. By: Henning Westerholt (henningw) 2023-03-15 08:22:19.312-0500 We observed a similar problem: - A (client behind SBC/SIP proxy) originates outbound call to PSTN gateway to B number - A put party B on hold - client sends Inactive in SDP, Asterisk sends sendonly towards proxy - A originates outbound call to PSTN gateway C party - call is answered - in call - A choose to merge the calls from the client - Client sends new INVITE with replaces header and instruct Asterisk to do call swap - Asterisk do call swap so B is in call with C - Asterisk hangup call with A as is supposed to do based on the INVITE with replaces header - Asterisk doesn't send any re-INVITE towards PSTN gateway to release B party from hold - Call between B and C stays in call until B or C party hangup but B is having MoH. C can hear B - A party can leave call without interrupting call between B and C Expected behaviour would be that A is in a call together with B and C. This was tested successfully with another PBX. In case of eventual patches, just let me know, we can easily support with testing. By: Henning Westerholt (henningw) 2023-03-20 08:51:42.353-0500 We have a patch that fixes the issue, currently running the test suite to see if there are any regressions. Is there already another patch available? Otherwise I would prepare a gerrit task for that. By: Joshua C. Colp (jcolp) 2023-03-20 08:57:51.656-0500 There is no patch attached here and no patch on Gerrit, so unless someone has one and has not disclosed it there doesn't appear to be one. By: Henning Westerholt (henningw) 2023-03-20 10:15:14.261-0500 Thanks for the confirmation. There was the ASTDEV issue linked which I can't open. Then I will continue with the tests. By: Henning Westerholt (henningw) 2023-03-21 03:20:04.316-0500 I have attached the patch. I tested it several times with the pjsip tests in the test suites, looked fine.Additional tests and of course review of course welcome. By: Henning Westerholt (henningw) 2023-03-21 06:41:26.127-0500 This was in fact already reported two years ago in ASTERISK-29469. The gerrit change was aparently never finalized. Will add a note to the older issue linking to this. By: David Middleton (dave-midd) 2023-03-21 06:54:27.372-0500 Thanks for the patch, Henning. Just a note that our issue was slightly different, in that we don't relay the hold upstream and the issue was asterisk sending two simultaneous RTP streams (one with MOH and the other with the user audio from the bridge) on the same SSRC and UDP ports. Having said that, your patch to 'unhold' on the replaces may well prevent this from happening. We'll be testing it today/tomorrow and I'll update here. Thanks again for your time and effort. By: Henning Westerholt (henningw) 2023-03-21 07:13:42.598-0500 Thanks for the reply, looking forward to your results. We did not looked to much into the RTP side of "our" issue, as it was already broken from a signaling point of view. By: David Middleton (dave-midd) 2023-03-22 05:51:29.963-0500 Good morning Henning. I'm happy to say that your patch has also fixed our issue. As soon as the INVITE with replaces was processed, the held party stops receiving moh audio and starts to receive the bridged audio from the other call leg (and there was just a single RTP stream.) Awesome, thanks. (I don't suppose you fancy looking at ASTERISK-30454 - I suspect that one's not quite as straightforward!) By: Henning Westerholt (henningw) 2023-03-22 06:06:12.041-0500 Thanks for the confirmation, good news. Lets wait for some feedback from the asterisk developers. Regarding the NOTIFY sipfrag, this is actually rather easy to workaround in Kamailio or similar. By: Henning Westerholt (henningw) 2023-03-30 02:12:57.757-0500 Hello, any update regarding the patch? Thank you. By: Joshua C. Colp (jcolp) 2023-03-30 04:34:37.728-0500 Any updates or comments will be posted on the Gerrit review. By: Friendly Automation (friendly-automation) 2023-04-10 12:07:22.803-0500 Change 20050 merged by Friendly Automation: chan_pjsip: fix music on hold continues after INVITE with replaces [https://gerrit.asterisk.org/c/asterisk/+/20050|https://gerrit.asterisk.org/c/asterisk/+/20050] By: Friendly Automation (friendly-automation) 2023-04-10 12:07:27.724-0500 Change 20020 merged by Friendly Automation: chan_pjsip: fix music on hold continues after INVITE with replaces [https://gerrit.asterisk.org/c/asterisk/+/20020|https://gerrit.asterisk.org/c/asterisk/+/20020] By: Friendly Automation (friendly-automation) 2023-04-10 13:36:02.260-0500 Change 20051 merged by George Joseph: chan_pjsip: fix music on hold continues after INVITE with replaces [https://gerrit.asterisk.org/c/asterisk/+/20051|https://gerrit.asterisk.org/c/asterisk/+/20051]