STUN support

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Configure SIPdroid with a SIP account with protocol=TCP.
2.  Connect your phone to a NATted WiFi network.  Wait for the SIPdroid 
connection icon to turn green.
3.  Place a call from another device to the SIP account with which you 
configured SIPdroid in step 1.  Note that the call fails to connect.

What is the expected output? What do you see instead?

Expected outcome:  SIPdroid receives the call and gives me the option of 
answering it.
Actual outcome:  SIPdroid never receives the call and it fails over to 
voicemail.

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

SIPdroid 1.0.4 from the Android Marketplace, on a locked T-Mobile G1 with 
firmware 1.5 installed.

Please provide any additional information below.

This problem is obviously because, behind the NAT, SIPdroid cannot receive 
incoming TCP connections.  Almost all SIP/VoIP providers also provide STUN 
servers, however, for NAT-traversal purposes.  SIPdroid should allow you to 
specify a STUN server so that SIP over TCP can be used to negotiate 
connections.

JSTUN is an open-source Java STUN library (http://jstun.javawi.de/) which 
has an Android port (http://www.hsc.com/resourceCenter/resource.aspx).

Original issue reported on code.google.com by sparrowh...@gmail.com on 10 Aug 2009 at 12:33

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 12 Feb 2010 at 1:32

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 12 Feb 2010 at 7:35

• Changed state: Started

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Issue 899 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 18 Apr 2011 at 6:45

[GoogleCodeExporter]

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