[asterisk-bugs] [JIRA] (ASTERISK-27151) chan_sip.c/add_sdp() systematically adding m=video line

[TLP Research (JIRA)]

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

TLP Research updated ASTERISK-27151:
------------------------------------

    Description: 
The following code in function {{add_sdp()}} in {{chan_sip.c}} is buggy:

{code}
/* Check if we need video in this call */
if ((ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)) && !p->novideo) {
	if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)) {
		ast_debug(2, "This call needs video offers, but caller probably did not offer it!\n");
	} else if (p->vrtp) {
		needvideo = TRUE;
		ast_debug(2, "This call needs video offers!\n");
	} else {
		ast_debug(2, "This call needs video offers, but there's no video support enabled!\n");
	}
}
{code}

The reason is that when the following condition is evaluated:
{{if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO))}}

the value returned by:
{{ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)}}

must necessarily be true (otherwise we would have skipped the block) causing the condition to be always false.

This has the effect of falling through the {{else if}} block systematically (when video is supported) and setting {{needvideo}} to true.

This means that even when no video is offered by the caller (i.e. no {{m=video}} in the SDP of the INVITE message sent from caller to Asterisk), {{needvideo}} will still be set to true. One side effect of this bug is causing the {{m=video}} line to be appended to the SDP later on in the code of the {{add_sdp()}} function, even when no such line is needed.

Since {{add_sdp()}} is called from many functions, specifically {{transmit_invite()}} and {{transmit_reinvite_with_sdp()}}, one higher-level effect of this bug is causing the callee to enable video even when the caller requested only audio, making it impossible to issue an audio-only call if {{videosupport}} is set to {{yes}} in {{sip.conf}} and the callee supports video. 

Our suggested fix (which we didn't test yet) is to replace:
{{if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO))}}
with:
{{if (doing_directmedia && !ast_format_cap_has_type(p->caps, AST_MEDIA_TYPE_VIDEO))}}

Thank you


  was:
The following code in function {{add_sdp()}} in {{chan_sip.c}} is buggy:

{code}
/* Check if we need video in this call */
if ((ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)) && !p->novideo) {
	if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)) {
		ast_debug(2, "This call needs video offers, but caller probably did not offer it!\n");
	} else if (p->vrtp) {
		needvideo = TRUE;
		ast_debug(2, "This call needs video offers!\n");
	} else {
		ast_debug(2, "This call needs video offers, but there's no video support enabled!\n");
	}
}
{code}

The reason is that when the following condition is evaluated:
{{if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO))}}

the value returned by:
{{ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)}}

must necessarily be true (otherwise we would have skipped the block) causing the condition to be always false.

This has the effect of falling through the {{else if}} block systematically (when video is supported) and setting {{needvideo}} to true.

This means that even when no video is offered by the caller (i.e. no {{m=video}} in the SDP of the INVITE message sent from caller to Asterisk), {{needvideo}} will still be set to true. One side effect of this bug is causing the {{m=video}} line to be appended later on in the code of the {{add_sdp()}} function, even when no such line is needed.

Since {{add_sdp()}} is called from many functions, specifically {{transmit_invite()}} and {{transmit_reinvite_with_sdp()}}, one higher-level effect of this bug is causing the callee to enable video even when the caller requested only audio, making it impossible to issue an audio-only call if {{videosupport}} is set to {{yes}} in {{sip.conf}} and the callee supports video. 

Our suggested fix (which we didn't test yet) is to replace:
{{if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO))}}
with:
{{if (doing_directmedia && !ast_format_cap_has_type(p->caps, AST_MEDIA_TYPE_VIDEO))}}

Thank you



> chan_sip.c/add_sdp() systematically adding m=video line
> -------------------------------------------------------
>
>                 Key: ASTERISK-27151
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27151
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>            Reporter: TLP Research
>
> The following code in function {{add_sdp()}} in {{chan_sip.c}} is buggy:
> {code}
> /* Check if we need video in this call */
> if ((ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)) && !p->novideo) {
> 	if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)) {
> 		ast_debug(2, "This call needs video offers, but caller probably did not offer it!\n");
> 	} else if (p->vrtp) {
> 		needvideo = TRUE;
> 		ast_debug(2, "This call needs video offers!\n");
> 	} else {
> 		ast_debug(2, "This call needs video offers, but there's no video support enabled!\n");
> 	}
> }
> {code}
> The reason is that when the following condition is evaluated:
> {{if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO))}}
> the value returned by:
> {{ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO)}}
> must necessarily be true (otherwise we would have skipped the block) causing the condition to be always false.
> This has the effect of falling through the {{else if}} block systematically (when video is supported) and setting {{needvideo}} to true.
> This means that even when no video is offered by the caller (i.e. no {{m=video}} in the SDP of the INVITE message sent from caller to Asterisk), {{needvideo}} will still be set to true. One side effect of this bug is causing the {{m=video}} line to be appended to the SDP later on in the code of the {{add_sdp()}} function, even when no such line is needed.
> Since {{add_sdp()}} is called from many functions, specifically {{transmit_invite()}} and {{transmit_reinvite_with_sdp()}}, one higher-level effect of this bug is causing the callee to enable video even when the caller requested only audio, making it impossible to issue an audio-only call if {{videosupport}} is set to {{yes}} in {{sip.conf}} and the callee supports video. 
> Our suggested fix (which we didn't test yet) is to replace:
> {{if (doing_directmedia && !ast_format_cap_has_type(tmpcap, AST_MEDIA_TYPE_VIDEO))}}
> with:
> {{if (doing_directmedia && !ast_format_cap_has_type(p->caps, AST_MEDIA_TYPE_VIDEO))}}
> Thank you



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