Sent-by Address: 127.0.0.1 about sipdroid

[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:[email protected]>
From: <sip:[email protected]>;tag=z9hG4bK87373289
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]>
Expires: 3600
User-Agent: mjsip stack 1.6
Content-Length: 0

Original comment by [email protected] 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:[email protected]>
From: <sip:[email protected]>;tag=z9hG4bK26630175
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]>
Expires: 3600
User-Agent: mjsip stack 1.6
Content-Length: 0

Original comment by [email protected] 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:[email protected]>.
From: <sip:[email protected]>;tag=z9hG4bK60423525.
Call-ID: [email protected].
CSeq: 1 REGISTER.
Contact: <sip:[email protected]>.
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:[email protected]>;tag=316ae364d36f7a841168df84601ddb59.8a0f.
From: <sip:[email protected]>;tag=z9hG4bK60423525.
Call-ID: [email protected].
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 [email protected] 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:[email protected]

may be something we the router not configured properly?

guido

Original comment by [email protected] on 20 May 2009 at 10:23

[GoogleCodeExporter]

Antonio started working on this issue.

Original comment by [email protected] 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 [email protected] 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 [email protected] 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 [email protected], so on incoming 
calls, the
message loops. 

Original comment by [email protected] 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 [email protected] 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:[email protected]
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 4 Sep 2009 at 10:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by [email protected] 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 [email protected] on 21 Sep 2009 at 1:30

[GoogleCodeExporter]

Original comment by [email protected] 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 [email protected] on 22 Sep 2009 at 9:30

[GoogleCodeExporter]

Issue 141 has been merged into this issue.

Original comment by [email protected] 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 [email protected] on 22 Sep 2009 at 5:34

[GoogleCodeExporter]

Port 0 should no more be announced in 1.1.0.

Original comment by [email protected] 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:[email protected]>
From: <sip:[email protected]>;tag=z9hG4bK10069008
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]>
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 2 Dec 2009 at 1:33

[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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 10 Dec 2009 at 11:41

[GoogleCodeExporter]

Original comment by [email protected] on 12 Dec 2009 at 1:52

• Changed state: FutureRelease

[GoogleCodeExporter]

Original comment by [email protected] 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 [email protected] 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 [email protected] on 12 Feb 2010 at 5:05

Attachments:

• stun.patch

[GoogleCodeExporter]

Looks good to me. Check it in, please.

Original comment by [email protected] 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 [email protected] on 15 Jul 2010 at 11:55