Feature conflict noted: DISABLE_RCV_UNTIL_STARTED & STUN-RTP

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile default Doubango for Android
2. Enable STUN
3. Establish a call
4. Noticed that STUN req were sent but resp was being ignored
5. Causes SDP to contain private addressing
6. Causes REALLY long call setup times waiting for STUN to timeout on SDP 
scokets

What is the expected output? What do you see instead?
1. Expected STUN response to be processed
2. Expected SDP (c) lines to contain public addresses & ports (via STUN)

What version of the product are you using? On what operating system?
Latest

Please provide any additional information below.

I found I was compiling Doubango project for Android with 
DISABLE_RCV_UNTIL_STARTED = 1 (default value) designed to protect Doubango from 
buffering early-media (audio) before IMSDroid is ready to process. The issue 
(bug?) with the current implementation is it turns OFF the IP kernel buffers in 
the Android and Win32 (Boghe) IP stacks altogether, STUN req packets do go out, 
the stack is notified of incoming STUN response data but the ioctl returns ZERO 
causing the transport thread to drop the packet altogether and miss the STUN 
response. The STUN timeouts in the current finite state machine, incorret SDP 
values are placed in the SDP (due to failure to receive STUN responses) and the 
call proceeds. Many CSCF with B2BUA capability ignore the STUN and use actual 
IP:port info received from the CSCF's local sockets for the A & B party 
endpoints.

Proposal to fix:
DISABLE_RCV_UNTIL_STARTED 0 // by default
...or fix the getsockopt and setsockopt to not completely disable the IP kernel 
buffers...

Original issue reported on code.google.com by rich.ho...@gmail.com on 12 Feb 2011 at 3:14

[GoogleCodeExporter]

Slight correction/clarification:

I found I was compiling Doubango project for Android with '#define 
DISABLE_RCV_UNTIL_STARTED  1' (the default value) designed to protect Doubango 
from buffering early-media (audio) before IMSDroid is ready to process. The 
issue (bug?) with the current implementation is it turns OFF the IP kernel 
buffers in the Android and Win32 (Boghe) IP stacks altogether so no data can be 
received on the socket, STUN req packets do go out, the IP kernel notifis 
Doubango of incoming STUN response data but the ioctl returns ZERO causing the 
Doubango transport thread to drop the packet altogether and miss the STUN 
response. The STUN eventually timeouts after 3 retries in the current finite 
state machine, incorret public IP:port values are placed (c) lines of the SDP 
(due to failure to receive STUN responses) and the call proceeds. Many CSCF 
with B2BUA capability ignore the (c) lines of SDP and use actual IP:port info 
received from the CSCF's local sockets for the A & B party endpoints.

Proposal to fix in Doubango for Android & Win32:
DISABLE_RCV_UNTIL_STARTED 0 // by default
...or fix the getsockopt and setsockopt to not completely disable the IP kernel 
buffers...

Original comment by rich.ho...@gmail.com on 12 Feb 2011 at 3:21

[GoogleCodeExporter]

You are right: this is an issue.
BTW, "DISABLE_RCV_UNTIL_STARTED" no longer exists in the latest releases.

Original comment by boss...@yahoo.fr on 13 Feb 2011 at 6:24

• Changed state: NextRelease

[GoogleCodeExporter]

Should be fixed in Doubango 587. You must rebuild the tinyWRAP.
Will be part of the next release of IMSDroid.

Original comment by boss...@yahoo.fr on 19 May 2011 at 8:58