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-0600 | Date Closed: | 2016-10-17 13:44:36 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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 |