Sent-by Address: 127.0.0.1

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enter sip settings for a local asterisk server
2. Attempt to register
3. Packet capture shows Sent-by Address: 127.0.0.1 and contact 127.0.0.1
(localhost)

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

Can it not send the ip of the device? Perhaps it expects some received
address and received port processing?

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

1.5 official on adp 1

Please provide any additional information below.

Original issue reported on code.google.com by scott.wi...@gmail.com on 29 Apr 2009 at 12:46

[GoogleCodeExporter]

SIP Registration Packet

REGISTER sip:pbx.lan SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bK23809
Max-Forwards: 70
To: <sip:6002@pbx.lan>
From: <sip:6002@pbx.lan>;tag=z9hG4bK87373289
Call-ID: 130815916834@127.0.0.1
CSeq: 1 REGISTER
Contact: <sip:6002@127.0.0.1>
Expires: 3600
User-Agent: mjsip stack 1.6
Content-Length: 0

Original comment by scott.wi...@gmail.com on 29 Apr 2009 at 12:48

[GoogleCodeExporter]

I have the same Problem:

--- (11 headers 0 lines) ---
Sending to 192.168.2.17 : 5060 (NAT)

<--- SIP read from UDP://192.168.2.17:5060 --->
REGISTER sip:192.168.2.69 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bK20244
Max-Forwards: 70
To: <sip:205@192.168.2.69>
From: <sip:205@192.168.2.69>;tag=z9hG4bK26630175
Call-ID: 042476028119@127.0.0.1
CSeq: 1 REGISTER
Contact: <sip:205@127.0.0.1>
Expires: 3600
User-Agent: mjsip stack 1.6
Content-Length: 0

Original comment by bendscha...@gmail.com on 8 May 2009 at 7:22

[GoogleCodeExporter]

I have the same problem too:

U 189.85.1XX.XX:6445 -> 189.85.1XX.XX:5060
REGISTER sip:189.85.128.23 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bK12874.
Max-Forwards: 70.
To: <sip:8998@189.85.1XX.XX>.
From: <sip:8998@189.85.1XX.XX>;tag=z9hG4bK60423525.
Call-ID: 071320683639@127.0.0.1.
CSeq: 1 REGISTER.
Contact: <sip:8998@127.0.0.1>.
Expires: 3600.
User-Agent: mjsip stack 1.6.
Content-Length: 0.

and the response is 400 Bad Request:
U 189.85.1XX.XX:5060 -> 189.85.1XX.XX:6445
SIP/2.0 400 Bad Request.
Via: SIP/2.0/UDP
127.0.0.1:5060;rport=6445;branch=z9hG4bK12874;received=189.85.1XX.XX.
To: <sip:8998@189.85.1XX.XX>;tag=316ae364d36f7a841168df84601ddb59.8a0f.
From: <sip:8998@189.85.1XX.XX>;tag=z9hG4bK60423525.
Call-ID: 071320683639@127.0.0.1.
CSeq: 2 REGISTER.
Content-Length: 0.
Warning: 392 189.85.1XX.XX:5060 "Noisy feedback tells:  pid=3267
req_src_ip=189.85.1XX.XX req_src_port=6445 in_uri=sip:189.85.1XX.XX
out_uri=sip:189.85.1XX.XX via_cnt==1".

Original comment by celson.s...@gmail.com on 12 May 2009 at 1:50

[GoogleCodeExporter]

me too, we I check my spi provider I see my android there registered as:

useragent: mjsip stack 1.6  contact: sip:41445002414@127.0.0.1

may be something we the router not configured properly?

guido

Original comment by Guido.Sc...@gmail.com on 20 May 2009 at 10:23

[GoogleCodeExporter]

Antonio started working on this issue.

Original comment by pmerl...@googlemail.com on 22 May 2009 at 6:47

• Changed state: Started

[GoogleCodeExporter]

I am having the same issues guys.  Any resolution or updates yet?

Original comment by zebahme...@gmail.com on 3 Jun 2009 at 3:42

[GoogleCodeExporter]

Same issue for me too using voiduser.org

"You are online with a Sipdroid/0.9.5 device or phone at 127.0.0.1 and you are 
not 
behind NAT"

Original comment by digitals...@gmail.com on 3 Jun 2009 at 9:47

[GoogleCodeExporter]

i have the same problem. I can call from sipdroid, but i cannot receive them. 

The thing is, the "contact" field contains user@127.0.0.1, so on incoming 
calls, the
message loops. 

Original comment by lucas.l...@gmail.com on 12 Jun 2009 at 2:21

[GoogleCodeExporter]

