[asterisk-bugs] [JIRA] (ASTERISK-17470) [patch] - When videosupport=yes, asterisk allows one end peer to send video, even though the other end supports only audio.

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-17470:
-----------------------------------

    Summary: [patch] - When videosupport=yes, asterisk  allows one end peer to send video, even though the other end supports only audio.  (was: When videosupport=yes, asterisk  allows one end peer to send video, even though the other end supports only audio.)

> [patch] - When videosupport=yes, asterisk  allows one end peer to send video, even though the other end supports only audio.
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-17470
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17470
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/Video
>    Affects Versions: 1.8.2
>            Reporter: effie mouzeli
>            Severity: Minor
>         Attachments: 0054_video_neg_fix.patch, video_tests.tgz
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)