/
2025-11-13 API backlog minutes

2025-11-13 API backlog minutes

 

Attendees

Organization

Name

Orange

 

Charter Communications

CableLabs

 

Telefonica

@Alberto Ramos Monaga

Vodafone

@Kevin Smith @Eric Murray @lauren kaye

Ericsson

@Jan Friman @Kamran Keykhosravi

AT&T

 

T-Mobile US

 

KDDI

 

Slagen

 

Nokia

 

China Telecom

 

ZTE

 

KPN

 

GSMA

 

Centilion

 

Deutsche Telekom

 

MTN

 

China Mobile

 

Verizon

PlektonLabs

 

TIM

 

NTT

 

China Unicom

 

Infosys Ltd

@Ravi Shekhar

Spectrum

 

Chunghwa Telecom

 

Telecom Argentina

 

Huawei

 

xFlow Research

@ALI IQBAL

Agenda Proposal

  • Antitrust Policy

  • Approval of minutes of last conf. call

  • Recent Updates & Recap

  • Discussion

    • New APIs Proposals:  

      • #250 (In Home Device Management API), #256 (Voice One Time Password Call), #267 (Radio signal attenuation API)

    • Scope Enhancement:

      • N/A

    • Out of Agenda: N/A

  • Closing Issues

    • #141 (Energy Footprint Notification), , #126 (Facial Recognition), #18 (Receive SMS), #89 (IP High-throughput Elastic Network), #41 (Telco Scoring), #83 #85 #86 #87 (Model as a Service), #20 (Best Interconnection), #68 (Consent URL), #91 (Fixed lines in Device Location APIs), #93 (Line Eligibility for Carrier Billing API), #50 (Device Management) #95 (IoT SIM Status Mgmt API), #96 (IoT SIM Fraud Prevention API), #109 (Support application resource requirements in application profiles), #163 (Dynamic Predictive Connectivity Data), #143 (IoT Network Optimization), #127 (Network Health Assessment), #128 (Network Traffic Analysis), #136 (eSIM Remote Management), #157 (Voice Notification), #160 (Voice Verification Code), #223 (Sponsored Data), #241 (Fraud Hotzone Alert), #262 (Provider Implementation - Energy Footprint Notification), #261 (Scope enhancement: Proposal to Expand DCB Applicability Beyond Mobile Subscribers to Home Accounts), #63 (IMEI Fraud - reactivate from frozen status)

  • Frozen API

    • #35 (5G New Calling), #17 (Consent and Measurement), #23 (Carrier Wholesale Pricing), #24 (Steering of Roaming Information), #115 (SIM Historical Information), #121 (User Account Spend Count), #122 (Number Of Cards Under User's ID), #167 (IdentityAndConsentManagement)

  • Review of Action Points

  • Decision Points

  • AoB

  • Q&A

Approval of minutes of last conf. call

  • Minutes of last API backlog WG call available here

    • DECISION: OK

Antitrust Policy

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

 

 

New Procedures in API Backlog WG meetings

A number of improvements are under discussion with leadership team of OGW project (Henry), CAMARA Project (Markus), Product Definition WS (Helene) and TSC (Herbert). As of today, the WG adopted agreements are three:

  1. To close the agenda SEVEN DAYS BEFORE the conf. call.

    • In case a WG participant wants to include a point in the agenda (e.g., present a new API proposal), this participant shall ensure the corresponding issue is opened in Github by then.

    • Exceptional situations will be treated separately.

  2. New schedule of conf. calls **The meetings are to be held by Linux Foundation (Links available at GitHub and Confluence Backlog front pages)

    • 2nd Thursday of the month (9-10:30 UTC)

    • 4th Thursday of the month (15-16:30 UTC)

  3.  Send agenda to TSC mail list, to encourage more TSC member companies to join the call and provide comments when they identify APIs which are of interest for them. 

  4. New API proposals are included in backlog table when template PR is created, linking to the pending PR

  5. PR will be merged as soon as ready for TSC, and should be merged before TSC review

  6. API enhancements requires existing group’s validation. TSC is informed accordingly to validate

  7. Link and status in backlog table will be updated accordingly

  8. Issue to track API onboarding will be opened once new API is confirmed in TSC.

  9. New proposal Lifecycle for frozen APIs.