We solve partially the asterisk issue, not as elegant as we will like, it do 
the trick.

CODE:

import java.net.InetAddress;
import java.net.Socket;
import java.lang.String;

In the public class SipdroidEngine ---

public static String getLocalHostAddress() {
InetAddress ip=null;
/** Detects the default IP address of this host. */
try {
Socket conn = new Socket("www.google.com", 80);
ip = conn.getLocalAddress();
ip.toString();
conn.close();
} catch (Exception e) {
return "127.0.0.1";
}
String aux = new String(ip.toString());
return aux.replaceFirst("/", "");
}

String opt_via_addr = getLocalHostAddress();

Original comment by fjclmo...@gmail.com on 17 Jun 2009 at 4:26

Attachments:

• SipdroidEngine.java

[GoogleCodeExporter]

Hi all,

I have the same issue on my Samsung Galaxy with sipdroid 1.0.3.

Did you find a fix ?

Thanks a lot !

Original comment by alexis.marcou on 23 Jul 2009 at 10:47

[GoogleCodeExporter]

Hi! Same problem! Sipdroid 1.0.3, Communigate Pro 5.2.9

Logfile output:

MEDIA-000047 created(4444447F) for PBXLEG-007760, audio port [0.0.0.0]:60000
MEDIA-000047 set:[127.0.0.1]:21000 SDP(-1=DTMF 8=PCMA/8000,0=,0=)sendrecv 
<-> (PCMA/8000)sendrecv
SIPDATA-035534 out: rsp -> tcp[212.26.245.116]:50753 200-INVITE(961 bytes)
SIPS-012666 [035534] 200-INVITE(final) sent to tcp[212.26.245.116]:50753
SIPDATA-035532 inp: req [0.0.0.0]:0 <- tcp[212.26.245.116]:50753 ACK(490 bytes) 
sip:signode-7760-36C04AAC@91.203.180.145
SIPDATA-035532 stand-alone ACK
DIALOG-000495 signal expiration updated
MEDIA-000047 adjusting sender timer: 2000
MEDIA-000047 [212.26.245.116]:21000 inp data dropped, unknown address

Original comment by juriy.fo...@gmail.com on 25 Jul 2009 at 11:00

[GoogleCodeExporter]

There is no need to comment to say "me too".  This is an issue for everyone.  
"127.0.0.1" is hard coded, which 
means that registrations will never work properly for anyone.

I have just started looking at this, but to see where it is hard coded, see 
src/org/sipdroid/sipua/SipdroidEngine.java, and search for "StartEngine".  The 
"opt_via_addr" is hard coded to 
"127.0.0.1", and in fact used for much more than the Via: header (not that it's 
correct there, either).

There are some other interesting things about this function that caught my 
attention at a glance:

 - The whole function is wrapped in a try { ... } catch (Exception E) { (nothing) } - so, errors are completely 
ignored

 - TCP is used by default if the server is "pbxes.org", while UDP is used otherwise.  It's odd to see service 
provider specific code like that.  Ideally, this information would come from an 
SRV record as to what the 
provider prefers.

Some final thoughts ... while it's tempting to make a localized change to this 
function for the problem, it 
seems like it's likely to not be a full solution.  Maybe the code already does 
some of this, I'm not sure yet, but 
since on these devices can have multiple connections to the internet, to 
maintain a working registration and 
be able to receive calls, this application must be aware of things like:

 - when a connection to the internet comes on or off, as a previous registration may need to be canceled, and 
a new one needs to be made.

- when the device's IP address changes because the device is wandering around 
and hopping between 
different networks, a new registration will be required, as well, as the device 
will no longer be reachable at 
the old Contact address.

But anyway, changing that function such that at least it is possible for the 
first registration to be correct 
would be a nice step in the right direction.  :-)

Original comment by russell....@gmail.com on 25 Jul 2009 at 2:13

[GoogleCodeExporter]

Hi,
a correct solution would be the use of a (changeable) STUN Server like almost 
every
VOIP Client.

Original comment by dataco...@gmail.com on 6 Aug 2009 at 8:42

[GoogleCodeExporter]

I'm experiencing this issue on 1.0.5. I'm in the asterisk cli and the addr->ip 
field 
has the correct ip/port, but the reg. contact still has 127.0.0.1. I'm not sure 
how 
ekiga accomplishes this, but both ekiga and sipdroid are registered through the 
same 
remote wifi. I don't have a stun server defined in ekiga. Is there a 
workaround? 
Thanks!

Original comment by piusve...@gmail.com on 26 Aug 2009 at 1:05

[GoogleCodeExporter]

