[asterisk-bugs] [JIRA] (ASTERISK-28637) chan_sip+native_bridge_rtp: directmedia compatibility check failure when negociated ptime is not default ptime.

Wed Nov 27 12:01:32 CST 2019

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=248907#comment-248907 ] 

Frederic LE FOLL commented on ASTERISK-28637:
---------------------------------------------

Analysis:

With conditions described above, In asterisk-13 branch, directmedia activation in 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 phsip.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, then compatibility test passes in native_rtp_bridge_compatible_check().
In fact, this is exactly what already happens in process_sdp() function.

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.

> chan_sip+native_bridge_rtp: directmedia compatibility check failure when negociated ptime is not default ptime.
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28637
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28637
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_native_rtp, Channels/chan_sip/General
>    Affects Versions: 16.4.0
>            Reporter: Frederic LE FOLL
>            Severity: Minor
>
> 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.

--
This message was sent by Atlassian JIRA
(v6.2#6252)