Recent Updates & Recap

Last TSC meeting 2025-11-06:

No new APIs were submitted to the TSC for approval, but there were interesting topics for CAMARA participants:

TSC Election

  • Nomination phase started (announced on TSC list); electorate: 62 Maintainers per Charter.

  • Maintainers list visible to CAMARA GitHub org members (list here).

Spring ’26 / Fall ’26 Timelines - #204

  • Approved: timelines for Spring26 and Fall26 including the guidance for APIs regarding participation within the Spring26 meta-release (as presented within last TSC and available on the preliminary wiki pages)

  • For Spring ’26: scope freeze Dec 15 (M1); teams must open a Release Management issue to join

Unified Clean-up Process - #199

  • In final review next Thursday after addressing comments.

  • Please review proposed candidates in the issue comments.

Meta-Release Naming - #200: Shortlist of name pairs from the issue discussion:

  • Spark YY / Anchor YY — start vs consolidation metaphor.

  • Foundation YY / Consolidation YY — descriptive, “build then steady” cycle.

  • Seed YY / Harvest YY — natural‐cycle metaphor: seed planted, then harvest reaped.

  • YYYYH1 / YYYYH2 — purely chronological halves, minimal metaphor, maximal clarity.

    • Vote: TSC + Outreach, Condorcet IRV; LF to run a one-week ballot.

Other topics

CAMARA APIs - Functional Differences (Use-Case & Data Semantics Edition): A white paper has been produced for publication on the CAMARA website to explain in detail what problem each API solves, what data it delivers, how to interpret it, and how to combine them in risk and error-prevention policies (Audience: Non-telco experts) APIs covered: SIM Swap · Device Swap · Tenure · Number Recycling - (link)

Provider Implementation - Energy Footprint Notification #262 - Provider implementation repository created (link)

Provider Implementation - IoT Network Optimization #278 - asking for a Provider Implementation repository.

Schedule additional API Backlog Working Group meetings #274 - @Shilpa Padgaonkar A new recurring meeting series was proposed to improve participation from colleagues based in U.S. time zones.

  • Proposed slot: 1st & 3rd Wednesdays, 15:00 PST (23:00 UTC / 00:00 CET next day).

  • Objective: increase inclusion of U.S.-based contributors while keeping current EU/Global cadence.

  • Pros identified:

    • Better accessibility for participants located in North America (especially West Coast).

    • Potential to expand contribution diversity and regional engagement.

  • Cons / Risks discussed:

    • Additional meetings could fragment participation and duplicate discussions across sessions.

    • Increased coordination and reporting effort (e.g. overlapping agendas, uneven attendance).

    • The proposed time falls during night hours for most European members (00:00 CET), reducing global inclusiveness.

  • Decision: Participants are concerned about proliferating meeting (adding more than the current ones), as this would fragment discussions and make coordination of backlog decisions and TSC more difficult. As a mitigation the group and participants is open to shifting the existing 2º meeting backlog slot to a later time (around 17:-18:00 UTC), which remains acceptable for European delegates while enables participation from North American colleagues.

Evolution of Consent Info API to support Controlled Delegation #276 - The proposed evolution of the Consent Info API introduces an optional Controlled Delegation model, allowing trusted developers to capture consent directly within their own applications using operator-provided texts and parameters, while the operator remains fully responsible for consent registration, storage, audit, transparency, and opt-out. This enhancement aims to reduce UX friction, enable in-app and backend consent capture, and expand coverage to (re)consent campaigns, all while maintaining backwards compatibility with existing AuthCode and CIBA flows. Review by the groups involved.

Discussion

Current Issues 

Issue #

Company

Summary

Status Update

#250

Infosys

In Home Device Management API

The API template is not yet.

LAST UPDATES:

