Summary:	ASTERISK-28110: rtp: Incorrect Packetization
Reporter:	Robert Cripps (bobcripps)	Labels:	patch
Date Opened:	2018-10-16 02:10:13	Date Closed:	2018-11-19 09:36:41.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip_sdp_rtp Resources/res_rtp_asterisk
Versions:	13.24.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Debian Jessie	Attachments:	( 0) 0051_rtp_ptime.patch
Description:	SDP ptime attribute is not honoured even if you set use ptime=true. In the transcode case (Alaw to Ulaw) the ptime was being discarded. In the native bridge case the framing was never checked.
Comments:	By: Asterisk Team (asteriskteam) 2018-10-16 02:10:14.760-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: Robert Cripps (bobcripps) 2018-10-16 02:25:01.106-0500 I am currently unable to upload attachments or use Gerrit because my account is not authorized By: Joshua C. Colp (jcolp) 2018-10-16 04:23:09.835-0500 Contributions require signing the license agreement at the top of JIRA. Once done it is reviewed by legal and if accepted you are able to upload patches and participate in Gerrit. By: Joshua C. Colp (jcolp) 2018-10-16 04:23:47.207-0500 Assigning to you per license agreement signing need. By: Robert Cripps (bobcripps) 2018-10-17 07:46:21.141-0500 Attached our internal patch By: George Joseph (gjoseph) 2018-10-26 13:00:32.716-0500 Hi Robert, We're having an issue understanding how this is happening.  Can you give us more detail including the endpoint configurations used by the two legs  and what devices are at the ends of the legs and their configurations? Also, do you have transcode_via_sln turned on in asterisk.conf?  If it's off, can you try with it on and see if the issue is still happening.  Not that that's a solution but it would give us more data. Finally, can you do a test with Asterisk 16 and see if you have the same issue?  Not saying that's a solution either but the stream handling changed significantly in 16 and it would help to know if this is a 13-only problem. Thanks. By: Robert Cripps (bobcripps) 2018-10-29 04:31:12.641-0500 Apologies I never pushed the testsuite additions. New Changes:         remote:   https://gerrit.asterisk.org/#/c/testsuite/+/10557 testsuite: Added tests for correct packetization So what I've added are rtp_ptime tests -  transcode and non-transcode Ive added a utility to check the packet size in the codec logs on the B Leg which asterisk negotiates to 20ms. If you remove the patch both tests will fail because Asterisk will send 40ms in the transcode and non-transcode cases. By: George Joseph (gjoseph) 2018-10-29 09:05:03.398-0500 Robert, could you address the questions I posted last week? By: Robert Cripps (bobcripps) 2018-10-30 03:09:42.341-0500 1st question is sort of answered by the testsuite additions. We have two separate tests one for transcode one for non transcode. The sipp scenarios are fairly straightforward and you can see the ptime being set to 40 on the A LEG. As I said Asterisk always negotiates the B LEG to 20ms but it's not honoured. 2nd question. I've just tried setting the  transcode_via_sln to "yes" and the transcoding test still fails. 3rd question we've not yet tried this with asterisk 16 as we don't currently deploy it. By: Robert Cripps (bobcripps) 2018-10-31 07:41:11.652-0500 I'm as sure as I can be that we can configure around transcode problem as I've got our test case working and know how to get it to fail the same way as our internal JIRA defect report. I still believe there is a problem on the non-transcode case and a review comment suggested there may be a more elegant solution in bridge_native_rtp.c which I believe I have found so I will submit that tomorrow By: Friendly Automation (friendly-automation) 2018-11-19 09:36:43.243-0600 Change 10495 merged by Joshua Colp: bridge_native_rtp.c: Fail native bridge if no framing match. [https://gerrit.asterisk.org/10495|https://gerrit.asterisk.org/10495] By: Friendly Automation (friendly-automation) 2018-11-19 09:37:01.704-0600 Change 10624 merged by Joshua Colp: bridge_native_rtp.c: Fail native bridge if no framing match. [https://gerrit.asterisk.org/10624|https://gerrit.asterisk.org/10624] By: Friendly Automation (friendly-automation) 2018-11-19 09:37:19.536-0600 Change 10625 merged by Joshua Colp: bridge_native_rtp.c: Fail native bridge if no framing match. [https://gerrit.asterisk.org/10625|https://gerrit.asterisk.org/10625]