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]

I'd like this to be solved also!
There is the same problem as the others have, Asterisk registration fails. 
After a
wireshark sniffing I suppose this must be a problem at the contact 127.0.0.1 
entry.

Original comment by jei...@gmail.com on 2 Dec 2009 at 3:11

[GoogleCodeExporter]

Snair.snair: 
Try using TCP instead of UDP, check "Media Termination Point Required" and 
change 
MTP Preferred Originating Codec to 711alaw. These changes allowed the phone to 
register, but only one-way voice on outbound calls and no inbound at all, 
because CM 
cannot see the actual IP address of the phone.

Original comment by annettep...@gmail.com on 2 Dec 2009 at 9:48

[GoogleCodeExporter]

I had this same problem with getting Sipdroid to connect to my local Asterisk 
PBX and
solved the problem by including:

nat => yes

in the appropriate definition in the sip.conf file.  I would guess that some 
similar
configuration should be possible with other PBX such as Cisco but I have no 
actual
knowledge or experience there.
I agree that it would be preferable to have sipdroid pick up the IP address 
assigned
to the WLAN interface, but at least it works.

Original comment by lannetli...@gmail.com on 3 Dec 2009 at 10:10

[GoogleCodeExporter]

The solution setting "nat = yes" works only in the same subnet!
If asterisk and sipdroid are in different subnets then audio works onl in the 
way
sipdorid -> asterisk, asterisk -> sipdroid wont work.
So, please sipdroid developers, change 127.0.0.1 to the right IP address of the 
phone.

Original comment by jkak...@gmail.com on 4 Dec 2009 at 8:26

[GoogleCodeExporter]

nat=yes is just a partial workaround.
Both in TCP and UDP modes, Sipdroid is able to register to my server and tries 
to make calls but no audio can be 
heard. There's surely a problem with nat traversing.
In my specific situation, if receiving a call using Sipdroid, audio works both 
ways. No way to make it work to call 
out.

Original comment by drag...@gmail.com on 5 Dec 2009 at 10:27

[GoogleCodeExporter]

I've noticed that on calls out to the PSTN through an audiocodes gateway the 
call ends 
when the gateway sends a 488 not allowed here.  The gateway apparently does not 
like 
the video in the SDP.  I tried change video=false in the profile, but no dice.  
I think the 
UA should renegotiate after a 488 instead of end the call.  With calls to other 
IP UAs no 
audio and call ends after about ten seconds.   

Original comment by khaef...@gmail.com on 5 Dec 2009 at 5:45

[GoogleCodeExporter]

Having the same issue with SIPDroid registering as 127.0.0.1 on CCM 6.2.  This 
is
causing the other endpoint on the call to send all RTP packets to 127.0.0.1.  
Would
love to get this resolved.

Original comment by mrintz...@gmail.com on 7 Dec 2009 at 9:13

[GoogleCodeExporter]

There is a project called SipAgent that one can get from the Android Market. It 
is in
beta, but is works with my asterisk server. E.g., it registeres without any 
problem
and I'm able to make calls to and from the SIP number. This proves that a SIP
implementation actually can be done.

The draw-backs are that it has a built-in call-duration limit of two minutes 
and the
developer is hesitant to include 3G support (the tick box is there, but it 
doesn't do
anything). 

Perhaps this project can get in contact with the developer of the SipAgent 
project to
investigate how he has implemented the standard SIP stack and then implement it 
in
SipDroid. This would take away all the difficulties this project has around
registering with standard SIP services.

If for whatever reason standard SIP is incompatible with PBXes, perhaps this 
project
can call the code from the SipAgent project whenever SipDroid is configured to 
use
anything else than the PBXes infrastructure.

Original comment by stofre...@gmail.com on 7 Dec 2009 at 9:42

[GoogleCodeExporter]

Gave up on SipDroid. Tried SipAgent Beta. Works great with CM 6. SipDroid has 
more 
options and I'd love to be able to use it, but without it's sending the correct 
IP 
nogo! Try SipAgent Beta.

Original comment by annettep...@gmail.com on 10 Dec 2009 at 9:49

[GoogleCodeExporter]

