Guide for Verifiers
Verifiers in GSMA's Open Verifiable Calling project are typically transit operators, gateway operators, or terminating service providers (though they could be auditors or national regulators, too). They are responsible for inspecting SIP INVITEs and deciding whether a call deserves to be routed (with verifiable branding) or declined. For calls that connect, verifiers also provide the verified, branded caller attributes that ultimately appear on the handset.
A verifier fits into the overall SIP call flow exactly as STIR imagines (see steps 6 and 7):
What is different in our project is that the passport contains richer, more robust, and more permanent evidence than with other STIR passport types — proof of the legal identity of the caller, right to use TN, brand attributes, delegation to the originating service provider, relationship to call center, settlement, AI involvement, and so forth. See The Evidence Advantage. The verifier is able to achieve higher levels of assurance about more facts, and to justify their decisions to auditors anywhere in the world, now and at any future time, without central governance.
Approaches to verification
There are 3 ways you can implement verifier behavior in this project:
with SIP redirects (just requires simple SBC config)
by calling RESTful APIs (requires a small amount of coding to integrate)
by implementing verification from scratch (doable with a significant investment)
In the first two approaches, verifiers call services that do the heavy lifting. In the Open Verifiable Calling project, these services are provided to experimenters by Provenant. In the final approach, verifiers collect and analyze the open VVP data themselves, and thus have full flexibility.
Easiest way to verify: use SIP redirect server
In this approach, the verifier's SBC receives an incoming SIP INVITE, and passes it to a SIP redirect server at sip-verify.voice.sandbox.provenant.net. This server analyzes the INVITE and returns a SIP response code that tells the SBC whether to continue routing or decline the call. If the decision is to continue routing, the response also adds verified brand information such as a logo to the call's Call-Info header so it can be displayed on the handset.
Prerequisites
Requesting verification
Your SBC should forward to the verification endpoint every SIP INVITE that is using the VVP mechanism. This means every INVITE that has an Identity header ending in ;type=vvp. No special headers or parameters are required — just the INVITE as it was received from an upstream node in the route, and as it would be forwarded to any other SIP redirect endpoint.
Sample TCP SIP verification request
What your SBC sends to this endpoint might look like this:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.122.197:5060;branch=z9hG4bK2712455
From: +XXXXXXXXXXX <sip:[email protected]:5060>;tag=12345
To: +YYYYYYYYYYY <sip:[email protected]:5060>
Call-ID: 3da62474-f40c-4cb1-b6d9-2ad09e8fde8d
CSeq: 1 INVITE
Contact: sip:[email protected]:5060
Identity: eyJhbGciOiJFZERTQSIsInR5cCI6InBhc3Nwb3J0IiwicHB0IjoidnZwIiwia2lkIjoiaHR0cDovL3dpdG5lc3MxLmRldi5wcm92ZW5hbnQubmV0OjU2MzEvb29iaS9FSVo1MGdaLXJIanNtdHljQWQ4VGtpRnJfU01RSmd0X1ZkN2xxb0s0UUZnNi93aXRuZXNzIn0.eyJvcmlnIjp7InRuIjpbIjQ0MjA3OTQ2MDgyMyJdfSwiZGVzdCI6eyJ0biI6WyIxMjEyMzMzMTIzNCJdfSwiaWF0IjoxNzU3NjA1NDI4LCJjYXJkIjpudWxsLCJjYWxsX3JlYXNvbiI6bnVsbCwiZ29hbCI6bnVsbCwiZXZkIjoiaHR0cHM6Ly9vcmlnaW4uZGV2LnByb3ZlbmFudC5uZXQvdjEvYWdlbnQvcHVibGljL0VHVGxRd1pUZTktLUlRQjhtamJzT0QyVjJ5b3ZON09KcWI1VEJZOTV3SWY1L2Rvc3NpZXIuY2VzciIsIm9yaWdJZCI6IiIsImV4cCI6MTc1NzYwNTcyOCwicmVxdWVzdF9pZCI6IiJ9.ZorPngtPKtA8T0NeIrHROq987hVvRR4sZhaIt-bMuJdk5cKvb-Kx57MiwXYX5qpEscUdlW8X7WyrJOJvWYjcDg;ppt=vvp
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 0Sample TCP SIP verification response
The SIP redirect server at sip-verify.voice.sandbox.provenant.net communicates errors exactly as the SIP spec expects — with 4xx and 5xx response codes. But in the normal case, verification results fall into one of 5 outcomes and are signalled with 3xx and 6xx status codes. A typical response might look like this:
SIP/2.0 306 branded 0x02388000
CSeq: 1 INVITE
Call-ID: ca4b5a6b-4efb-412b-a8ff-9e8c64d967c6
From: "+XXXXXXXXXXX" <sip:[email protected]:5060>;tag=12345
To: "+YYYYYYYYYYY" <sip:[email protected]:5060>
Via: SIP/2.0/TCP 192.168.122.197:5060;branch=z9hG4bK9566937;received= 192.168.3.41;rport=52557
Request_id: 49066ecb-84e0-4723-8186-de9223431d1c
Contact: <sip:[email protected]:5060>
Identity: eyJhbGciOiJFZERTQSIsInR5cCI6InBhc3Nwb3J0IiwicHB0IjoidnZwIiwia2lkIjoiaHR0cDovL3dpdG5lc3MxLmRldi5wcm92ZW5hbnQubmV0OjU2MzEvb29iaS9FSVo1MGdaLXJIanNtdHljQWQ4VGtpRnJfU01RSmd0X1ZkN2xxb0s0UUZnNi93aXRuZXNzIn0.eyJvcmlnIjp7InRuIjpbIjQ0MjA3OTQ2MDgyMyJdfSwiZGVzdCI6eyJ0biI6WyIxMjEyMzMzMTIzNCJdfSwiaWF0IjoxNzU3NjA1NDI4LCJjYXJkIjpudWxsLCJjYWxsX3JlYXNvbiI6bnVsbCwiZ29hbCI6bnVsbCwiZXZkIjoiaHR0cHM6Ly9vcmlnaW4uZGV2LnByb3ZlbmFudC5uZXQvdjEvYWdlbnQvcHVibGljL0VHVGxRd1pUZTktLUlRQjhtamJzT0QyVjJ5b3ZON09KcWI1VEJZOTV3SWY1L2Rvc3NpZXIuY2VzciIsIm9yaWdJZCI6IiIsImV4cCI6MTc1NzYwNTcyOCwicmVxdWVzdF9pZCI6IiJ9.ZorPngtPKtA8T0NeIrHROq987hVvRR4sZhaIt-bMuJdk5cKvb-Kx57MiwXYX5qpEscUdlW8X7WyrJOJvWYjcDg;ppt=vvp
Call-Info: <http://cdn.callverify.com/media/293487dklw47.png> ;purpose=icon, <https://docs.callverify.com/codes?c=0x02388000> ;purpose=reason
Content-Length: 0The Identity and Call-Info headers in the response may be passed to downstream parties that are willing to trust the verifier; these function as a receipt that can be presented to an auditor. The hex code at the end of the response's initial status line (0x023888000), and that is repeated inside Call-Info in the URL with purpose=reason, is called a reason code. It gives details about how the verification service evaluated evidence, and can be converted to a human-friendly explanation for troubleshooting purposes using the URL.
More control, slightly more effort: use RESTful web service
In this approach, your SBC calls an HTTPS verification endpoint instead of a SIP redirect server. The benefit is that you can get richer data and can perform arbitrary customizations in your routing logic. The tradeoff is that you have to call an HTTPS API from SIP infrastructure. Performance at scale is optimized and can approach that of raw SIP, but to use the API, you must satisfy the API's cybersecurity requirements. Instead of using an API key or an OAuth token, you must sign your HTTP requests according to rules of RFC 9421. This RFC is elegant and very secure, but it is also relatively new, so the technique may be unfamiliar. (Implementation is not difficult — 20 to 40 lines of code in most common programming languages. Provenant has reference implementations that it can share upon request.) Perhaps more important, this also requires your infrastructure to create, register, and manage the lifecycle of an Ed25519 keypair, and it requires your code to depend on a cryptographic library like libsodium.
Sample POST
A request to the web verification endpoint, https://voice.sandbox.provenant.net/v1/verifier/voice/verify, is a POST. It must define the Content-Digest, Signature, and Signature-Input headers, and its body must be JSON that includes the orig and dest TNs, the Identity header received from upstream, and a request_id for tracing. A sample request might look like this:
POST /v1/verifier/voice/verify HTTP/1.1
Accept: application/json
origin-date: 2025-09-11T14:39:10.315887244-04:00
content-digest: sha-256=:VB7N894Lwiz1hh7BUk6fKaXGBDn2C1j4cUluErclL5w:
signature: indexed="?0";provenant-au="0BAlLeQYQ-GPXnu81eJdc1zG52aDQoZQ5UvGrvoElcPfT5MjGA3eG-qa0IQ7MZO5qqn9EPTtLOW8QdoyUa0bh28O"
signature-input: provenant-au=("@method" "@path" "origin-date" "content-digest");"created"="1757615950316";"keyid"="BCR0ytXKwOzeRwoLUkgHx3pKwmDQfCYJXXfArjL-UCik";"alg"="ed25519";
Content-Type: application/json
Content-Length: 747
Host: verify.web.callverify.com
Connection: Keep-Alive
Accept-Encoding: gzip
"{"orig":"+442079460823","dest":"+12123331234","identity":"eyJhbGciOiJFZERTQSIsInR5cCI6InBhc3Nwb3J0IiwicHB0IjoidnZwIiwia2lkIjoiaHR0cDovL3dpdG5lc3MxLmRldi5wcm92ZW5hbnQubmV0OjU2MzEvb29iaS9FSVo1MGdaLXJIanNtdHljQWQ4VGtpRnJfU01RSmd0X1ZkN2xxb0s0UUZnNi93aXRuZXNzIn0.eyJvcmlnIjp7InRuIjpbIjQ0MjA3OTQ2MDgyMyJdfSwiZGVzdCI6eyJ0biI6WyIxMjEyMzMzMTIzNCJdfSwiaWF0IjoxNzU3NjE1OTIzLCJjYXJkIjpudWxsLCJjYWxsX3JlYXNvbiI6bnVsbCwiZ29hbCI6bnVsbCwiZXZkIjoiaHR0cHM6Ly9vcmlnaW4uZGV2LnByb3ZlbmFudC5uZXQvdjEvYWdlbnQvcHVibGljL0VHVGxRd1pUZTktLUlRQjhtamJzT0QyVjJ5b3ZON09KcWI1VEJZOTV3SWY1L2Rvc3NpZXIuY2VzciIsIm9yaWdJZCI6IiIsImV4cCI6MTc1NzYxNjIyMywicmVxdWVzdF9pZCI6IiJ9.2bRFuprx0dmRxauiK4t7YmSIh2jMG0jQMzrf1sc-2AI6iwOvRGh4fARk3Ubrh2hOpNi_5SRhk3E2x2L5JX6bAg;ppt=vvp","request_id":""}"If you'd like the OpenAPI (Swagger) definitions for this API, use ssh-keygen to create an Ed25519 keypair. Then contact Provenant with your public key and the IP address you'll be calling from. Your key will be registered and you'll receive docs to explore further.
Maximum control, significant investment: implement from scratch
The VVP specification and the related KERI, ACDC, CESR, and Dossier specifications that it depends on are all open, published to the world by standards organizations. In addition, there are reference implementations of major components of a VVP stack under permissive open source licenses on github. The communities behind these resources conduct meetings that are open to the public, and may be able to offer simple orientation to what they've published. Participants in the Open Verifiable Calling project would likely be welcomed as peers with enthusiasm.
However, these resources represent many person-years of investment in a specialized problem domain. Therefore, those pursuing this approach should expect a significant learning curve. After they've mastered the basics, there is still work to be done, gluing the components together, adapting them to the special needs of VVP use cases, testing them rigorously, and deploying for high availability, scale, cybersecurity, and similar goals.
Last updated