Closed GoogleCodeExporter closed 9 years ago
Was it the case in previous version?
If not, really annoying... would mean that some server support only
<sip:user@domain.loc> uris and others supports only sip:user@domain.loc uris :S
Original comment by r3gis...@gmail.com
on 13 Nov 2010 at 10:49
I'm also interested in logs & the server (sip provider) you are using.
Original comment by r3gis...@gmail.com
on 13 Nov 2010 at 11:24
Hello,
actually I have quite a lot more problems, like the person I call or who calls
me hears everything back he/she says, bluetooth does not work I know it's
alpha^^ I use pbxes.org, there were some more problems but I can not remember
them anymore. I just switched today back from Sipdroid because it's not working
very well for me too, and I saw you had updated your dev version yesterday.
Original comment by make...@gmail.com
on 13 Nov 2010 at 11:32
I just tested version 0.00-15. It seems the(my) hang up bug does not occur on
that build. But a TCP connection does not work with pbxes, just UDP.
Original comment by make...@gmail.com
on 13 Nov 2010 at 11:48
For BT : you have to activate it by hand :
even if you hear something, it doesn't mean that bluetooth is activated - just
that the BT headset is used as a AD2P headset (so without micro). You should
also try with audio frequency set to 8kHz (that's more supported by BT SCO).
You have also to know that there is an awful bug in android 2.2 (that they
solved in 2.2.1) in bluetooth, and that on some devices BT and Wifi interfere
so things becomes really instable using BT + a voip app over wifi).
What is strange is that in 0.00-15-11 I've use my pbxes.org account to solve a
problem that was exactly about end call. And seems that pbxes.org servers
doesn't support simplified uris. But now with my recent changes should be fixed
(at least using my account it's fixed).
Are you sure you reproduce for both incoming and outgoing calls (and not only
for outgoing)?
And on what kind of other extension are you trying to call? Is there a
configured trunk to another provider? (If so maybe could make sense to directly
configure csipsimple to use this other account to test without pbxes.org
between)
Original comment by r3gis...@gmail.com
on 13 Nov 2010 at 11:58
Hi,
I tested it now with .12, and it seems to work again. Actually I had lots of
problems with BT, I thought it's because of the Bluetooth device I bought
(Nokia BH-214), I ordered another (Sony Ericsson MW600) to test that one. But I
saw you removed a lot of settings with the new build, why? With .15 I saw I
could edit the mic and earpieve amplification, that options are gone. Like I
said, I have this echo problem with my Samsung i9000, and it seems its because
the earpiece or the mic is too loud or not good enough shielded. I just tested
around with .15 and set both gains to 0.1, and that removed the echo, expect
that the mic is very quiet now.
Original comment by make...@gmail.com
on 14 Nov 2010 at 12:12
OK, I saw you put that into expert settings. I tested a little bit around, and
the only option seeming to work for my i9000 is mic gain 0,2 earpiece gain 0,1.
Other than that the one calling me gets an echo. What does Android audio stream
setting do? I switched a little bit around but it does not seem to change
anything. Anything else from the other settings I could/should try to optimize
echo? I switched to 8khz and deactivated every codec but Speex 8khz and GSM
8khz too.
Original comment by make...@gmail.com
on 14 Nov 2010 at 12:22
On .15 default settings on galaxy S are 0.4 & 0.2. I've no galaxy S to directly
test on, but this settings were reported to me on this issue list to solve the
echo problem (without BT).
> What does Android audio stream setting do?
Nothing on galaxy S. On all other android device (that has not this crappy
driver from samsung), it's the ~clean~ way to set the listening sound level.
On latest builds you can change the amplification during call (use volume
buttons).
I'd be really interested by logs about the first issue you reported.
In last dev version there is a facility in Menu > Help to activate log
recording... then reproduce the problem... then go back in help and press stop
recording and it will ask you to send me the logs directly.
Original comment by r3gis...@gmail.com
on 14 Nov 2010 at 12:30
On .15 default settings on galaxy S are 0.4 & 0.2. I've no galaxy S to directly
test on, but this settings were reported to me on this issue list to solve the
echo problem (without BT).
-I can definitely tell you, that 0.4 & 0.2 results in a bad echo for my i9000,
it's the international version not the US one, maybe that's the reason? I've
tested it, and the only settings 'working' are 0.2 mic and 0.1 ear.
On latest builds you can change the amplification during call (use volume
buttons).
-I saw that, but its useless without any text values, maybe you can add those?
That it shows the gain, without any text I cannot adjust during call.
I'd be really interested by logs about the first issue you reported.
-But the problems seems to be gone with your newest build. Or isnt it?
Original comment by make...@gmail.com
on 14 Nov 2010 at 12:37
I have another problem now btw, I cannot call out anymore, it goes directly
into hang up and I dont know why. I cannot send you any logs btw too, because
after I hit stop record nothing happens ;)
Original comment by make...@gmail.com
on 14 Nov 2010 at 12:56
OK, it seems .12 is still broken. I dont know why, but hanging up does not work
again anymore, it seems to hang up but after like 30 seconds later. And I
cannot call out anymore because I guess the line is still taken somehow and
pings out later sometime, then I can call out again. And like I said, I cannot
send you logs .-.
Original comment by make...@gmail.com
on 14 Nov 2010 at 1:54
Did you read my comments here?
Original comment by make...@gmail.com
on 17 Nov 2010 at 3:26
Yes sorry, forgot to reply.
Well, about logs I'm wondering something : you are maybe using the record call
feature (which record a .wav file of the conversation) and not the Log record
feature.
Log record feature is in the main CSipSimple dialer, press menu Help > Activate
log recording (or something like that, just under the FAQ line).
If you can't use this feature, you can still follow the old instruction
(HowToCollectLogs)
Original comment by r3gis...@gmail.com
on 17 Nov 2010 at 7:56
Hi,
no, of course I did use the log feature, not recoding calls, (from the dialer,
help, record logs to send it to dev team and report a bug). That feature does
not work, it just does not happen anything after stopping.
Original comment by make...@gmail.com
on 19 Nov 2010 at 9:44
Ok, sad :(
So twice more interested by your logs :). If you could try with the old
fashioned method described in the wiki could help me to understand where is my
mistake. (And also maybe improve the log reporting feature ;) ).
Thx
Original comment by r3gis...@gmail.com
on 19 Nov 2010 at 10:24
Did you change anything considering the pbxes problems in the latest dev build?
I cannot get that log thing working... I have another request actually, maybe
could you add a slide mechanic for ending calls like it is in Sipdroid?
Original comment by dustb...@gmail.com
on 28 Nov 2010 at 7:52
If you can't use the get log feature follow that instructions :
HowToCollectLogs It would really help me!
I'm absolutely not fan of the sipdroid UI with sliding. It's not common UI
scheme on android while the end call button is exactly the same behavior that
the stock android phone application.
The only slide there to end call is when your device doesn't support proximity
sensor and the UI is just like the froyo lock slider.
Besides, I plan to add a much more powerful drag and drop feature to manage
call end, hold call and conferencing.... stay tuned ;). So would be
incompatible with this slide to bottom to end call behavior.
Just un-learn every bad reflex you had took with sipdroid... their integration
with the android system is far to be good (IMHO), and there is a much more user
friendly way to manage things. (for example integration with android stock
contacts etc).
Original comment by r3gis...@gmail.com
on 28 Nov 2010 at 12:10
Hey! I see what I can do about the logs, the problem is but to have the error
logged because it is somehow not really reproducible -.- About the slider, Im
not with you here, because I like a slider much more, it is safer and somehow
more reliable for me. Why not make a choose option, letting the user choose is
always the best option and not making too much hard codings as a developer, I
hate that so much about mostly all applications, and I know you think you are
always doing your best as a develeoper I speak out of experience. But every
person likes it somehow different^^ I have another issue btw, should I open
another issue posting? It is just, that I noticed that CSipSimple permanently
uses between 2% and 3% CPU idle time, why is that so, cant that be changed?
Original comment by make...@gmail.com
on 28 Nov 2010 at 12:24
@makedir : ok. For the choose option, my approach if one really want to have a
custom in call interface is to add a "theme" application. I've done all the API
needed to do such an application.
So it is possible to have this kind of optional feature, but my approach is not
to put it in the core application. (That was the sense of my remark). In the
core app, I have other plans for user interface. I'll see that in the future,
that's also with drag and dropping but more user friendly ;).
Original comment by r3gis...@gmail.com
on 28 Nov 2010 at 1:08
The other part was a little bit more important to me, I should had say it that
way maybe^^ I have another issue btw, should I open another issue posting? It
is just, that I noticed that CSipSimple permanently uses between 2% and 3% CPU
idle time, why is that so, cant that be changed? <-
Original comment by make...@gmail.com
on 28 Nov 2010 at 1:10
Oh sorry forgot to reply this point.
Actually CSipSimple can run to be "always available".
If so it remains in background and try to keep the socket this the server
alive. It consume CPU time.
If you set csipsimple to be "only for ougoing call" it will potentially be in
background but will not run at all (android manage application itself and put
some application up in memory while they don't consume any CPU time).
Original comment by r3gis...@gmail.com
on 28 Nov 2010 at 1:49
Of course CSipSimple is running all the time in the background^^ but keeping
the connection alive, besides it is TCP, does not take CPU time every second my
guess was? You can look up with top or other process listings that CSipSimple
permanently uses ~2-3% CPU time so it is not really idling.
Original comment by make...@gmail.com
on 28 Nov 2010 at 2:01
TCP doesn't change anything if you don't change keep alive time (switch you
account to an expert account).
Anyway you should not get this value.
On my nexus one, even in mode run in background, top give a CPU of 0%....
Wondering so maybe something else particular to your configuration :
* Some sip server send you a lot of sip messages (some sip servers send keep
alive messages besides of csipsimple messages).
* Check if lock CPU is not set to on in settings.
Else try to do a ps -t 37821 where 37821 is the PID of csipsimple.
It may help to see what are the threads associated to CSipSimple tehre is maybe
something to see interesting doing that. Maybe some audio thread is still
running.
Original comment by r3gis...@gmail.com
on 28 Nov 2010 at 2:14
There are no settings for keep alive time, I thought it would be set to a
higher value by default when using TCP. ps result:
com.csipsimple
HeapWorker
Signal Catcher
JDWP
Compiler
Binder Thread #
Binder Thread #
Binder Thread #
UAStaeAsyncWor
Thread-57
Thread-57
And no, it idles at 2-3% all the time on my phone.
Original comment by make...@gmail.com
on 28 Nov 2010 at 2:25
Ok, no strange thread sounds good for that point.
For keep alive setting : transform your account into an expert account, you'll
see all settings to tune the behavior of the keep alive (and re-register
timeout) for this account.
(Just for info, the application is really tunable but that's for power users,
for main stream I keep things hidden... and should remain hidden for main
stream... the approach is to get optimized things for main stream users but
provide a way for power users to change settings).
However again, on my phone I don't see such an activity (and with default
options).
My guess is that it is your SIP server (your provider) that frequently send you
some "Option" or another packet that make the activity alive.
This could be easily detected with logs.
You can also try to reboot your phone, in the doubt could maybe help, but my
first thought is about a talkative SIP registrar.
Original comment by r3gis...@gmail.com
on 28 Nov 2010 at 2:41
I dont get why you choose to put up that kind of way how you have to set it up.
Why dont you put fundamental settings like keep alive timings into the normal
expert network setting menu. And I was not able yet to create an "expert
account" or "transform" it. Besides Im using pbxes.org I thought you do too, so
the question about it being "talk active" should be answered.
Original comment by make...@gmail.com
on 28 Nov 2010 at 3:02
Keep alive is *not* a global setting that's a setting relative to an account
!!! So it has to be set into accounts settings. That's absolutely logic. Other
sip software doesn't support multiple accounts... So everything is mixed in the
interface.... Here you have settings about the account and global settings.
It's separated.
In global settings there is a basic mode (the easy setting line) (for main
stream users that don't know everything about SIP). There is the advanced mode,
the three other lines. And the expert mode (press menu and switch to expert).
In accounts there is the same thing, Basic account (or any branded wizard),
Advanced account and expert account. And you can switch from a wizard to
another.
To transform an account that's pretty simple :
Long clic on the account row. And select "choose wizard" and choose expert.
I don't use pbxes.org. In most of cases that's absolutely useless and you can
directly plug to your true SIP provider. (SipDroid which is developed mainly by
pbxes.org advise to use their service, but SIP is *not* only pbxes.org. (There
is advantages to use their service indeed, but that's not absolutely required).
Try to understand, you are trying to do things that a power user do. It's
normal that the interface is more complicated for you. If you were just a
mainstream user, you'd don't want to bother with these strange settings...
That's the reason why there is many level of interface.
Think about that, you don't succeed in creating an expert account while for
somebody that know about sip it is absolutely possible all the more so as the
pbxes.org wizard actually create an expert account, just like all other
accounts.
I could have done only the expert wizard... but you and a lot of other users
would have been absolutely lost.
Original comment by r3gis...@gmail.com
on 28 Nov 2010 at 3:18
Nevermind, you got me wrong there. That you can transform an account just by
reclicking wizard did not make sense. But CPU usage does not change when I
delete or deactivate the account.
Original comment by make...@gmail.com
on 28 Nov 2010 at 3:41
What is the thread that eat all the cpu time?
You can get it with :
top -t -m 10
Did you try to reboot the phone?
(As for transforming an account, again, that's for power users, UI is not
intended to be user friendly for them... I focus on features for mainstream for
now and not for power users features... power users can manage this kind of
more complex approach in the UI for now).
Original comment by r3gis...@gmail.com
on 28 Nov 2010 at 4:16
[deleted comment]
Yes I rebooted my phone sometimes before, sensorserver_yamaha 4% and csipsimple
2%, like I said csipdroid idlest at ~2% sometimes jumps to a little bit more
too.
Original comment by make...@gmail.com
on 28 Nov 2010 at 4:54
Coul you please give me your email address for the logs?
Original comment by make...@gmail.com
on 29 Nov 2010 at 11:01
developers[at]csipsimple.com
Original comment by r3gis...@gmail.com
on 29 Nov 2010 at 1:08
I have emailed you the logs, no respond yet, maybe you can write back to that
email of mine too instead of posting here.
Original comment by make...@gmail.com
on 30 Nov 2010 at 6:41
For reference was due to UDP transport.
Now UDP transport is automatically activated by default.
@mkdir : as for other hints, it's in my mind don't worry ;). I'll try to
reproduce CPU as soon as I'll get my i9000 (next week).
And I'm about to refactor filters features and I'll include your remark about
GSM.
Original comment by r3gis...@gmail.com
on 12 Dec 2010 at 7:28
Original issue reported on code.google.com by
make...@gmail.com
on 13 Nov 2010 at 10:24