Open GoogleCodeExporter opened 9 years ago
Which provider have you been using? Did you make a SIP trace?
Original comment by pmerl...@googlemail.com
on 18 Sep 2009 at 7:16
Happens with all providers, i.e. Vodafone for 3G and with all internet
providers
(wifi). I don't really know what and how to do a SIP trace, but I can happily
make on
if you tell me how. Also, this also happens after a full wipe, after changing
the rom,
even after changing country :D
Original comment by a.splendiani@gmail.com
on 19 Sep 2009 at 9:32
I wanted to know what you've entered as SIP server.
Original comment by pmerl...@googlemail.com
on 19 Sep 2009 at 10:25
Sorry, I didn't get that was the question. I am using EuteliaVOIP.
Original comment by a.splendiani@gmail.com
on 21 Sep 2009 at 8:09
We don't care on incompatibilities to single providers here. Please track the
problem
down to the real bug (the sip messages that are not processed properly for
example) or
discuss the problem in the user's group.
Original comment by pmerl...@googlemail.com
on 21 Sep 2009 at 8:26
LOL,
so I am using PBXes, which _suggests_ to use EuteliaVOIP, and sipdroid makes it
almost _mandatory_ to use PBXes, and "you don't care about incompatibilities
with
single providers"?
Dude, something's wrong.
Original comment by a.splendiani@gmail.com
on 22 Sep 2009 at 7:22
There might be some misunderstandings here:
1) Have you been using EuteliaVoIP thru PBXes or directly?
2) It does not make sense to say "it does not work with EuteliaVoIP" unless you
provide
more research to the problem.
Original comment by pmerl...@googlemail.com
on 22 Sep 2009 at 7:49
Alright,
so, I don't want to waste your time, nor mine, so let's go through the
misunderstanding.
1) I am using EuteliaVOIP through PBXes.
2) Ok, I just did the test. I let the telephone go in stand-by mode. Then I
tried to
place the call, it did not work. I checked on the call log of both PBXes and
EuteliaVOIP and there is no trace of the call.
Tell me if there is any other info I can provide.
Original comment by a.splendiani@gmail.com
on 22 Sep 2009 at 8:01
Original comment by pmerl...@googlemail.com
on 22 Sep 2009 at 2:01
Hi, since the problem is still persisting, I would like to check the log of
when and
how sipdroid registers to PBXes. Can you tell me how to check this information?
Thank you.
Original comment by a.splendiani@gmail.com
on 1 Oct 2009 at 8:59
Also, I made some tests and I have got some useful information that could be
hlpful
in solving the problem.
After (exactly?) 60 seconds of SIPDROID outbound inactivity (not cellphone
inactivity), so for example, after 60 seconds you have placed a call, or after
60
seconds SIPDROID registers, it won't allow you to place an outbound call.
If you try, the dot turns instantly to yellow and the call ends. Then it
re-registers
again and you can place a call if you do it withing 60 seconds. The new
information
compared to the first post is the time frame, 60 seconds, I don't know if there
is
any inner setting with that duration.
Strangely enough, if even after 60 seconds you try to RECEIVE a call, it works.
I
have tried waiting, say, 5 minutes, receiving a call (it works) and right
afterwards
trying to place a call (it doesn't). So the 60 seconds time is from the last
outbound
action.
Any clue?
Finally, and I don't know if this helps, _everytime_ I place a call with
sipdroid the
dot turns yellow. But when it works, it also turns green again in half a
second. When
it doesn't, it eventually goes to red (and then re-registers, of course).
Original comment by a.splendiani@gmail.com
on 1 Oct 2009 at 9:36
Change protocol from UDP to TCP and it'll work.
Original comment by pmerl...@googlemail.com
on 2 Oct 2009 at 8:44
It is already using TCP...
Original comment by a.splendiani@gmail.com
on 2 Oct 2009 at 8:53
I had a similar problem. Unfortunatly Sipdroid send REGISTER before the INVITE
every time you try to make an outgoing call. I guess some networks can not
handle this properly. It would be nice if Sipdroid would wait for response on
the REGISTER before sending INVITE.
/ mandrajg
Original comment by mandrajg@gmail.com
on 20 Jun 2010 at 7:12
Original issue reported on code.google.com by
a.splendiani@gmail.com
on 18 Sep 2009 at 2:46