Inquiry about the data format for Live Caller ID Lookup

Just to be more clear, in the addition of a user's name and icon, I want to add another field!

I am currently in the design-phase of an app that aims to present what the last call between the two parties was about, and that information can be gotten from an API that I will build according to Apple's principles that is comaptible with the Live Caller ID Lookup protocol. Therefore adding a field that will present a short summary of the last call will be very handy. Is that possible?

I wouldn't expect so, at least not in a way that would be useful. As described in "Understanding how Live Caller ID Lookup preserves privacy", Live Caller ID goes to considerable effort to ensure that your server cannot link specific users to specific queries. The system also limits the data you can return, but even if you could return "arbitrary" data, that data couldn't actually connect to any previous query.

Also, keep in mind that none of our call identification services actually receive "all" calls. For example, if a call is already the users contacts database, that data issued directly without ever querying other data sources.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for the reply! I don't think I was super clear. I actually do not want to link specific users to specific queries. I just want to send the contents of a field in my database to the user who is using the app. Imagine that I have a field in my database that contains the value: "testing Live Caller ID Lookup". I want this string to be showed to the user that is using the app, in addition to the user name and user icon. So that would mean that the screen that the user will be getting, will look like something like the picture below:

Is that possible?

Thanks for the reply! I don't think I was super clear. I actually do not want to link specific users to specific queries. I just want to send the contents of a field in my database to the user who is using the app. Imagine that I have a field in my database that contains the value: "testing Live Caller ID Lookup". I want this string to be showed to the user that is using the app, in addition to the user name and user icon. So that would mean that the screen that the user will be getting, will look like something like the picture below:

No, there isn't any way to extend the interface like that. The format documented in "Formatting data for blocking and identity information" and the CallIdentity struct only contains a name, icon image, and the cache management data.

One point to clarify here is that Live Caller ID Lookup is specifically designed around spam call blocking and is not the right tool for other use cases (like corporate phone directories). The Contact Provider Extension or Call Directory app extension are better options for phone directories or for fixed blocking lists.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I see! What about how much information that can be inserted into the name field? I guess there is a restriction on the amount of characters that can be put into the name field?

I see! What about how much information that can be inserted into the name field? I guess there is a restriction on the amount of characters that can be put into the name field?

I'm sure there is but I'm not sure what it is off the top of my head and the field limit itself isn't the main limit. The main limit here is the display limit of the screen itself, above which we'll reformat the string so that it fits within the limit.

Keep in mind that this means that the limit doesn't actually translate very well to a fixed character limit. Device width varies of course but so does the string width, based on character spacing, character set, font size, etc. All of that means that you'll really need to do you own testing and experimentation to figure out exactly what looks and feels right for you use case.

On the testing front, one suggestion I do have is that our CallKit sample "Making and receiving VoIP calls" (Speakerbox) is a handy tool for experimenting with how the incoming call UI will behave. It's basically a "fake call" app* implemented with CallKit, so you can use it to quickly test what a given string value will look like in the call UI without needing multiple devices or a even an active cellular plan.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for the reply Kevin! I completely understand then. I think either way, I can fit what I need to fit inside the name field. With that in mind, do you think that it is completely feasible that I build a very small app that will implement the Live Caller ID Lookup extension so that I identify caller if he/she is among my business' customers (given that their contact details are already in our internal database) given that I build up the server based on the requirements that you have indicated in the protocol (I mean the privacy-related requirements with the specific endpoints, data format etc.)?

By the way, I have looked into using a periodically updated offline database (via Call Directory app Extension) to do what I referred to above (and which was a common solution for lots of developers before Live Caller ID Lookup), but I actually need to have access to an online database since our database changes very very often, and therefore I want it to be always synced with the calling-identification service that I want to build.

What do you think about my reasoning? Should I kick-off this project with Live Caller ID Lookup, or do you think I should look at other options?

Thanks in advance!

By the way, I have looked into using a periodically updated offline database (via Call Directory app Extension) to do what I referred to above (and which was a common solution for lots of developers before Live Caller ID Lookup), but I actually need to have access to an online database since our database changes very very often, and therefore I want it to be always synced with the calling-identification service that I want to build.

What do you think about my reasoning? Should I kick-off this project with Live Caller ID Lookup, or do you think I should look at other options?

At a purely technical level, yes, it would theoretically work. In practice, I think it's a bad idea. In particular:

• I don't know if you'd be approved to use it at all, as this isn't really what Live Caller ID was designed to do.

• On this point, I don't think you'll actually see results that are THAT much better than the alternatives:

