When a subscriber receives a bank callback from an unfamiliar number, they have to decide whether to answer. As the operator, you control what happens before that phone rings: which caller identity is accepted and how the call should proceed.
Verified Caller ID brings SSI and EUDI wallet integration into your IMS and SIP service logic. A verifier checks the caller's credential before call control applies your service policy. Branded calling presents the business identity on supported terminating networks and handsets.
The service you offer connects three decisions: what your network accepts, which business the caller represents and what the subscriber sees before answering.
You decide which identities your voice service accepts and what happens when a check fails. Verification runs at the SIP application layer, where your call policy controls admission, timeouts and fallback.
The operator defines how the verification result affects the call.
Your enterprise customers need to reach people who may not recognise their calling number. Link the representative's credential to a call from a work phone or CRM, so your service can carry the permitted business identity.
Business identity is connected to the representative placing the call.
The caller presents a wallet credential as part of placing the call. Your service can then provide the permitted identity information during ringing, where the receiving network and dialer support it.
Identity information can reach the recipient before answer.
Caller verification starts with a trusted credential. Choosing SSI or EUDI defines the wallet, credential and issuer requirements for your service.
Self-sovereign identity (SSI) uses decentralized identifiers (DIDs) and verifiable wallet credentials. Your verifier validates presentations and issuer trust during call setup.
A DID alone does not prove a caller's authority to represent a business.
European Digital Identity (EUDI) wallets let callers share identity attributes with their approval. The verifier checks the presentation and issuer trust.
Your call control uses the result to decide how the call proceeds.
The caller has started a call, but wallet consent and verification still need to complete. Call control keeps the recipient's leg pending during that window, so the permitted identity information can travel with the initial call request.
The wallet sends its presentation to the verifier over HTTPS while SIP maintains the voice session. Once the result returns, call control applies your policy and decides how the call proceeds. For verified delivery, the recipient is alerted after the check and policy decision.
OpenID4VP presentation
Credential Verification + call policy
Deployment options
A subscriber dials, or a representative starts a call from the CRM. Call control links the request to the caller, destination and registered device, then asks for a wallet presentation.
Result: The credential request belongs to this call.
The caller approves the wallet request. The wallet sends its presentation to the verifier over HTTPS, where the credential and issuer are checked against the policy agreed for the service.
Result: The verifier returns the permitted identity claims.
The result reaches call control before the recipient is alerted. Your policy determines verified delivery, rejection, or an explicitly unverified fallback when verification fails, is cancelled or takes too long.
Result: Each outcome has a defined call treatment.
For a verified call, the initial request carries the permitted identity information. The terminating network and recipient's dialer determine which details appear while the phone rings.
Result: Supported identity information can appear before answer.
Once your service has verified the caller, that identity still needs to reach the subscriber. Branded calling gives your enterprise customers a recognisable presence: their business name, logo and call reason put the incoming call in context. The credential provides the identity claims behind that presentation; the receiving network and handset determine which fields can be shown.
Incoming call
OVOO sp. z o.o.
✓ Verified caller
Scheduled consultation
Incoming demo call from OVOO
Drag to rotate. Tap the phone's screen controls to answer, decline or end the demo call. Arrow keys rotate. Enter or Space answers, ends the call or starts it again. Escape declines or ends the call. R resets the view.
Using Hammer handsets, we tested the call flow from credential verification to call delivery.
It checks the identity claims the caller presents from their wallet and connects them to the call being placed. Before the recipient is alerted, a verifier checks the presentation against the agreed issuer trust and credential policy. Those claims can identify an individual subscriber or establish a business representative's role, depending on the deployment.
Branded calling helps the recipient recognise the business through a name, logo or call reason. Verified Caller ID also checks the caller's wallet credential before ringing. Branded calling is the presentation part of that service, with the fields shown depending on the receiving network and handset.
One of our implemented scenarios does not require STIR/SHAKEN. The verifier checks the caller's wallet credential and returns the result to call control. Where both mechanisms are used, STIR/SHAKEN authenticates asserted telephone identity through service-provider signatures.
They follow the same call-verification sequence, but the wallet and trust requirements differ. The SSI path uses decentralized identifiers and verifiable credentials within an agreed trust model. An EUDI integration follows the selected wallet, credential formats and relying-party requirements. Using OpenID4VP alone does not establish EUDI certification.
The wallet step belongs to the caller, who uses a wallet and a compatible custom dialer. The recipient receives an ordinary voice call. What appears on their screen depends on the terminating network, handset and dialer's support for rich caller information.
No. Name, logo and call-reason display must be checked separately for each handset and network route.
Yes. A representative starts a click-to-call request in the CRM, which passes it to the Call Register Service. Third-party call control establishes and parks the caller's leg while the wallet check completes. It then initiates the recipient's leg with the identity information permitted by the verification result and call policy.
A SIP application server acting as a back-to-back user agent coordinates the wallet presentation and verification result. A Media Resource Function can play an announcement to the caller during this window. The server applies the operator's call policy before alerting the recipient.
OVOO has tested call flows over VoLTE and VoWiFi using Hammer handsets in its own IMS lab.
You agree a verification window and the call treatment for each outcome before deployment. A failed, cancelled or timed-out check can lead to rejection or an ordinary unverified call under an explicit fallback policy. A failed check must never be presented to the recipient as a verified identity.
Bring a subscriber or enterprise call flow from your network, the wallet you want to support and your target handsets. Together we define the identity claims, operator policy and integration points, then test call treatment and identity delivery before planning rollout.
