Contact pictures are not always shown

[GoogleCodeExporter]

I understand that this app aims to fully integrate with the native phone 
application. Therefore, the following 2 points:
. I don't understand why it needs an own dialer (apart from entering sip 
addresses)
. When receiving calls UI is not the native one on n1 froyo
. Contact pictures are not always shown

Caller is superfast, faster than sipdroid.
Thanks

Original issue reported on code.google.com by alessand...@gmail.com on 27 Jul 2010 at 9:44

[GoogleCodeExporter]

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

• Changed title: Contact pictures are not always shown
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

" 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

[GoogleCodeExporter]

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

• Changed state: Accepted

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

No worries

Original comment by alessand...@gmail.com on 4 Aug 2010 at 11:06

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Verified