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

[TLP Research (JIRA)]

TLP Research created ASTERISK-27151:
---------------------------------------

             Summary: 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:

/* 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");
	}
}

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 (other 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 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), the 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)