It looks 127.0.0.1 is defaulted in for several fields, such as caller id and 
contact. 
Could the sip server hostname be used as the default instead? I'm watching my 
windows 
mobile phone and ekiga both register, and it appears that they do this. This is 
unchartered territory for me, so I'm just trying to dig up details. Thank you!

Original comment by piusve...@gmail.com on 26 Aug 2009 at 5:42

[GoogleCodeExporter]

Ekiga has stun support built in, using their stun server. I'm not sure if or how
windows mobile resolves this.

Original comment by piusve...@gmail.com on 28 Aug 2009 at 1:20

[GoogleCodeExporter]

You can work around this in CallWeaver by setting nat=yes in the phone's 
sip.conf
entry, although this opens up some security issues (but does have the rather 
cunning
advantage that you can transparently roam between networks (e.g. WiFi and 3G) 
while
the call is in progress).

However, even without STUN, setting this to 127.0.0.1 is wrong.   In the 
absence of
STUN telling it otherwise, it should be set to the address of the NIC that has 
the
default route on it (actually, should be the NIC that the SIP traffic is going 
out
of, but that is probably the same thing on a phone).

For the record, I personally don't require a STUN server since there is no NAT
between my phone and my CallWeaver server when the phone is connected via 
either 3G
or WiFi.

Original comment by nexusuk....@googlemail.com on 4 Sep 2009 at 8:05

[GoogleCodeExporter]

The proper solution would be to implement (if it is not already) RFC 3581 "An
Extension to the Session Initiation Protocol (SIP) for Symmetric Response 
Routing"
http://www.ietf.org/rfc/rfc3581.txt

This would provide Client UA handling of via address and port values.

Original comment by scott.wi...@gmail.com on 4 Sep 2009 at 10:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 21 Sep 2009 at 11:16

• Changed state: Fixed

[GoogleCodeExporter]

I am not sure if this should be closed.

There is a related issue:
[Sep 21 15:24:18] WARNING[10396]: chan_sip.c:2620 __sip_xmit: sip_xmit of 
0x828ca70
(len 516) to 79.122.68.184:0 returned -1: Invalid argument

Sipdroid send a wrong port number (at least if seems to me).

Regards,
  cstamas

Original comment by csta...@gmail.com on 21 Sep 2009 at 1:30

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 21 Sep 2009 at 5:25

• Changed state: Started

[GoogleCodeExporter]

It uses the right IP now but announces itself as listening on port 0 causing 
replies
from sip server to fail to transmit.

Original comment by darksk...@gmail.com on 22 Sep 2009 at 9:30

[GoogleCodeExporter]

Issue 141 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 22 Sep 2009 at 2:08

[GoogleCodeExporter]

Sipdroid still shows as UNREACHABLE in asterisk. I don't know if this is 
helpful, but 
these are differences that I've noticed from my other phone which is working 
perfectly 
with asterisk:

The Via header contains 127.0.0.1:0, whereas my other phone sends the external 
ip:port.
The To and From headers lack the port.
The Contact header value is <sip:sip:uri> in sipdroid, as opposed to 
<sip:externalIP:port> on my other phone.

Original comment by piusve...@gmail.com on 22 Sep 2009 at 5:34

[GoogleCodeExporter]

Port 0 should no more be announced in 1.1.0.

Original comment by pmerl...@googlemail.com on 22 Sep 2009 at 11:07

[GoogleCodeExporter]

I just updated to 1.1.0 and it still will not register.  Still getting this:

<--- SIP read from 10.13.1.159:56184 --->
REGISTER sip:funkynerd.com SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1;rport;branch=z9hG4bK32221
Max-Forwards: 70
To: <sip:101@funkynerd.com>
From: <sip:101@funkynerd.com>;tag=z9hG4bK10069008
Call-ID: 607963417096@127.0.0.1
CSeq: 1 REGISTER
Contact: <sip:101@127.0.0.1>
Expires: 3600
User-Agent: Sipdroid/1.1.0 beta
Content-Length: 0

Which is wrong....  I would not expect to see 127.0.0.1 anywhere in a SIP 
message, ever.

Original comment by jazz13 on 23 Sep 2009 at 12:50

[GoogleCodeExporter]

It would maybe help to revert the change of the org.zoolu.net.IpAddress.java in 
the
revision r303.

Original comment by jiri....@gmail.com on 23 Sep 2009 at 9:04

[GoogleCodeExporter]

Everyone knows now register=no needs to be set as a workaround for this on 
Asterik.
This project is great and you guys should aim to fix this as everyone just look 
bad
to sipdroid as soon as they see this behavior.

Have a look at this (199 is sipdroid):

pbx1-uk*CLI> sip show channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)  Format           Hold    
 Last
Message   
83.13.192.197    199         18810cfe5cf  00102/00000  0x0 (nothing)    No      
Init: NOTIFY              
127.0.0.1        199         18724917995  00101/00002  0x100008 (alaw|  No      
 Rx:
ACK                   
127.0.0.1        (None)      83712516288  00101/00002  0x0 (nothing)    No      
 Rx:
REGISTER              

I hope that helps.

Original comment by conex...@gmail.com on 16 Oct 2009 at 6:39

[GoogleCodeExporter]

Since there is some indication (from previous posts) that this problem is 
related to 
both hardware and software, I wanted to let you know that this problem also 
occurs 
on Sprint's version of the HTC Hero.  I would love to see this resolved as soon 
as 
possible.  Any idea when a fix could be released?

Original comment by troutkin...@gmail.com on 10 Nov 2009 at 5:24

[GoogleCodeExporter]

How could this problem be related to hardware ?
I must be missing something, can you point us to the posts saying so ?

Original comment by sebastien.wains on 10 Nov 2009 at 9:06

[GoogleCodeExporter]

Here is the post I was referencing.  Perhaps its not a valid point but I'm not 
sure 
what exactly is meant by "my other phone".  What other phone is this?

Comment 25 by piusvelte, Sep 22, 2009 Sipdroid still shows as UNREACHABLE in 
asterisk. I don't know if this is helpful, but 
these are differences that I've noticed from my other phone which is working 
perfectly 
with asterisk:

The Via header contains 127.0.0.1:0, whereas my other phone sends the external 
ip:port.
The To and From headers lack the port.
The Contact header value is <sip:sip:uri> in sipdroid, as opposed to 
<sip:externalIP:port> on my other phone.

Original comment by troutkin...@gmail.com on 10 Nov 2009 at 8:31

[GoogleCodeExporter]

@troutking1968,
I was comparing to other softphones that I'm using, specifically Ekiga and 
Windows 
Mobile 6 Internet Telephony.

Original comment by piusve...@gmail.com on 10 Nov 2009 at 8:50

[GoogleCodeExporter]

On a side note, this issue has the most stars.
Comment 5 says Antonio was working on this issue, back in May.
Can we get a word or two from the devs about the progress.

Is there any problem getting this figured out ?
Do you need help ? Testers ?

Original comment by sebastien.wains on 10 Nov 2009 at 8:58

[GoogleCodeExporter]

Further to comment #9, is there not a method to bring up a network connection in
Android that would also have an associated method to determine the IP address
currently assigned to the active interface? I guess I could go look.

Original comment by scott.wi...@gmail.com on 10 Nov 2009 at 9:04

[GoogleCodeExporter]

There is a project called 3gtest. Effectively this does some testing on your
connection. Although the name suggests otherwise, the tool will test 3g and 
WiFi. For
either connection type it is able to identify not only the IP address 
associated with
the NIC, it also finds out its public IP address. So for a 3G connection, 
you'll see
the device's IP address and the IP address that would show up in a web server 
log if
you were to visit a web page through a NAT-ed 3G connection.

Same is true for a WiFi connection. It will show the IP address from the private
range that has been associated with the WiFi adapter, as well as the public IP
address that would be used if you were to visit a public web site.

Perhaps this project can take some of the code (provided that the licenses are
compatible) that is used in the 3gtest project.

Original comment by stofre...@gmail.com on 10 Nov 2009 at 9:13

[GoogleCodeExporter]

When the sip client registers with the sip server, the server checks the 
ip:port that 
the client is announcing. If they are different from the ip:port that the 
server is 
receiving them from, as they would be when NAT'd, then the server tells the 
client 
the actual public ip:port. The client should then send future transactions 
using the 
updated information. I don't see sending the loopback address initially as the 
big 
problem here. It's that the client isn't updating the ip:port with what the 
server is 
returning. Sipdroid shouldn't go out of it's way to try to discover the public 
ip:port when this is handled by sip server as per protocol. Issues 21 and 149 
are 
also involved as the branch is supposed to be updated in the VIA header, and is 
not.

Original comment by piusve...@gmail.com on 10 Nov 2009 at 9:29

[GoogleCodeExporter]

As it has been stated the ideal solution would be to integrate STUN support 
into the 
client. Since this project was derived from the HSC java SIP client it begs the 
question, can the HSC STUN client be integrated?

http://www.hsc.com/tabid/87/Default.aspx

Original comment by carlos.t...@gmail.com on 10 Nov 2009 at 9:40

[GoogleCodeExporter]

Why add more complexity with STUN, when the sip server returns the correct ip 
and port 
and the client should simply use that? Read the server response, parse the 
received and  
rport values and set them as the ip and port, respectively. I posted about this 
in the 
developer group, and nearly had it fixed, but it requires some knowledge in the 
Sipdroid code that I don't currently have. The solution is readily available, 
and 
should be fixed to comply with the RFC's concerning SIP protocol anyway.

Original comment by piusve...@gmail.com on 10 Nov 2009 at 9:51

[GoogleCodeExporter]

Here are the relevant RFC's
RFC3261 - unique branch id
RFC3581 - use received and rport values

Original comment by piusve...@gmail.com on 10 Nov 2009 at 9:54

[GoogleCodeExporter]

I'm running rooted with Cyanogen 4.2.3.1.  I've got sipdroid 1.1.8.

I have the same problem.  I'm on my corporate wifi.  I have my phone registered 
with
our corporate Cisco Callmanager (via TCP).  I can call out both to extensions 
in the
network and to the PSTN.  When I do call out, I can't hear the other end, but 
they
can hear me.  In Callmanager, the IP address of my phone is displayed as 
127.0.0.1.

I unregistered my phone and registered X-lite on my PC using the same 
credentials to
the same device and Callmanager reported the correct IP address (the IP of my 
PC). 
If I go back to sipdroid, it still shows 127.0.0.1.

Thanks

Original comment by stevemas...@gmail.com on 11 Nov 2009 at 6:45

[GoogleCodeExporter]

How is it possible to use the file in post 9 to fix/bandaid this issue?

Original comment by stevemas...@gmail.com on 11 Nov 2009 at 6:58

[GoogleCodeExporter]

the problem of 127.0.0.1 is rooted from IpAddress.java,
public static String localIpAddress = "127.0.0.1";
then it is used by other code to initialization.
but when phone is connected to net via gprs/wifi, this address isnt updated to 
reflect the assigned ip address. 
and also phone ip address maybe nated, it also need to convert to the external 
public ip address and port .

Original comment by yuxiao...@gmail.com on 13 Nov 2009 at 1:07

[GoogleCodeExporter]

@yuxiao100,

It doesn't concern me that 127.0.0.1 is used for initialization. If the RFC's
concerning SIP, received and rport values are handled, then ip, nat, port 
problems
all go away. Those RFCs were created to deal with this problem.

Sipdroid should not look any further than the SIP server's response to find 
which
ip:port to use.

Original comment by piusve...@gmail.com on 13 Nov 2009 at 1:50

[GoogleCodeExporter]

Bump comment #34.  Can we get an update from the developers on the progress of 
this bug?

I have a Moto Droid that I am trying to get to work with asterisk.  If it will 
help I
can provide data from a Wireshark dump, or provide information from the asterisk
console.  I haven't posted these yet since it seems that the problem is well
understood at this point.

Original comment by bennet...@gmail.com on 13 Nov 2009 at 4:56

[GoogleCodeExporter]

Is the issue of SipDroid sending 127.0.0.1 and not the actual IP of the device 
going 
to be fixed? This seems to be the only issue in getting SipDroid to work with 
Cisco 
CM6.

Original comment by annettep...@gmail.com on 23 Nov 2009 at 10:46

[GoogleCodeExporter]

This is a known issue, but there's no interest in fixing it as the developers 
are
paid by pbxes.org and the use of your own asterisk server goes against their
interests (if you can have your own asterisk server for free, there's no need 
to use
pbxes service). 

There are several issues reported using other SIP servers which are all related 
to
this. The workaround is to set qualify=no on asterisk.

annetteparas: Check issue#109

Original comment by conex...@gmail.com on 24 Nov 2009 at 10:47

[GoogleCodeExporter]

Thanks conexcol but I do not have an Asterisk.  I'm trying to set sipdroid up 
as a 
third party SIP phone on a Cisco CM 6.1.3. CM sees it as registered but with an 
ip 
address of 127.0.0.1 which is not valid to it.

Original comment by annettep...@gmail.com on 1 Dec 2009 at 10:31

[GoogleCodeExporter]

Add FreeSwitch to the list. It does not like the fact the endpoint is using 
127.0.0.1 
as the contact IP address.

Original comment by carlos.t...@gmail.com on 1 Dec 2009 at 11:21

[GoogleCodeExporter]

Annette,

I am not even getting to that point where the phone is getting registered. I 
have Xlite (on a PC) working just fine, 
but Sipdroid just fails to regsiter. CM 6 doesnt even show the phone as 
registered...

Original comment by snair.sn...@gmail.com on 2 Dec 2009 at 1:33