[asterisk-bugs] [JIRA] (ASTERISK-22424) bridge_native_rtp: Asterisk 12 attempts to remotely bridge on 200OK response to invite when the 200 lacks SDP

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-22424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-22424:
-----------------------------------

    Target Release Version/s:     (was: 11.6.0)
                                  (was: 1.8.24.0)
    
> bridge_native_rtp: Asterisk 12 attempts to remotely bridge on 200OK response to invite when the 200 lacks SDP
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22424
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22424
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_native_rtp, Core/RTP
>    Affects Versions: SVN, 12, 1.8.23.1, 10.12.3, 11.5.1
>            Reporter: Jonathan Rose
>            Assignee: Jonathan Rose
>
> I discussed this with Mark and he believes this is misbehavior on both the part of Asterisk 11 and Asterisk 12 and that the call should be terminated on receiving the 200 OK in this malformed state, but the difference between Asterisk 11 and Asterisk 12 is that Asterisk 11 would fallback to local bridging in this case on account of the following codeblock in rtp_engine.c
> ast_rtp_instance_bridge:
> {noformat}
> 	/* If address families differ, force a local bridge */
> 	ast_rtp_instance_get_remote_address(instance0, &addr1);
> 	ast_rtp_instance_get_remote_address(instance1, &addr2);
> 	if (addr1.ss.ss_family != addr2.ss.ss_family ||
> 	   (ast_sockaddr_is_ipv4_mapped(&addr1) != ast_sockaddr_is_ipv4_mapped(&addr2))) {
> 		audio_glue0_res = AST_RTP_GLUE_RESULT_LOCAL;
> 		audio_glue1_res = AST_RTP_GLUE_RESULT_LOCAL;
> 	}
> {noformat}
> At this point when bridging, addr2 will be NULL and we will use local bridging when the bridge is actually formed. I'm not entirely sure whether this actually results in a usable call and Mark suspects that it will result in one or both of the audio paths being broken. Asterisk 12's native RTP bridging code has no similar block, so it will keep trying to use remote bridging. This will almost certainly result in one or both audio paths being broken.
> For an example of some scenarios where this plays out, check the sip_hold_direct_media test in testsuite revision 4095.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira