Summary:	ASTERISK-28637: chan_sip+native_bridge_rtp: directmedia compatibility check failure when negociated ptime is not default ptime.
Reporter:	Frederic LE FOLL (flefoll)	Labels:
Date Opened:	2019-11-27 11:50:32.000-0600	Date Closed:	2019-12-04 18:05:46.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Bridges/bridge_native_rtp Channels/chan_sip/General
Versions:	16.4.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	Bridge technology selection fails to select native_bridge_rtp, although both endpoints have negociated RTP with the same codec and ptime. Example : - sip.conf configured with A-Law allowed, restricted to 10 ms (allow = alaw:10) - Two SIP endpoints configured to negociate codec=A-Law with ptime=10 - Re-INVITE for Direct Media does not occur after called party answer. The same problem occurs with other ptime values different from default value 20. Tested with Asterisk 13 or Asterisk 16 using chan_sip. Directmedia activation, in the same conditions, used to work in asterisk-13 branch (OK in 13.13 version), but recent Asterisk 13 versions also have the problem.
Comments:	By: Asterisk Team (asteriskteam) 2019-11-27 11:50:33.456-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]. 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. By: Frederic LE FOLL (flefoll) 2019-11-27 11:59:50.579-0600 Analysis: With conditions described above, In asterisk-13 branch, directmedia activation works until 13.15 included. It starts to fail with 13.16, where 'core set debug 1' shows: "native_rtp_bridge_compatible_check: Packetization differs between RTP streams (10 != 20 or 20 != 10). Cannot native bridge in RTP". The test fails comparing 10 and 20, while both endpoints and Asterisk have negociated 10ms ptime, as it can be checked in a SIP capture. The same test passes in previous version 13.15. But if you add a debug log in native_rtp_bridge_compatible_check(), in order to display values when the test has passed, you can see that this success is in fact the consequence of a double error: "native_rtp_bridge_compatible_check: Packetization matches between RTP streams (read_ptime0:20 == write_ptime1:20 and read_ptime1:20 == write_ptime0:20). Can native bridge in RTP". Tested ptime 20 is wrong for both parties of the call, and the test passes. A change in 13.16 has fixed ptime for called party (tested value 10 is real value), but not for calling party (tested value 20 is not real value). Thus, test in native_rtp_bridge_compatible_check() now fails if negociated ptime is not defaut ptime 20. The change seems to come from fix for ASTERISK-26143 with a modification in chan_sip.c:sip_get_codec(). If you revert to previous sip_get_codec() code, you come back to "all-wrong-but-equal" ptimes comparison. => An additional fix would be required to enable a correct compatibility check for ptime values other than 20, so that ast_format_cap_get_format_framing() gets real negociated ptime value for both parties of the call. As a result of ASTERISK-28110, https://gerrit.asterisk.org/c/asterisk/+/10495/, Asterisk 13.24 in asterisk-13 branch (and Asterisk 16.1 in asterisk-16 branch) introduces a preliminary comparison of framings, based on values obtained by ast_rtp_codecs_get_framing(). If you add debug traces on both tests, you can see that first test (new test) succeeds with ptime=10 for both parties, and second test (old test) fails on mismatch between 10 and 20: "native_rtp_bridge_compatible_check: Symmetric ptimes on the two call legs (framing_inst0:10 == framing_inst1:10). May native bridge in RTP" "native_rtp_bridge_compatible_check: Bridge '...': Packetization differs between RTP streams (10 != 20 or 20 != 10). Cannot native bridge in RTP" Additional information: Test with PJSIP instead of chan_sip (affer sip.conf to pjsip.conf conversion by sip_to_pjsip.py): The same scenario tested with PJSIP instead of chan_sip, in version 13.29.2, succeeds, but first test on ast_rtp_codecs_get_framing() just compares 0 to 0: "native_rtp_bridge_compatible_check: Bridge '...'.  Checking compatability for channels 'PJSIP/11002-00000005' and 'PJSIP/11001-00000004'" "native_rtp_bridge_compatible_check: Symmetric ptimes on the two call legs (framing_inst0:0 == framing_inst1:0). May native bridge in RTP" "native_rtp_bridge_compatible_check: Packetization matches between RTP streams (read_ptime0:10 == write_ptime1:10 and read_ptime1:10 == write_ptime0:10). Can native bridge in RTP" => framings obtained from ast_format_cap_get_format_framing() are consistent with negociated ptime value but ast_rtp_codecs_get_framing() returns 0 (not defined?, default?). Proposal: Initial SDP processing in chan_sip.c:process_sdp_a_audio() records the correct framing value for calling party. But sip_new(), next, selects the capabilities to use (what = ...) and calls ast_format_cap_append(caps, fmt, 0) ("add our best choice back"). With last argument 0, ast_format_cap_append(), through format_cap_framed_init(), will fill in a format_cap_framed structure with framing set to 0 and will fill in ast_format_cap structure with global framing set to ast_format_get_default_ms(). I think this is the origin of the framing=20 that appears in later comparisons. If chan_sip.c:sip_new() calls ast_format_cap_append() with the result of ast_format_cap_get_format_framing(what, fmt) instead of 0 [in fact, this is exactly what already happens in process_sdp() function], then compatibility test passes in native_rtp_bridge_compatible_check(). Asterisk wiki article https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal gives information on ast_format and ast_cap (read ast_format_cap?) but I did not find much information about ast_format_cap_framed. Other article https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite is not fully up-to-date either, concerning ast_format_cap structure. Thus, I am not sure about the suggested fix. By: Friendly Automation (friendly-automation) 2019-12-04 18:05:47.239-0600 Change 13351 merged by Friendly Automation: chan_sip+native_bridge_rtp: no directmedia for ptime other than default ptime. [https://gerrit.asterisk.org/c/asterisk/+/13351|https://gerrit.asterisk.org/c/asterisk/+/13351] By: Friendly Automation (friendly-automation) 2019-12-04 18:07:12.702-0600 Change 13350 merged by Friendly Automation: chan_sip+native_bridge_rtp: no directmedia for ptime other than default ptime. [https://gerrit.asterisk.org/c/asterisk/+/13350|https://gerrit.asterisk.org/c/asterisk/+/13350] By: Friendly Automation (friendly-automation) 2019-12-05 07:56:56.461-0600 Change 13311 merged by Joshua Colp: chan_sip+native_bridge_rtp: no directmedia for ptime other than default ptime. [https://gerrit.asterisk.org/c/asterisk/+/13311|https://gerrit.asterisk.org/c/asterisk/+/13311] By: Friendly Automation (friendly-automation) 2019-12-05 07:57:12.156-0600 Change 13352 merged by Joshua Colp: chan_sip+native_bridge_rtp: no directmedia for ptime other than default ptime. [https://gerrit.asterisk.org/c/asterisk/+/13352|https://gerrit.asterisk.org/c/asterisk/+/13352]