The API enables full management of devices connected to a home network, providing connection details and control functions for both customer and operator devices.

  • @Eric Murray - What use cases could this API support that TR-369 cannot? And if TR-369 has gaps, why is it preferable to create a new API in CAMARA instead of evolving TR-369 within the Broadband Forum?

    • @ravim95-eng: The BBF TR-369 standard focuses on low-level broadband network operations intended for service providers. In contrast, CAMARA offers a higher-level abstraction through simplified APIs, making them accessible to non-telecom consumers without requiring knowledge of underlying protocols like TR-369, TR-069, or TR-181. The proposed CAMARA Device API is designed to be standards-agnostic and easily consumable across domains.

  • @Alberto Ramos Monaga: Bit concerned about a possible overlap with the already approved Home Devices QoD API, since both build on the same household device inventory.

    • @ravim95-eng: I see the proposed InHomeDeviceAPI to be foundational/pre-requisite API for usecases like Home Devices QOD API rather than functional overlap

Aug 28, 2025: The presentation will be on the next Backlog meeting with all needed supporting documentation and the API proposal.

AP: The presentation will be on the next Backlog meeting with all needed supporting documentation and the API proposal.

Sep 11, 2025: AP: The presentation will be on the next Backlog meeting with all needed supporting documentation and the update API proposal.

Key Architects are out of office; hence team would be presenting ‘AP 20250828-01’ on the next call of 25th September.

Sep 25, 2025: The presentation has been carried out during the meeting. Discussion:

  • @Mahesh Chapalamadugu (verizon):

    • Noted that the IoT Device Management repo is still very early, with the goal of basic lifecycle management, later extending to diagnostics.

    • Raised the possibility of overlap/synergy between IoT Device Management and the new In-home Device API.

    • Emphasized CAMARA’s principle of keeping APIs small, intent-based and simple, rather than large YAMLs covering multiple functions.

    • Asked whether In-home Device API is really distinct or if it should be consolidated with IoT device management.

  • @Ravi:

    • Explained that In-home Device API is intended to manage household connected devices (desktops, laptops, mobiles) behind a modem, exposing standard APIs for ISPs and third-party apps (voice assistants, apps, etc.).

    • Suggested that IoT and connected devices should be unified under one specification rather than kept separate.

    • Argued that at an abstraction level the data attributes for IoT and connected devices are nearly identical, so one generalized API could cover both.

    • Clarified that the proposal is not about putting everything in one YAML but keeping separate operations with a shared model for all devices.

    • Conceded that while the current focus is “in-home”, the model could extend beyond (e.g., connected cars).

AP1: Create a PR with the API proposal following the template.

  • Join to the call of IoT Device Management to clarify scope and positioning (if the API remain separate, clearly document the distinct use cases, if not proposed a unified device object model that works across IoT, home, and possible other domains like automotive).

  • New API proposal- Device management · Issue #50 · camaraproject/APIBacklog - This is the issue in API backlog for device management. You will also find a pdf file which has high level scope defined in the same issue.

    • @Ravi Shekhar attended IoT device management backlog meeting earlier to understand the scope of it and overlap with proposal here. Based on those discussions, #50 is about IoT devices management and the one proposed here is related to devices connected to modem, so the scope are different. I am refining the usecase for this proposal & mostly have it for upcoming call.

AP2: Upload the presentation to the supporting document within the current PR.

Oct 9, 2025, Oct 23, 2025: Not treated

MEETING UPDATE:

Nov 13, 2025: Create the PR with the related presentation. The last point of IoT Device management has been solved (see previous minutes).

63

Before: MTN and now: xFlow Research Inc

IMEI Fraud

The API template is available

IMEI Fraud Check API proposal by ALIIQBAL786 · Pull Request #254 · camaraproject/APIBacklog

INITIAL CONTEXT:

This API was presented already and included in an existing group but no work was done so discontinued. Now Rebecca is presenting the proposal seeking for support

DeviceCheck GSMA proposal overlaps this

IMEI Fraud will offer more information to developers than GSMA Device Check service.

MTN and other supporters should meet with GSMA to discuss if proceeding with this API within CAMARA still makes sense.

Request for meeting already sent by GSMA to MTN

Outcome of meeting awaited before deciding if this API proposal should proceed in CAMARA

  • Pending to be confirmed by MTN, AP to be raised.

@Eric Murray : (IMEI status) service related, but GSMA is ok for this proposal.

ACTION: Pending from MTN for moving on with this API. Maybe to be included in the Device Identifier family.

 @reg no further information from MTN, consider to de-prioritize, pending to further update

