/
2025-10-16 Number Insights

2025-10-16 Number Insights

Community Attendees:

@Ludovic Robert @Alberto Ramos Monaga @Fernando Prado Cabrillo @Toshi Wakayama @Surajj Jaggernath Nandula Karunasingha

Community Attendees:

 

LF Staff:

 

Agenda

The project's Antitrust Policy is linked from the LF and project websites. The policy is important when multiple companies, including potential industry competitors, are participating in meetings. Please review it, and if you have any questions, please contact your company’s legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.

 

  • Gouvernance update

  • OTP

  • SIM Swap

  • Device Swap

  • Number Verification

Minutes

Gouvernance update

Proposal to Adopt a Dual-Phase Meta-Release Cadence for CAMARA APIs (Proposal to Adopt a Dual-Phase Meta-Release Cadence for CAMARA APIs · Issue #194 · camaraproject/Governance)

The current biannual meta-release cadence (Spring and Fall) treats all API versions equally, regardless of maturity level. This structure creates friction for early-stage APIs and operational fatigue for stable APIs, which require repeated validation and integration across release cycles.

Introduce a dual-phase cadence that distinguishes explicitly between:

  • Sandbox Phase (0.x versions): APIs can be released iteratively year-round for early testing and validation, independently of meta-releases.

  • Stable Phase (1.x+ versions): APIs are aligned with official meta-releases (Spring or Fall), with a preference for stable releases in Fall.

 Stabilization criteria, versioning rules (mandatory/optional/breaking), and patching procedures would be formalized per lifecycle phase. Commonalities and ICM would follow a structured Spring release to prepare for Fall API publication.

Already approved by the TSC

Detailed planning is available here: v2 Updated meta-release plan - CAMARA Project - CAMARA Project

 

OTP Validation

 

SIM Swap

 

Device swap

  • New issues:

    • https://github.com/camaraproject/DeviceSwap/issues/73 : At present, there are no test cases covering the scenario where a phone number is active and connected to the network but has not experienced any Device Swap within the monitored period (maxAge).

      • Yaml documentation update for the POST retrieve-date to add “In case the phone number has never been installed in a device, or no data is available in the operators records (e.g. database error), API will return a 422 error.“

      • Test case need to be completed when no swap in the monitor period occurred.

      • @Fernando Prado Cabrillo will make the PR

    • https://github.com/camaraproject/DeviceSwap/issues/72 : The oas schema for the Generic400 error for retrieveDeviceSwapDate operation doesn't follow the commonalities artifact.

      • @Fernando Prado Cabrillo will make the PR.

  • Backlog:

 

Number Verification

API clarification

  • We discussed last meeting about the requirements for clarification between few APIs: Device Swap, SIM Swap, Number Recycling, Tenure

    • White paper in preparation with Telefonica & Orange

    • Will be shared in each API repo in an issue for comments

    • @Toshi Wakayama mentioned that in the KYC discussion a point was raised to add Subscription Status in this document.