Closed GoogleCodeExporter closed 9 years ago
Just a hint to the developers: the problem here is that in the "Contact" field
of the
SIP register Packet contains the Android's loopback address (127.0.0.1),
whereas it
should contain the network address (for example, 192.168.1.51).
Therefore Asterisk is sending the answer to 127.0.0.1:5060 (that is, to
himself) and
this is the reason why the error message on sipandroid says "Timeout" (this is
something that was lacking on the original message).
Ah, obviously, I'm having this problem too! :-)
If time allows, in the night I will check the code and try finding a solution.
Going back to work now... ;-)
Emiliano
Original comment by emiliano...@gmail.com
on 6 May 2009 at 8:15
Issue #9 is the same as this one. I have the same issues authenticating to my
FreeSWITCH. FS actually sends the response back to SIPdroid (I get the 403 on
the
SIPdroid side) but it is being rejected because of the above reason (Contact
gives
loopback device.)
Original comment by death...@gmail.com
on 7 May 2009 at 11:54
This requires NAT processing on the Asterisk server. Set nat=yes in the sip peer
definition to work around this.
Original comment by scott.wi...@gmail.com
on 8 May 2009 at 1:57
Also the realm attribute needs to be set to the fully qualified domain name of
the
asterisk server in the sip general settings....
Original comment by scott.wi...@gmail.com
on 8 May 2009 at 2:00
Hello All I Had The Same Problem, But Fixed It:
Check that your sip.conf file or freepbx looks like this:
[300]
callerid=
canreinvite=no
context=sip
dtmfmode=auto
host=dynamic
nat=yes
port=5060
qualify=no
record_in=Never
record_out=Never
type=friend
username=300
Then unset the password (Leave password blank) when there is a password set it
will
not login so leave the password area blank.
I hope this helps you all as it is a great product.
Andrew
Original comment by Andrewho...@googlemail.com
on 10 May 2009 at 6:05
Password is not an issue, it can be set and will not affect registration.
What it really matters is nat=yes (for registration) and canreinvite=no
(withouth
this you won't hear nothing on both sides)
Original comment by emiliano...@gmail.com
on 11 May 2009 at 7:41
Guys,
You are missing the point. SIPROID is not registering to the server. nat is set
to
yes, and canreinvite is set to no.
Original comment by vreme...@gmail.com
on 12 May 2009 at 3:05
I can't see the point: if you set nat=yes and canreinvite=no sipdroid IS
registering
(already tried on my server).
However, this is completely OT, so never mind.
Emiliano
Original comment by emiliano...@gmail.com
on 12 May 2009 at 8:32
What version of asterisk are you running? I tested this on Asterisk 1.4.21. I
can
register fine with any sip client including hard phones.
Original comment by vreme...@gmail.com
on 13 May 2009 at 12:13
"Private as well as public SIP servers are usually not made or properly
configured
for serving mobile clients. As you can see there is not just one issue. It's a
bunch
of adjustments to account for phones that are not plugged in to a single
network,
are battery powered and Java based. So unless you are a developer we don't
recommend
spending much time in getting your plain-vanilla Asterisk box suited for
Sipdroid.
Instead register your Asterisk to PBXes, too."
I have to disagree with this statement. Are you telling us SIPROID is not a SIP
client, but PBEXES instance of SIP? What about the RFC? We might as well rename
this
project to pbxesroid.
Original comment by vreme...@gmail.com
on 13 May 2009 at 12:16
Here is another attempt with 1.4.24-1. The newest version of Asterisk:
REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bK60893
Max-Forwards: 70
To: <sip:31337@domain.com>
From: <sip:31337@domain.com>;tag=z9hG4bK53179896
Call-ID: 752329879515@127.0.0.1
CSeq: 1 REGISTER
Contact: <sip:31337@127.0.0.1>
Expires: 3600
User-Agent: mjsip stack 1.6
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK60893;received=1.2.3.4;rport=1024
From: <sip:31337@domain.com>;tag=z9hG4bK53179896
To: <sip:31337@domain.com>
Call-ID: 752329879515@127.0.0.1
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK60893;received=1.2.3.4;rport=1024
From: <sip:31337@domain.com>;tag=z9hG4bK53179896
To: <sip:31337@domain.com>;tag=as5fcaac09
Call-ID: 752329879515@127.0.0.1
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="2fe2ff97"
Content-Length: 0
Original comment by vreme...@gmail.com
on 13 May 2009 at 12:26
Work around to get this to work is to remove
;secret=
Original comment by vreme...@gmail.com
on 13 May 2009 at 12:40
"Private as well as public SIP servers are usually not made or properly
configured
for serving mobile clients."
"I have to disagree with this statement. Are you telling us SIPROID is not a
SIP
client, but PBEXES instance of SIP? What about the RFC? We might as well rename
this
project to pbxesroid."
i agree.
i used SIP voip on WM based phones without any problem, Fring is one of them.
i insist on adding a STUN configuration on SIPdroid if is a SIP client and not a
PBEXES one.
http://www.voip-info.org/wiki/view/STUN
Original comment by massinissa74@gmail.com
on 13 May 2009 at 8:19
I'm using asterisk 1.4.22 and actually the last version available is 1.4.24.1
(from
www.asterisk.org)
Original comment by emiliano...@gmail.com
on 13 May 2009 at 9:10
R96 patch is not going to fix this issue.
Original comment by vreme...@gmail.com
on 13 May 2009 at 7:48
0.9.4 or R97 patch will only fix error notification. No word on fixing of this
issue.
Original comment by vreme...@gmail.com
on 13 May 2009 at 7:50
[deleted comment]
Issue still presists with 0.9.4 without removing secret or changing the realm.
REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bK69595
Max-Forwards: 70
To: <sip:31337@domain.com>
From: <sip:31337@domain.com>;tag=z9hG4bK00661318
Call-ID: 758165291997@127.0.0.1
CSeq: 1 REGISTER
Contact: <sip:31337@127.0.0.1>
Expires: 3600
User-Agent: mjsip stack 1.6
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK69595;received=1.2.3.4;rport=5060
From: <sip:31337@domain.com>;tag=z9hG4bK00661318
To: <sip:31337@domain.com>
Call-ID: 758165291997@127.0.0.1
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK69595;received=1.2.3.4;rport=5060
From: <sip:31337@domain.com>;tag=z9hG4bK00661318
To: <sip:31337@domain.com>;tag=as360cade9
Call-ID: 758165291997@127.0.0.1
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="775f9344"
Content-Length: 0
Original comment by vreme...@gmail.com
on 13 May 2009 at 8:57
It looks like siproid wants sip2 features:
To fix this issue add the following to your user setting in the Asterisk server:
auth=31337@your-password-here@your-domain.com
Original comment by vreme...@gmail.com
on 13 May 2009 at 9:03
Why didn't you just change the realm in Asterisk as Scott and Emiliano did?
Original comment by pmerl...@googlemail.com
on 13 May 2009 at 9:04
I did, and it works that way:
[31337]
username=31337
type=friend
context=unsecured-line
callerid=Android <31337>
nat=yes
host=dynamic
canreinvite=no
qualify=5000
;disallow=all
;allow=gsm
;allow=ulaw
auth=31337@my-super-secret-password@domain.com
Original comment by vreme...@gmail.com
on 13 May 2009 at 9:07
I am not sure how not having a password is a usable workaround. Yes, if I
remove the
password and have no security it can register and make calls. Does not seem to
receive them, however, though the invites are sent to the correct address of the
device they are to <sip:accountname@127.0.0.1> in the SIP header. Might be a
NAT
issue, I will check further.
Is this auth= line supposed to make it work? I've never seen a sip client
before
that needed a line like that or which had this issue authenticating, it's
certainly
something in sipdroid, not in asterisk. I've connected dozens of different sip
clients to my asterisk using fairly simple parameters once I get it working.
It's
just not sending in the authenticated invite or register after it gets the
challenge,
even though the nat control makes sure the challenge goes to the IP of the
android
phone (which is on my LAN via wifi).
Original comment by brad...@gmail.com
on 15 May 2009 at 4:53
bradtem, please re-read the comments especially Scott's. You don't need to use
the
auth= line, and you don't need to omit a password. These were just alternative
solutions.
Original comment by pmerl...@googlemail.com
on 15 May 2009 at 11:38
Sorry, I must be thick, because the suggestions did not make it work, other than
removing the password. I have nat=yes, have canreinvite=no. The phone
registers
to asterisk, asterisk responds with UNAUTHORIZED and provides the
www-authenticate
line -- but sipdroid does not send back a packet in response to the UNAUTH
message.
If I remove the secret, then it does indeed make calls because it does not need
to
respond to the unauth.
It also appears to not be responding to BYE messages. Or, I guess, to any messages
at all.
Some things that may be different: My asterisk is on port 5160, and has two
interfaces, one inside the NAT (with the sipdroid on wifi) and one outside the
NAT.
Original comment by brad...@gmail.com
on 16 May 2009 at 1:04
OK, essentially this issue is about the server name needs to be equal to the
domain
name at this time. So please set you realm in Asterisk accordingly. Once the
issue is
fixed Sipdroid will accept any realm to authenticate with.
Original comment by pmerl...@googlemail.com
on 16 May 2009 at 9:28
Ah. Well, both the auth= example above and the ones in the sip.conf
documentation
did not seem to work, but I was able to change my global realm and make sipdroid
respond with an authentication to the challenge on a register.
It still does not appear to respond to NOTIFY requests, which isn't a killer
(though
it means asterisk keeps retransmitting them, never getting acknowledgement.)
These
requests are trying to say how many voice mails there are.
Actually, it's still not responding to any requests (invites, "request pending"
errors, etc.) Could this be because I am on a different port from 5060? The
requests are going to port 5060 on the android phone.
Original comment by brad...@gmail.com
on 16 May 2009 at 7:22
I have tried most everything here, our realm on our gateways are already set to
the
fqdn of the server, we already have NAT turned on - so this all should have
worked.
Are there any ideas on how to get this working with an Asterisk gateway?
Original comment by troykel...@gmail.com
on 16 May 2009 at 8:39
Apologies, I should be clear - it is registering fine (however it shows up as
"UNAVAILABLE" in the peers list).
When I try and make calls, I see SIP traffic, and the attempt is there - but it
always fails.
Original comment by troykel...@gmail.com
on 16 May 2009 at 8:40
Now what I get is if there is no secret, it can register and it can make calls
but it
doesn't respond to requests like INVITE, BYE, NOTIFY which are sent to the
android.
If I have a secret (and the matching realm) it can register, but if it tries to
make
a call it sends the invite, gets the challenge, re-sends the invite with auth
and
then Asterisk responds with a request pending, even though this is the first
request.
It is as though * is treating the 2nd authenticated as another instance of the 1st.
There is no request pending (I tried this with a freshly booted asterisk)
Sip dialog attached
Original comment by brad...@gmail.com
on 16 May 2009 at 10:23
Attachments:
I am having the same exact issue as vreme...@gmail.com ... But I am trying to
register against a voip sip trunk provider (voicepulse) and not to a asterisk
box
and therefore do not have access to change sip.conf. After speaking to them,
they
saw the same issue that it was not nating properly. Response was being sent to
127.0.0.1.
Any suggestions?
Original comment by zebahme...@gmail.com
on 3 Jun 2009 at 3:37
I don't think there will ever be ideas.
The conduct of the owners of the project clearly shows that unless you are using
their gateway of choice (obviously with a non-standard sip implementation, and
horrific call quality) then you can go find some other SIP Voice client to use
on
your phone.
And ... I can't wait until there is another one. That works.
Original comment by troykel...@gmail.com
on 3 Jun 2009 at 7:51
@purpleoranges:
I hope you're wrong. However, even if you are right, this is an open source
project
so perhaps someone will fork the code and make it more compatible with standard
sip.
Original comment by jas...@gmail.com
on 4 Jun 2009 at 4:06
I have added realm=my.domain.com (the FQDN which points back to my Asterisk
box) and
still cannot get it to work. I am currently testing from within the gateway on
the
LAN, but will test outside tonight.
Anything else that is suggested to be done to get this to work? I have tried the
auth= line (doesn't work). Only removing the password works, but I don't feel
like
that is a solution.
Help appreciated, just tooling around and happy to see some* kind of sip client
on
android even if it's not perfect...
Original comment by kenneth....@gmail.com
on 8 Jun 2009 at 8:16
Issue 48 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 9 Jun 2009 at 7:52
Issue 52 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 14 Jun 2009 at 9:41
I'm not sure if this is the correct place to post this:
Sipdroid 0.9.7_full does also not register with sip.antisip.com over WiFi
(Timeout)
but over 3G/Edge, it works flawlessly.
Original comment by tscha...@gmail.com
on 17 Jun 2009 at 7:58
Modifying sip_additional.conf to the following did it for me. Note that I
comment
out the "secret" param. If I make any changes to the extension via the web
interface
it breaks again because it sets the secret once again.
[9444]
deny=0.0.0.0/0.0.0.0
type=friend
;secret=8015
qualify=yes
port=5060
pickupgroup=
permit=0.0.0.0/0.0.0.0
nat=yes
mailbox=9444@default
host=dynamic
dtmfmode=rfc2833
dial=SIP/9444
context=from-internal
canreinvite=no
callgroup=
callerid=device <9444>
accountcode=
call-limit=50
auth=9444@NumericPassword@DomainFromDyndns
Original comment by mario.fr...@gmail.com
on 23 Jun 2009 at 12:32
[deleted comment]
sip.conf:
[name1]
type=friend
username=name1
host=dynamic
nat=yes
canreinvite=no
context=sip
[name2]
type=friend
username=name2
host=dynamic
nat=yes
canreinvite=no
context=sip
extensions.conf:
[sip]
exten => 7777,1,Dial(SIP/name1,20)
exten => 7777,2,Hangup()
exten => 8888,1,Dial(SIP/name2,20)
exten => 8888,2,Hangup()
This seems to work fine with Sipdroid 0.9.6 version and up for both
applications run
from the source and from downloaded apk. In the settings name1 and name2 are the
usernames, the password field is left blank, the server field should contain
the ip
address of the asterisk server, which can be identified by typing "ifconfig" at
the
server root, and the port field should be 5060 by default. Both emulators can
call
each other using the numbers 7777 and 8888 for name1 and name2 respectively.
However, after adding a password in the user profile definitions in sip.conf, by
typing "secret=password1", only my x-lite softphone was able to register fine.
Sipdroid just couldn't register for some reason, unless the password
requirement is
removed.
Original comment by Silversp...@gmail.com
on 23 Jun 2009 at 3:55
Hi .. saw this about two months ago. suggest that this be bumped to high
priority,
client pretty much un-usable without fixing the contact header.
Original comment by elya...@gmail.com
on 28 Jun 2009 at 12:34
Issue 67 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 7 Jul 2009 at 1:18
@elyatus - I think we just need to find another SIP client. This one seems to be
built for one specific carrier only, which is useless to anybody not in the
states.
If the project was serious about a ~COMPLIANT~ SIP client, then this issue
would have
already been high priority, and would have been resolved by now.
Original comment by troykel...@gmail.com
on 7 Jul 2009 at 9:40
You as well as anybody else is invited to fix the issue. Antonio is already
working
on it. That's why I set the status to "Started". See
http://groups.google.com/group/sipdroid-developers for details.
For full interoperability you can also go to PBXes and register your carriers
from
there. PBXes is not a carrier, it's a virtual PBX providing data centers in New
York
and San Diego for users in the US. That's working pretty well. Try it out. The
basic
account is free.
Original comment by pmerl...@googlemail.com
on 7 Jul 2009 at 10:39
[deleted comment]
[deleted comment]
I've seen that there was a patch file for an earlier version solving this
issue. Is there available an apk file
of this version that is already patched? Would really like to test this
Original comment by HartwigE...@gmail.com
on 8 Jul 2009 at 7:29
@pmerle71 - Yes, anybody is welcome to fix the issue. I don't posses the skills
to do
so however, and until you are actually ~SIP~ compliant ... not "PBXes" the
product
should not misrepresent itself as a working SIP client.
PBXes is hopeless, particularly for anybody outside of the USA. Latency on
calls that
go via PBXes is horrific, along with audio path issues and many other problems.
It's not a solution I can even use for testing, let alone to actually carry a
real
phone call.
Original comment by troy.ke...@gmail.com
on 8 Jul 2009 at 8:02
When I applied the patch to the previous version of Sipdroid I could register
to my
provider, make and receive calls, but the other party could not hear me (though
I
could hear them).
So, looking at the comments on the thread for that patch, I modified sipdroid
to get
the realm from the remote end (from the 401 packet as Pascal suggested). All
this
actually requires is remove the realm check in
RegisterAgent.generateRequestWithWwwAuthorizationheader. Because sipdroid
passes the
remote www auth header into the DigestAuthentication, the realm is picked up
from there.
I can register fine with this change, but the previous audio issues remain.
ps, Sipdroid still speaks SIP, just because it only works with particular
configurations at the moment doesn't change that. Like most FOSS projects, it
scratches a developers itch. So DIY, fund a developer, or wait patiently.
Original comment by nigel....@gmail.com
on 8 Jul 2009 at 9:22
[deleted comment]
Original comment by pmerl...@googlemail.com
on 12 Jul 2009 at 9:53
Original issue reported on code.google.com by
vreme...@gmail.com
on 4 May 2009 at 9:35