Open GoogleCodeExporter opened 8 years ago
Have you checked if an INVITE message is sent to Sipdroid over your TCP
connection?
Which server are you using? Why do you assume this to be solved by a STUN
client?
Original comment by pmerl...@googlemail.com
on 10 Aug 2009 at 7:42
Let me further explain why a STUN service can't help you:
When you are sitting behind a NAT router you can only make outgoing
connections.
Incoming connections (don't mix this up with incoming calls!) cannot be made
because
you don't have a public IP to address them to (unless you have activated some
sort of
port forwarding on your router to enable services like a web server on a
private IP).
To be able to receive calls a client usually opens a connection when
registering.
Then the server can answer on this connection when a call comes in, and the
phone
rings.
A TCP connection greatly simplifies things because the server just needs to
send the
INVITE message thru the connection. It does not need an address like with UDP
because
it is a connection oriented protocol.
I hope my questions asked above are clear now.
Original comment by pmerl...@googlemail.com
on 10 Aug 2009 at 10:30
pmerle71, You are not entirely correct. There's a technique called NAT hole
punching
- see http://en.wikipedia.org/wiki/Hole_punching for details.
Original comment by mor...@ringutomlands.se
on 3 Sep 2009 at 11:46
Sparrowhawk mentioned being registered already and a call does not come in from
the
registrar.
You are referring to a different story. Hole punching applies to double NAT
scenarios
(p2p).
BTW: Hole punching is only possible with UDP. (Theoretically a bit more is
possible, but using TCP is not practical, if at all possible).
Original comment by pmerl...@googlemail.com
on 4 Sep 2009 at 7:21
Could this not be solved by using an outbound proxy from the SIP rfc? I know
that
most UA have support for it today. Would be nice to have on those NAT:ed WLAN's.
http://www.voip-info.org/wiki/view/SIP+outbound+proxy
Original comment by s.lindeb...@gmail.com
on 4 Sep 2009 at 8:12
As you can see below - NAT/STUN support would be required , the VIA: is being
set to
an RFC1911 IP which in turn does not work (The device is registered against a
hosted
PBX on the Internet)
U 2009/09/29 12:26:05.766390 [XXX.XXX.XXX.XX]:5060 -> [XXX.XX.XX.XX]:5060
ACK sip:160@XXX.XX.XX.XX SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XXX.XX;branch=z9hG4bKb761.1401a5a4.2.
Via: SIP/2.0/UDP
127.0.0.1;received=XX.XXX.XX.XX;rport=57323;branch=z9hG4bK27711.
Max-Forwards: 69.
To: <sip:160@XXX.provider.dom>;tag=as6de3193b.
From: <sip:XXXXXXX@XXX.provider.dom:XXXX>;tag=z9hG4bK04653745.
Call-ID: 037818904673@127.0.0.1.
CSeq: 1 ACK.
Contact: <sip:XXXXXXX@127.0.0.1>.
Expires: 3600.
User-Agent: Sipdroid/1.1.1 beta.
Content-Length: 0.
As the device is registering with a hosted PBX on the internet, NAT traversal
or STUN
would need to be supported .
Registering the phone against a hosted PBX on the local network does not have
these
problems.
Original comment by gavinjle...@gmail.com
on 29 Sep 2009 at 11:33
The VIA and Contact fields should be updated using the received and rport
values from
the sip provider, but not appear to be happening. This should resolve NAT on
the client
side with using STUN, if the provider is not also NAT'd.
Original comment by piusve...@gmail.com
on 29 Sep 2009 at 3:46
The STUN support is really needed for this great application. My own server has
a
STUN service, PBX, but the incoming cals fail. The Asterisk "sip show peers"
signs my
phone as unreachabe.
Original comment by simon.pe...@gmail.com
on 15 Nov 2009 at 9:07
For asterisk use nat=route in sip.conf to work around this issue.
Original comment by csta...@gmail.com
on 15 Nov 2009 at 11:18
Tamás, this is just a workaround, what doesn't work.
All my endpoints should need to set a STUN server. Behind a router how can your
Asterisk find the way to your voip phone, voip adapter, voip soft client?
Original comment by simon.pe...@gmail.com
on 15 Nov 2009 at 12:57
[deleted comment]
Original comment by pmerl...@googlemail.com
on 12 Feb 2010 at 1:32
Original comment by pmerl...@googlemail.com
on 12 Feb 2010 at 7:35
I am new here. What is current status of STUN support for sipdroid?
Original comment by Aviator...@gmail.com
on 18 Mar 2010 at 8:28
Shouldn't it be marked as fixed? There is a STUN setting in sipdroid.
Original comment by marcu...@gmail.com
on 21 Jun 2010 at 12:45
Issue 899 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 18 Apr 2011 at 6:45
More enhancement:
Ability configure stun auto
- with stun server and port parameters
On connection change:
- check using stun if device ip address is behind nat
-- if behind nat, use stun protocol (costs 300 KiB per day)
-- if has global ip, do not use stun
Original comment by har...@therudells.com
on 7 Jan 2012 at 10:44
Original issue reported on code.google.com by
sparrowh...@gmail.com
on 10 Aug 2009 at 12:33