[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 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 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)