Feature conflict noted: DISABLE_RCV_UNTIL_STARTED & STUN-RTP
- Dominant language
- Java
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
```
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
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.