[Asterisk-code-review] bridge native rtp.c: Fail native bridge if no framing match (asterisk[13])

Robert Cripps asteriskteam at digium.com
Wed Nov 7 10:43:58 CST 2018


Robert Cripps has posted comments on this change. ( https://gerrit.asterisk.org/10495 )

Change subject: bridge_native_rtp.c: Fail native bridge if no framing match
......................................................................


Patch Set 3:

(1 comment)

> The nativeformats on the channel are set in set_caps, and the
 > format capabilities structure there is supposed to contain the
 > correct framing. Are you saying that this is not true? If so then
 > that is a bug - the nativeformats on the channel are supposed to
 > contain the correct framing as a result of the SDP negotiation
 > itself, which would then get used in the callback for get_codecs,
 > which should then cause the correct framing to appear in
 > bridge_native_rtp.

https://gerrit.asterisk.org/#/c/10495/3/bridges/bridge_native_rtp.c
File bridges/bridge_native_rtp.c:

https://gerrit.asterisk.org/#/c/10495/3/bridges/bridge_native_rtp.c@718
PS3, Line 718: 	read_ptime0 = ast_format_cap_get_format_framing(cap0, ast_channel_rawreadformat(bc0->chan));
             : 	read_ptime1 = ast_format_cap_get_format_framing(cap1, ast_channel_rawreadformat(bc1->chan));
             : 	write_ptime0 = ast_format_cap_get_format_framing(cap0, ast_channel_rawwriteformat(bc0->chan));
             : 	write_ptime1 = ast_format_cap_get_format_framing(cap1, ast_channel_rawwriteformat(bc1->chan));
> Yes, I think that is the real bug here.
So looking at set_caps()
Three ast_format_caps structures are all now initialized by the time this line of code is executed.
        /* get the joint capabilities between peer and endpoint */
        int ret = ast_format_cap_get_compatible(caps, peer, joint);
        ast_log(LOG_DEBUG,"PTIME_DEBUG framing - caps = %u peer = %u joint = %u ret = %d\n",caps->framing,peer->framing,joint->framing,ret);
        if (!ast_format_cap_count(joint)) {
That debug I put in there is called three times over the course of the test.
1st time in A LEG -
 res_pjsip_sdp_rtp.c: PTIME_DEBUG framing - caps = 20 peer = 40 joint = 20 ret = 0
2nd time B LEG -
res_pjsip_sdp_rtp.c: PTIME_DEBUG framing - caps = 20 peer = 20 joint = 20 ret = 0
3rd time A LEG
res_pjsip_sdp_rtp.c: PTIME_DEBUG framing - caps = 20 peer = 40 joint = 20 ret = 0

"caps: and "joint" are always 20ms. "peer" is not used after that line of code so any trace of 40ms is lost.
I had to hack in the declaration of ast_format_caps to get the debug to compile.
Still looking... but does this look normal?



-- 
To view, visit https://gerrit.asterisk.org/10495
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-MessageType: comment
Gerrit-Change-Id: Ic64b8fc6a140a93fbdb2f97550a40d0ff334e607
Gerrit-Change-Number: 10495
Gerrit-PatchSet: 3
Gerrit-Owner: Robert Cripps <rcripps at voxbone.com>
Gerrit-Reviewer: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Jenkins2 (1000185)
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: Robert Cripps <rcripps at voxbone.com>
Gerrit-Comment-Date: Wed, 07 Nov 2018 16:43:58 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20181107/ef4bc17d/attachment.html>


More information about the asterisk-code-review mailing list