Does Live Caller ID Lookup entirely replace Call SIP content, or are they ever combined?

If an iPhone receives an incoming call with some partial sip content (for example it contains a name but not an image, or vice versa) and if there is an app enabled for Live Caller ID Lookup, and the result of that lookup supplies data not in the sip (i.e. the lookup returns an image, but not a name, or vice versa).

By "sip content", do you mean calls reported by 3rd party voip apps? In general, 3rd party voip apps have never been handled/covered by any of our call identification/blocking APIs, and I don't think Live Caller ID is any different.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@Kevin Elliott Sorry I should have clarified that. No I don't mean a Voip call I mean a regular call.

For example, identifying information about the caller might be in the P-Asserted-Identitiy field, or an image might be specified in the Call-Info header (with purpose=icon).

So I was wondering, for example suppose a call arrived and P-Asserted-Identity was empty but Call-Info contained an icon, and LCID returned a name but no icon, then would the OS combine the icon from Call-Info with the name from LCID to display a name and an icon?

So I was wondering, for example suppose a call arrived and P-Asserted-Identity was empty but Call-Info contained an icon, and LCID returned a name but no icon, then would the OS combine the icon from Call-Info with the name from LCID to display a name and an icon?

No, we don't "mix" data like this. There's basically a "hierarchy" of data sources and we only present the data from that data source (whichever one "works"). For example, if there is a contact card for a specific number then that's what we're going to show to that user, regardless of what any other data source would have returned*.

*Primarily for performance reason, we basically stop "looking" at the first data source that matches, so we aren't going to look at other data.

We don't "overlap" data source because it creates the possibility of confusion and could potentially be exploited.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

"we don't "mix" data like this. There's basically a "hierarchy" of data sources and we only present the data from that data source (whichever one "works"). For example, if there is a contact card for a specific number then that's what we're going to show to that user, regardless of what any other data source would have returned*."

@Kevin Elliott

When there is an incomming call what is the hierarchy of data sources? I would guess from my observations its:

1. Contacts
2. Call Directory Extension
3. Live Caller ID
4. SIP header content

Would that be correct? There's additionally Voip Calls, but beyond that, are there other sources of data where call time information is extracted from to display on the call screen?

Thank you

When there is an incoming call, what is the hierarchy of data sources? I would guess from my observations it’s:

...

Would that be correct?

We've never formally documented the exact order and probably never will, as this is exactly the sort of implementation detail we tend to avoid trying to document in exact detail.

Having said that, yes, that looks right.

There are additionally VoIP Calls, but beyond that, are there other sources of data where call time information is extracted from to display on the call screen?

You didn't mention the ContactProvider extension. In terms of the hierarchy above, I suspect it's between #1 and #2, but I don't actually know off the top of my head.

A few general comments here:

• The system’s primary goal here is "do what seems sensible and manageable to the user", not necessarily "what's most correct". Case in point, the reason the contact's directory takes "precedence" over other data sources is that it's what the user directly controls and we're trying to avoid creating a situation where the user labeled a number "Mom" and the phone presented "Mrs. Elliott". The issue isn't that one is "right" and the other is "wrong", it's that "Mom" is the value they can directly modify.

• In a similar vein, I expect the ContactProvider extension to take precedence over other data sources because that data is directly visible in Contacts, even if it can't be edited.

• I believe we should now be "labeling" call identification data so that it's clear where less visible sources (like Live CallerID or CXCallDirectory) have provided data. If you find an exception to that, please file a bug.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware