[asterisk-bugs] [Asterisk 0018880]: When videosupport=yes, asterisk allows one end peer to send video, even though the other end supports only audio.
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Mar 2 06:46:41 CST 2011
The following issue has been UPDATED.
======================================================================
https://issues.asterisk.org/view.php?id=18880
======================================================================
Reported By: manji
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 18880
Category: Channels/chan_sip/Video
Reproducibility: always
Severity: minor
Priority: normal
Status: acknowledged
Asterisk Version: 1.6.2.16.1
JIRA: SWP-3179
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2011-02-24 10:13 CST
Last Modified: 2011-03-02 06:46 CST
======================================================================
Summary: When videosupport=yes, asterisk allows one end peer
to send video, even though the other end supports only audio.
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.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2011-02-28 14:47 lmadsen JIRA => SWP-3179
======================================================================
More information about the asterisk-bugs
mailing list