Closed GoogleCodeExporter closed 9 years ago
So, in fact when I write "native sip" I mean using a native sip library (which
is faster than a java stack like in sipdroid).
For your first point, the in-application dialer is here for a good reason :
For example if you don't want csipsimple to be integrated in native dialer:
There is an option in Menu> Settings > User Interface... > Activate
integration to choose if you want or not use the native dialer integration.
Beside user interface is not yet finished. (Remember, this is still an alpha
version !)
There is also an option in user interface option to choose to start with the
text dialer interface (for now a little bit buggy since you have to quit the
app and restart it to make the change valid).
For your second point, it's technically impossible to use the calls UI from the
standard android telephony interface. What I did is reuse code for both dialer
and in call interface from the android git source code. But I planned that
third party application can override theses view by customizing it with other
themed versions.
Besides of the technical limitation, the in call interface of sip call is
necessarily different from a GSM call, features such as conference etc etc are
different between sip calls and gsm calls.
For your last point I'm really interested in a scenario to reproduce the issue.
For now, the current implementation search in your contacts if any of them has
a number that matches the username field of the sip address (DisplayName
<username@domain.loc>). If "username" match *exactly* one of your contacts
phone numbers it will display his picture and his name (this search is done
asynchronously so it first display a blank picture and DisplayName or username
if looks like a phone number or fill sip address).
There is maybe issues with some specific contact phone number. This part was
not fully tested, for example maybe phones numbers that start by a "+" are not
well supported etc etc. So a more detailed description of this particular issue
could help me to find out what is wrong.
As I answered the two first point, I change the issue title to track the last
point. I wait for more details to be able to start this point.
Thanks in advance.
Original comment by r3gis...@gmail.com
on 27 Jul 2010 at 10:05
Thanks for clarifying ui integration to me.
When I use my sip2sip account for outgoing calls to a +4x123456789 number which
I choose over android contacts manager and using GSM is displayed with name and
picture, when using sip no picture and name is displayed.
However I have another sip account which I use only for incoming calls and when
dialing with that one picture and name are displayed...
Original comment by alessand...@gmail.com
on 27 Jul 2010 at 10:22
A more general question: when using csipsimple telephone interface I cannot
choose which sip account to use for outgoing call. App automatically chooses
which sip account to use.
Is it possible to set an account only for incoming calls? I use sip2sip for
outgoing and sipcall free for incoming which gives me a +41123456789 nr where I
can be reached for local tariffs.
Btw this would work fine when using pbxes... but I don't like a German server
to store my call behavior
Original comment by alessand...@gmail.com
on 27 Jul 2010 at 10:31
" For your second point, it's technically impossible to use the calls UI from
the standard android telephony interface. "
Why is it technically impossible ? Is it simply because of a lack of an API ?
Is the UI encrypted code ? If the carrier link could be replaced by a SIP link
it would solve a lot of lingering issues. eg: lack of bluetooth functionality,
perfect call record keeping, etc.
Original comment by Djoneslo...@gmail.com
on 27 Jul 2010 at 5:47
Well, I try to explain this point a little bit more.
The more important thing to understand is that the telephony application is an
application that aim to manage GSM / CDMA calls. And not sip calls. Sip call
management is different from GSM/CDMA calls management. Just read the code of
the android *standard* application :
http://android.git.kernel.org/?p=platform/packages/apps/Phone.git;a=tree;f=src/c
om/android/phone;h=9b6b2b6d778c2d6d178953bec89ff6d18c192584;hb=HEAD and you'll
maybe understand where the problem is.
I have reused a lot of this code but :
* Everything can not be reused due to the fact this is done to manage cdma/gsm
calls
* Theses phone applications use private APIs (which are known but that we
should not use see next point).
* Each phone manufacturer can rewrite his own phone application and manage
sound, device etc etc differently. So official audio api should be use
* Some device has no phone application
* Phone application doesn't provide API at a detailed level (and that make
absolutely sens)
Just read the android git code, if you understand java and has some skills in
android development you'll understand a lot of things.
Else just trust me ;) : reusing code and take inspiration of what is done in
the android open source project is possible (and is already done). But use the
in-call UI from the standard android phone interface make no sens.
Original comment by r3gis...@gmail.com
on 27 Jul 2010 at 6:42
I can fully understand the need for 3rd party plugins, which i think is what
you are driving at (at some point in your last comment) .
However then again it doesn't fill the current need nor does it save users
time/money when making and receiving calls. Right now there is no solution, and
atleast something is better than nothing.
So i propose the following once cSip is brought to its first stable release.
Split the project into 4 two part sections.
cSipSimple Remote - Which would be cSipSimple in its current form with
developer support.
cSipSimple Local - Which would interact with the original phone api .
And which has the ultimate goal of filling the need to solve the underlying
issues.
Both branch and trunk builds (Stable and Alpha)
I understand the reasoning for taking a proactive approach to development
however we should try to take a reasonable approach to development as well.
Understanding that getting solutions into the hands of consumers ultimately
helping conserve energy that would lead to protecting the environment should
always be the top goal.
We need to look at this as well, it might be months or even quarters/years
before a backwards compatible bluetooth solution is ratified without direct UI
integration.
Original comment by Djoneslo...@gmail.com
on 27 Jul 2010 at 9:48
Well, I fear my comment was not clear, surely due to my bad English.
Your "cSipSimple local branch" is just impossible : I mean technically
impossible.
Try to write some code and you'll see.
You think that if it was possible all other android sip application had also
re-implemented their own in-call views?
As far as I understand, what you'd like is something absolutely integrated
within a custom rom's phone app.
(I've seen your issue on cyanogenmod - and I think that CSipSimple is not yet
enough mature to be integrated for a daily use -)
But well, I think that what you want is just CSipSimple becoming more stable
and full featured.
The "original phone api" - which doesn't exist as you think it is - will not
solve this issue at all.
Don't worry I know exactly were I want to go, and I'm still far to have reached
my goal. What I deliver is an *alpha* version just for tests. Even, when it
will be a beta and the first stable version will not include all features. This
is not a proprietary software and it will live grow, add features and
improvements for years (at least I hope :) )!
Besides, a custom rom integration (as the representation you have of it) is not
a good idea to integrate directly to the phone app.
There is many technical reason for that and also reasons linked to the project
management (merge with both updates from the android git and the csipsimple svn
is unbelievable. Imagine, when I will implement the transfer call, hold call
and multiple call management... how to merge with a version totally rewritten
within the native phone application? And what about voice mail integration, and
features that are not present in GSM/CDMA calls but present in SIP. And what
about when IMS, 4G, LTE will appear in android?...
If it's just the Bluetooth that afraid you, I'll reassure you my think is that
it should take about 1 or 2 week to be implemented in the current version of
csipsimple (provided the fact I own a bluetooth handset to test on... ). The
android api is not so complicated on this point.
Regarding the proactive approach from development or user.... You know, I'm a
child of opensource projects such as Blender, Firefox etc etc.
And CSipsimple is an opensource project. I code only for my pleasure, there is
no commercial engagement. The backward effect is that priority is given to the
feature contributors of the project want to give time. But if a feature is
worth to be implemented, be sure that there will be contributors that will
implement it.
I try to take into account all request and suggestion from users since I think
they are really important and will make the app provide a better user
experience. But let developer choose what they want to develop. Else each code
contributor will stop developing if that's not a pleasure to develop but a task
asked by somebody and they don't really need it and you'll have nothing....
Besides please, don't say me how to code and design the app (OR code it
yourself ;) and contribute !!! ).
If you prefer to pay for having exactly what you want and don't want to code
anything, opensource model is not for you and you should use some proprietary
application :
Ask some enterprise to code the application for you, but I ensure you that
price will not be the same and probably you'll not have features that you never
though to.
P.S. : sorry for the spamming Alessandro, not really related to your first
issue. But this point is probably important to clarify.
Original comment by r3gis...@gmail.com
on 27 Jul 2010 at 10:55
Regarding contact pictures, I can confirm that 000-12-7 does not show pictures
when the prefix is '+' . Using '00' works as expected. I know that Google Voice
only supports '+' as a prefix, as that is what comes in to my phone whether I
originally use '+' or '00' to contact it.
Original comment by robert.b...@gmail.com
on 3 Aug 2010 at 11:16
I think that most "old school" phones do fuzzy matching: if the first few
characters are different but the rest are the same they consider it to be the
same number and show you the contact information from the address book.
Original comment by egcros...@gmail.com
on 3 Aug 2010 at 4:34
No worries
Original comment by alessand...@gmail.com
on 4 Aug 2010 at 11:06
Check changes in r181, this may fix it. I have '+' prefix numbers. It may only
work on SDK > 5 though (I test on Android 2.1-1).
Original comment by dc3de...@gmail.com
on 5 Aug 2010 at 8:54
Thanks to logcat from Robert P., I detect that there were no contact lookup if
phone number contains +.
In fact, I had a test that check if username is a phone number before searching
into contacts. r187 is now more permissive and will search even if contact uid
contains +, *, #, -, ( and ). Besides if contact uid lookup fails, it tries
with display name.
Code has been factorized to be used by Ringer and by InCallInfo class. (Should
probably be used for CallLogs too).
@egcrosser : fuzzy matching is probably not really easy to do since we use a
fixed api provided by android to lookup into contacts.
I've not read how it's done inside the android code on this subject. Maybe
fuzzy search is already done... But as for now (thanks to Bob), what I can
affirm is that contact lookup in csipsimple will not be worse than the official
GSM telephony application of android (since they also relies on the same api).
The only thing we can fail for is either not trying to do the search (my guilty
fault) or not finding out the good thing to search provided the sip From header
(and has just been improved).
Original comment by r3gis...@gmail.com
on 7 Aug 2010 at 2:30
I can confirm that the look-up now works with the prefix "+" on Android 2.1,
thank you very much. It still writes 'Unknown' to the Call History, even though
it finds the number.
Original comment by robert.b...@gmail.com
on 7 Aug 2010 at 2:51
Well as for call history I've another issue open for that. So I close this one
(just to make the issue list more clear ;) )
Original comment by r3gis...@gmail.com
on 13 Oct 2010 at 5:20
Original issue reported on code.google.com by
alessand...@gmail.com
on 27 Jul 2010 at 9:44