Any other operator open to take the lead of this API is welcomed

LAST UPDATES: No response since September 6, 2024.

Feb 27, 2025, Mar 13, 2025, Mar 27, 2025,Apr 10, 2025, Apr 24, 2025, May 8, 2025,May 22, 2025, Jun 12, 2025, Jun 26, 2025: Not treated

Request to reactivate the IMEI fraud verification API (Thursday, August 21, 2025) from Ali Iqbal xFlow Research Inc.

If the original proposal owner (@krishvenkatachalam / @wwAMRA) is not available to continue leading, xFlow Research Inc. is willing to step in and take on the role of Proposal Owner to help drive this work forward in collaboration with interested contributors.

Aug 28, 2025:
AP1: Reuse the existing PR and update the current API proposal and add the supporting document with the new context (IMEI Fraud Check API proposal by ALIIQBAL786 · Pull Request #254 · camaraproject/APIBacklog )

AP2: Make a presentation for the next backlog meeting.

AP3: Do a research for possible overlap with Device Identifier API

Sep 11, 2025: Not treated

Sep 25, 2025:
AP1: Upload the documentation to the PR as a supporting document - OK

AP2: (review this old comment from when the owner was MTN) → Have this conclusion for the next meeting and IoT SIM fraud prevention. Check the material shared by @Eric Murray regarding DeviceCheck, and validate the inclusion of the API in the Device Identifier group:

  • IMEI Fraud will offer more information than GSMA Device Check service. MTN and other supporters should meet with GSMA to discuss if proceeding with this API within CAMARA still makes sense. Request for meeting already sent by GSMA.

  • Action to remain open until after meeting with GSMA is held

Oct 10, 2025: AP2 update → contact to GSMA on reactivating this and be part of Device Identifier sub project (send e-mail)

Oct 23, 2025: Find the previous email and re-send again (done). We’re waiting response from GSMA.

MEETING UPDATE:

Nov 13, 2025: Minutes from meeting with GSMA: Ali (Xflowresearch), Rebecca (MTN), Mark (GSMA), Jason (GSMA) and Hugo  (GSMA)

Conclusion: All parties see value in pursuing IMEI Fraud API within the Device Identified group

Meeting notes

  • Alignment on IMEI Fraud Detection API: Ali from Xflow Research, Rebecca from MTN, Hugo from GSMA, Jason, Mark, and Reg discussed the IMEI Fraud Detection API, clarifying its purpose, input parameters, status definitions, and the need for alignment between CAMARA, MTN, and GSMA to ensure the API meets operator and stakeholder requirements.

  • Clarification of Related Fraud Detection APIs: Rebecca clarified the distinction between the IMEI Fraud Detection API under discussion and MTN's broader Mobile Fraud Detection API, which includes SIM swap, device swap, and device distance features, ensuring all participants understood the scope of the current meeting.

Next Steps

  • Sub Project Meeting Arrangement: Arrange the next sub project meeting with Jason, Hugo, and Rebecca to discuss further alignment and feedback on the IMEI fraud detection API. (Ali)

  • Feedback to CAMARA: Report back to Camara on the outcome of this meeting, confirming that GSMA and MTN support continuing the IMEI fraud detection API within the device identifier sub project. (Reginald)

AP: Review PR from Backlog WG and sent to TSC.

Add this API to the Device Identifier meeting as a topic and then we can start to review the PR - @ALI IQBAL

#259

Heksagon

Voice One Time Password Call

The API template is available at #256

INITIAL CONTEXT:

The “Voice One Time Password Call” API is used to send short-lived one time passwords (OTP) to a phone number via voice call and validate it afterwards, in order to provide a proof of possession of the phone number.

AP1: Update the PR by creating a new entry under documentation/API-proposals instead of modifying documentation/API-proposal-template.md.

AP2: Create an issue with the API proposal label and link it to this PR.

AP3: Resolve the easyCLA error by clicking the provided link and signing the authorization

Sep 25, 2025: Not treated

Relation with Voice Verification Code (#233) - Herbert suggest if we can merge this with this issue.

Oct 10, 2025, Oct 23, 2025: Not treated

MEETING UPDATE:

: Not treated