Summary:	ASTERISK-30119: res_pjsip_sdp_rtp: Timeout doesn't handle bundled streams
Reporter:	Joe Searle (jsearle)	Labels:	webrtc
Date Opened:	2022-06-30 09:31:26	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Resources/res_pjsip_sdp_rtp
Versions:	16.24.0 16.25.0 16.26.0 16.27.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) endpoint.txt ( 1) video_recvonly.pcap ( 2) video_sendrecv.pcap
Description:	Since upgrading from 16.22.0 to 16.27.0 when making outbound calls from my sip client (webrtc) I have been noticing Asterisk has been dropping the calls slightly after the 60 second mark with the notice {quote}[Jun 30 13:05:34] NOTICE[20479]: res_pjsip_sdp_rtp.c:149 rtp_check_timeout: Disconnecting channel 'PJSIP/softphone-web-6-00000002' for lack of video RTP activity in 65 seconds{quote} I used git bisect to track down the issue to this commit {quote}14156f9827eb0caa4e3b64bafce318e475a12b68{quote} The related jira issue is ASTERISK-28890 Prior to this change I wouldn't have any issue with Asterisk dropping the calls. I thought that the problem was that the INVITE sent from the endpoint to Asterisk was set to *recvonly* on the video stream and that Asterisk wasn't checking whether it should be receiving the video RTP before it adds the applies the rtp_timeout to it. This does not seem to be the case however because I tested enabling video in the softclient before making another attempt so it was set to *sendrecv* but I still have the problem with video being sent to Asterisk. Reading the linked jira issue the change relates to *rtp_keepalive* which I don't have enabled on the endpoints. I will attach the endpoints settings and a pcap once I figure out how. The only work around I have found so far is to disable rtp_timeout on the endpoints which isn't ideal.
Comments:	By: Asterisk Team (asteriskteam) 2022-06-30 09:31:28.897-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. 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: Joe Searle (jsearle) 2022-06-30 09:39:32.167-0500 I have attached two pcaps, one where the endpoint just wants to receive video and one where it also sends video. I have also attached the settings for the pjsip endpoint. By: Joshua C. Colp (jcolp) 2022-06-30 09:42:07.846-0500 The underlying issue is that in a bundled scenario all streams flow over a single RTP instance, so all the others instead never show as receiving media. The timeout code doesn't take this into account. By: Torbjörn Abrahamsson (tobbe) 2022-08-11 03:36:06.078-0500 We encountered the same problem using 18.12.1, while not having the issue with 18.8.0. Is someone looking at this? We will probably revert the patch referred to above to solve our needs, as we feel unsure if we can construct a correct solution at the moment. By: Torbjörn Abrahamsson (tobbe) 2022-08-11 06:32:24.900-0500 Could it possibly as easy as changing: session_media->type == AST_MEDIA_TYPE_VIDEO to: (session_media->type == AST_MEDIA_TYPE_VIDEO && !session_media->bundled) in the second of the two changes in the patch mentioned in the description? By: Joshua C. Colp (jcolp) 2022-08-11 06:38:52.752-0500 There is noone actively working on this issue. I don't know if that is the correct fix or not. By: Torbjörn Abrahamsson (tobbe) 2022-08-11 06:55:07.183-0500 Alright, we will test our small change, and see if it resolves our problems. If so we will submit the patch for review. By: Torbjörn Abrahamsson (tobbe) 2022-08-15 04:24:20.416-0500 To follow up, my proposed solution did not work. We ended up partially reverting the aforementioned patch. My initial guess was that it was the second of the two changes that were the culprit, as it had code pertaining to keepalives, and the first seemed to be about moh. This proved to be wrong, as removing the video part of the first if statement gave the desired result. This can probably be solved in a more correct way, but it made our video calls not drop anymore.