"I actually need to have access to an online database since our database changes very very often"

There's a lot of gray area in "very very often". If the database is changing VERY frequently (minutes/seconds), then caching inside Live Caller ID mean that you're going to get incorrect results. On the other hand, if changes are happening at a broader interval ("every few minutes"/"few times an hour"), then you could probably push those changes to contact provider frequently enough that it wouldn't be an issue. Either way, I think both cases are going to periodically "wrong" and the other directory APIs are FAR more straightforward to work with.

My advice would still be to use the other APIs I mentioned.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for the reply! I see what you mean, and I might instead go with the Call Directory Extension (briefly explained here: https://developer.apple.com/documentation/callkit/identifying-and-blocking-calls). As far as I understood, I think that you are referring to it as a much better solution to what I want to do, BOTH theoretically and practically. Am I right?

Regarding the database, if I can update the pre-loaded on-device database every an hour or so, then it's fine by me. In that case, I might start designing the app with the Call Directory Extension in mind. I want to hear your thoughts!

Ps. Call Directory Extension is not restricted to VoIP calls right? Because I want to get Caller ID when an ordinary call (via the default iOS' Phone app) is received.

Thanks for the reply! I see what you mean, and I might instead go with the Call Directory Extension (briefly explained here: https://developer.apple.com/documentation/callkit/identifying-and- blocking-calls). As far as I understood, I think that you are referring to it as a much better solution to what I want to do, BOTH theoretically and practically. Am I right?

Yes. My main concern for your use cases is that getting it to update "frequently" can be difficult, as you don't really have very good control over it's update process. From that perspective, Contact Provider Extension might be a better option, particularly since it allows you to provide full contact data, not just "a name".

Ps. Call Directory Extension is not restricted to VoIP calls right? Because I want to get Caller ID when an ordinary call (via the default iOS' Phone app) is received.

Correct and actually the reverse. Call Directory extension ONLY applies to standard call calls, it does NOT apply to voip calls. Keep in mind that voip calls are not required to include a phone number at all and most do not.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for the reply! I see, then if Contact Provider Extension will let me sync more frequently, then I will go with it.

Just before I start looking into building it, do you see any ways where the idea for my app might go wrong with this extension? As I said before, I want people from my business' contact list (that do exist in a database) to be identified if the incoming call's number exists in the database. This is the idea in its most simple form. I might need to ask more in-detail questions later but first I want to hear your thoughts.

Again, thanks in advance for your huge support!

Just a small update: During the weekend I read a bit on Contact Provider, and it seems like the database of contacts will be stored in the phone's contact list. Is that the case, or can I choose to not show them and instead just use the contact information (from the database) when a (identifiable) number is calling?

Just a small update: During the weekend I read a bit on Contact Provider, and it seems like the database of contacts will be stored in the phone's contact list.

It will be visible in contacts, however, it isn't actually stored in the same "common" data store. So, for example, deleting/disabling the Contact provider will remove all of the contacts it "owns".

Is that the case, or can I choose to not show them and instead just use the contact information (from the database) when a (identifiable) number is calling?

There's no way to do this currently, but it's a reasonable enhancement request.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Ok I see! This is not exactly what I want to do because the app will be used by several people and they are definitely not interested in having lots of unrelevant numbers in their local contact list. If that is the case, then Call Directory App Extension might be the way to go, but I wonder how frequent is it possible to to update the database (i.e., fetch new (or updated contacts) from online db). Like do you know if once per hour is possible? Or does the update occur based on the user's input, for example that the user presses a button in the app and a sync gets performed. Because if one of those ways work then that would be more than enough for my use-case.

Thanks in advance!

Ok I see! This is not exactly what I want to do because the app will be used by several people and they are definitely not interested in having lots of unrelevant numbers in their local contact list.

You may want to create a test app to see what this look before you discard this approach. I'm not sure what the UI looks like, but this feature was designed with the knowledge that these weren't "the users contacts" and that inserting them as simple peers was probably a mistake.

If that is the case, then Call Directory App Extension might be the way to go, but I wonder how frequent is it possible to to update the database (i.e., fetch new (or updated contacts) from online db). Like do you know if once per hour is possible?

We've never documented any formal numbers but the major issue with this API has always been that apps don't have direct control over it's reload process (they tell the system "reload", but that's all they can do). If the database is quite small then frequent triggers might be workable, but the process is a bit cumbersome.

The larger issue here is that I don't think any of the API options here are actually going to do EXACTLY what you want. You're going to need to pick the one that you feel best meets your requirements, then do you best to work around it's limitations.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware