[Home]

Summary:ASTERISK-19830: Asterisk receives an SDP offer with "recvonly" for video media but Asterisk responds with "sendrecv"
Reporter:Siegfried Tischler (siegfried_tischler)Labels:
Date Opened:2012-05-02 04:11:11Date Closed:2012-06-22 11:28:26
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability Channels/chan_sip/Video
Versions:1.8.10.1 10.3.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:openSuse Linux 11.3Attachments:( 0) 10-1-3-_chan_sip.c
( 1) ASTERISK-19830-capture-20120502-1230.zip
( 2) Call_disconnected.pcap
( 3) mixed_sendrecv.diff
( 4) VideoProblem.tar.gz
Description:Asterisk receives an SDP offer with "recvonly" (when phone is in VIDEO_PASSIVE mode == video-on, no-usb-cam-connected) but the SDP answer from asterisk contains a "sendrecv" which is not-RFC compliant (sendonly or inactive are valid responses).

Test scenario
Comments:By: Siegfried Tischler (siegfried_tischler) 2012-05-02 04:13:27.081-0500

Test scenario:

Asterisk: 10.90.10.100

Both phones have video capability activated
but no camera connected
762 (10.90.10.2) calls 763 (10.90.10.10)
763 answers the call
---> connection will be disconnected
By: Siegfried Tischler (siegfried_tischler) 2012-05-02 05:46:00.808-0500

Asterisk SIP DEBUG traces
By: Klaus Wiesinger (kwiesing) 2012-05-02 07:19:16.290-0500

Relevant SIP messages where we discover the RFC-non-compliance - SDP offer received by asterisk:

{quote}
<--- SIP read from UDP:10.90.10.2:5060 --->
INVITE sip:763@10.90.10.100:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.90.10.2;branch=z9hG4bKe18ea8547d29f33d4
From: "TERM-NAME_762" <sip:762@10.90.10.100:5060>;tag=1b67b81da7;epid=SC25e2dd
To: <sip:763@10.90.10.100:5060>
Call-ID: c270813f4b95aef8
CSeq: 488857086 INVITE
...
Content-Type: application/sdp
Content-Length: 395

v=0
o=OpenStage-Line_0 1594648025 787962740 IN IP4 10.90.10.2
s=SIP Call
c=IN IP4 10.90.10.2
t=0 0
m=audio 5010 RTP/AVP 8 0 18 101
...
a=sendrecv
m=video 5050 RTP/AVP 34
a=rtpmap:34 H263/90000
a=fmtp:34 QCIF=1
a=recvonly

{quote}



SDP answer sent by asterisk:
{quote}
<--- Reliably Transmitting (NAT) to 10.90.10.2:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.90.10.2;branch=z9hG4bKe18ea8547d29f33d4;received=10.90.10.2;rport=5060
From: "TERM-NAME_762" <sip:762@10.90.10.100:5060>;tag=1b67b81da7;epid=SC25e2dd
To: <sip:763@10.90.10.100:5060>;tag=as09a3144c
Call-ID: c270813f4b95aef8
CSeq: 488857086 INVITE
Server: Asterisk PBX 1.8.10.0-rc3
...
Content-Type: application/sdp
Content-Length: 360

v=0
o=root 527125661 527125661 IN IP4 10.90.10.100
s=Asterisk PBX 1.8.10.0-rc3
c=IN IP4 10.90.10.100
b=CT:384
t=0 0
m=audio 5006 RTP/AVP 8 0 101
...
a=sendrecv
m=video 5054 RTP/AVP 34
a=rtpmap:34 H263/90000
a=sendrecv                <== here either "sendonly" or "inactive" are valid values
{quote}



Regards,
-Klaus
By: Kinsey Moore (kmoore) 2012-06-05 15:28:57.858-0500

Hi Siegfried and Klaus,
Could you give the attached patch a try?  It causes Asterisk to decline the video stream when the audio and video streams differ in their media states.  Asterisk is not currently capable of maintaining different/separate media transmission states for different streams in the same offer.  This patch seems to fix the bug you experienced in the testing I performed.

Kinsey
By: Siegfried Tischler (siegfried_tischler) 2012-06-13 01:22:55.504-0500

Hi, I am not an expert on patching such files.
Please can you check the attached chan_sip.c, if the source is patched correctly.
I used a chan_sip.c file, based on version 10.1.3

And I am not sure, how to bring this into the source from the difference-list:

/* Now gather all of the codecs that we are asked for: */
ast_rtp_codecs_payload_formats(&newaudiortp, peercapability, &peernoncodeccapability);
ast_rtp_codecs_payload_formats(&newvideortp, vpeercapability, &vpeernoncodeccapability);
@@ -9830,11 +9846,11 @@
ast_set_write_format(p->owner, ast_channel_writeformat(p->owner));
}
By: Kinsey Moore (kmoore) 2012-06-13 07:41:16.016-0500

It does not appear that the patched chan_sip.c you provided was patched properly. If you want to apply the patch, move into the Asterisk source code directory and run the command "patch -p0 < /path/to/file/mixed_sendrecv.diff".  You can then build Asterisk normally.
By: Siegfried Tischler (siegfried_tischler) 2012-06-14 07:10:46.941-0500

There is a problem with the provided solution.
Now the specch connection without attached camera works but if a camera is connected to the phone no vodeo connection will be established. Only a specch connection is established.
Attached are the following:
- your diff file of chan_sip.c
- patched (used) chan_sip.c file
- Wireshark traces of both test cases (without camera, with camera)
- Asterisk trace of the case, where avideo camera is attached
 In this case, the Asterisk console shows:
 [Jun 14 13:16:00] WARNING[5232]: chan_sip.c:9753 process_sdp_a_sendonly: a=recvonly is not supported
 [Jun 14 13:16:00] WARNING[5232]: chan_sip.c:9317 process_sdp: Video stream disabled due to mismatched stream hold states

Test scenario:
Station 771 (192.168.4.95) calls 772 (192.168.4.93)
771 has camera connected.

By: Kinsey Moore (kmoore) 2012-06-14 07:34:14.666-0500

If you attach a camera to both sides, the video should function again.  As I stated when providing the patch, Asterisk is not currently capable of maintaining separate sendonly/recvonly/sendrecv/inactive states among different streams in an offer.  Due to this limitation, only this behavior (technically correct, but less functional) or the old behavior (violates the RFC, but has more desired functionality) is available without major reworking of chan_sip's hold mechanisms and a rewriting of SDP parsing in its entirety.
By: Kinsey Moore (kmoore) 2012-06-22 11:05:12.585-0500

Given that committing this change would result in a significant degradation in capabilities for what I assume is a fairly common use case, I am going to leave the patch attached to this issue for anyone who requires absolutely correct SDP but I will not be committing it.
By: Kinsey Moore (kmoore) 2012-06-22 11:28:26.128-0500

As per the above comment, this bug can not be fixed while maintaining functionality without a significant reworking of chan_sip's stream handling (which is not currently planned).