[Home]

Summary:ASTERISK-17470: [patch] - When videosupport=yes, asterisk allows one end peer to send video, even though the other end supports only audio.
Reporter:effie mouzeli (manji)Labels:
Date Opened:2011-02-24 10:13:20.000-0600Date Closed:2016-10-17 13:44:36
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Video
Versions:1.8.2 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 0054_video_neg_fix.patch
( 1) video_tests.tgz
Description:When videosupport=yes, asterisk always advertises video codecs, thus one end believes that this a video call, and sends video, even though the other end accepts audio only.


Test setup
----------

Linphone 3.3.2  --- Asterisk --- Telephone 1.0.1
   (DDDD)                                                 (EEEE)

sip.conf:

videosupport=yes
bindport=1628

[DDDD]
type=friend
secret=kokolala
nat=no
qualify=yes
host=dynamic
canreinvite=no
context=koko
dtmfmode=rfc2833
disallow=all
allow = gsm
allow = alaw
allow = ulaw
allow = g722
allow = g726
allow = h263
allow = h263p
allow = h264
qualify=no
callerid="DDDD-LIN"<4000>

[EEEE]
type=friend
secret=kokolala
nat=no
qualify=yes
host=dynamic
canreinvite=no
context=koko
dtmfmode=rfc2833
disallow=all
allow = gsm
allow = alaw
allow = ulaw
allow = g722
allow = g726
allow = h263
allow = h263p
allow = h264
qualify=no
callerid="EEEE-TLPH"<5000>


- When peer  DDDD calls EEEE, it advertises the following codecs:

User-Agent: Linphone/3.3.2 (eXosip2/3.3.0).
m=audio 7078 RTP/AVP 0 3 8 112 111 110 101.
<snip>
m=video 9078 RTP/AVP 99 97 100 34 98.
<snip>

- Asterisk invites EEEE advertising the allowed codecs according to sip.conf:

User-Agent: Asterisk PBX 1.6.2.16.1.
m=audio 10534 RTP/AVP 3 8 0 9 111 101.
<snip>
m=video 13696 RTP/AVP 34 98.
<snip>

-EEEE responds 200 OK and sets its video port to 0, since it doesn't support video,
and choses the GSM codec:

m=audio 4000 RTP/AVP 3 101.
m=video 0 RTP/AVP 34 98.

- Asterisk sends 200 OK to DDDD, with the following codecs:

Server: Asterisk PBX 1.6.2.16.1.
m=audio 17820 RTP/AVP 3 8 0 111 101.
m=video 11448 RTP/AVP 34 98.

As a result, DDDD is sending video to asterisk, since it thinks that this is a video call. Even if client EEEE (Telephone 1.0.1) initiates the call, the result is the same, DDDD (Linphone)  will believe that this is a video call. I noticed the same behavior in Asterisk 1.8.2.3.
Comments:By: Amardeep S Bhambra (amardeep) 2011-07-27 09:02:45.193-0500

We are seeing following behavior even when the option videosupport=no is set

Asterisk is exhibiting following behavior for a call from user A to user B:

1) Originating leg: User A to Asterisk --> INVITE with audio codecs only
2) Terminating leg: Asterisk to User B --> INVITE with audio and video codecs
3) Terminating leg: User B to Asterisk --> 200 OK with audio and video codecs
4) Originating leg: Asterisk to User A --> 200 OK with audio codecs only
5) Terminating leg: Asterisk to User B --> ACK
6) Originating leg: User A to Asterisk --> ACK

To summarize, Asterisk is advertising video codec on the terminating leg even when the videosupport option has been turned off and there is no video codec present in the SDP on the originating leg. Is there any configuration parameter which can change this behavior of Asterisk?



By: Wim De Vlaminck (wimdev) 2013-02-25 06:34:59.396-0600

I would like bump this since it's still active and my report for asterisk 11 for the same issue was closed as duplicate.
ASTERISK-21158.

By: Cornelius Cety Lim (cetylim) 2014-01-28 03:27:59.138-0600

i installed Asterisk 11.5.1 on my ubuntu, still have same issue.

By: Torrey Searle (tsearle) 2014-09-15 07:26:51.426-0500

from reading the internal documentation, I have found that videosupport can have 3 values "yes" "no" and "always" currently "yes" is behaving the same as always and I believe this is a bug.

Attached is a patch to fix this and corresponding test cases to validate the patch.

By: Torrey Searle (tsearle) 2014-09-15 07:28:28.002-0500

This patch adapts videosupport=yes to only add video when needed

By: Torrey Searle (tsearle) 2014-09-15 07:29:27.206-0500

corresponding unit tests to validate the patch