I wonder if the developer actually reads these messages and realises that not 
fixing
this is making people go elsewhere for a solution.

Original comment by jazz13 on 10 Dec 2009 at 9:52

[GoogleCodeExporter]

There's one more you can try. It's called aMobbyTouch: 
http://www.androlib.com/android.application.org-hw-sipua-xACp.aspx

The funny part is that's clearly a rip of sipdroid but with this issue fixed 
and 
includes support for multiple profiles. You might want to try it with CM.

Original comment by carlos.t...@gmail.com on 10 Dec 2009 at 10:05

[GoogleCodeExporter]

aMobbyTouch seems to be working in the right way with Askerisk. It's clearly a 
fork of SipDroid (look at the 
SipDroid user agent it uses to register). Too bad it's so buggy, at the moment, 
and doesn't seem to support the 
GSM codec.
SipDroid is quite ahead, but this issue is quite annoying. I don't think it'd 
be hard to fix.

Original comment by drag...@gmail.com on 10 Dec 2009 at 11:41

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 12 Dec 2009 at 1:52

• Changed state: FutureRelease

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 14 Dec 2009 at 8:54

• Changed state: Fixed

[GoogleCodeExporter]

[username]
callerid=
canreinvite=no
context=internal
dtmfmode=auto
host=dynamic
mailbox=2099
nat=yes
port=5060
qualify=no
record_in=Never
record_out=Never
secret=password
type=friend
username=username

I used those settings with my asterisk server with is not in the same subnet
(asterisk 192.168.1.asterisk) My own network 102.168.2.client the router of my 2
network has a 192.168.1.router adres the registration works now but calling 
still
won't work. The server see the 192.168.2.sipdroid. My guess is that asterisk 
does not
know this adress so wont know where to send the response. 

Dont know if i should make a other issu for this cause it is very related to 
this one.

Sorry for my not so well English.

Original comment by Pimmetje on 15 Dec 2009 at 5:38

[GoogleCodeExporter]

Thank You Devs!!! :-)
This fixed my problem and made my phone usable with our asterisk server.  Now 
all I
have to do is convince the boss to pay for the phone!

Original comment by bennet...@gmail.com on 17 Dec 2009 at 3:30

[GoogleCodeExporter]

Below is a preliminary patch for STUN support within sipdroid. I took the jstun 
code 
from HSC and incorporated into sipdroid. Can this be incorporated in a future 
release? 
Thanks.

Original comment by carlos.t...@gmail.com on 12 Feb 2010 at 5:05

Attachments:

• stun.patch

[GoogleCodeExporter]

Looks good to me. Check it in, please.

Original comment by pmerl...@googlemail.com on 12 Feb 2010 at 9:15

[GoogleCodeExporter]

I'm still having problems with this.  I am accessing my Asterisk server via 
VPN.  On the Sipdroid side i have an ip address of 192.168.0.81 and the server 
is on the 10.0.0.0 network.  For some reason Sipdroid now sends the Via header 
with an address of 192.168.42.129 which exists NOWHERE on any of our networks.

The only thing I can think of is that it's the IP assigned by my carrier and 
it's the 3G IP address.   Shouldn't Sipdroid check to see what type of 
interface the IP is for before deciding to use it?

I've looked at the code in the setLocalIpAddress() method of the IpAddress 
class and as a jaded old SIP developer, the code makes little sense to me.  
Sure, I can tell what it's doing, I just don't know WHY.  It loops through the 
network interfaces looking for a non-loopback address, which makes sense, but 
once it's found one it keeps looping and looking for more.  Shouldn't it a) 
make sure the interface is of the correct type dictated by the preferred 
interface settings and their current state and b) return from the method once 
it has found an IP address?  

The only thing it appears to check is if STUN is preferred.  Wouldn't it make 
sense to use the IP address of the interface that is actually active and 
preferred?  In my case, this is the WiFi interface.

Original comment by jazz13 on 15 Jul 2010 at 12:49

[GoogleCodeExporter]

Would the route table not be useful to figure out what interface and therefore 
IP address would be used to send a packet to a network?

Original comment by scott.wi...@gmail.com on 15 Jul 2010 at 11:55