Issue #

223

Telecom Argentina

Sponsored Data

The API template is available in PR#224

LAST UPDATES:

• The Sponsored Data API allows third parties to sponsor mobile data usage for end users in a destination-agnostic way. It enables the initiation, monitoring, and termination of sponsored data sessions via secure operator interfaces.

• Supporting document - Proposal API #229. Includes initial draft of supporting document discussed in issue #223. This commit does not intend to close the issue — just to provide context for further discussion.

Jun 12, 2025, Jun 26, 2025,Jul 10, 2025: not treated

Jul 24, 2025: To be considered in next session with easyCLA resolved.

Aug 14, 2025:

@Eric Murray

• Proposes decoupling session creation from campaigns to support non-campaign use cases (e.g., a parent buying a limited data bundle for a child). Campaigns may use sessions, but session objects shouldn’t embed campaign identifiers.

• Raises an open question on end-user notifications for sponsored/limited data (e.g., 100 MB cap):

  • How is the customer informed when the allowance is consumed?

  • Should the API/network operator trigger the notification, or is it the sponsor’s responsibility?

@Julian Filippini
My understanding is that the sponsor is responsible for notifying the end customer. When the sponsor requests the activation of a session, they provide a callback URL to receive session status updates. When the session ends, the sponsor receives the termination event via that callback and should then notify the customer (e.g., in-app message, SMS, or email). In this model, the API/network operator only delivers events to the callback and does not contact end users directly.

AP: Close the PR#229 and upload the yaml file and the supporting presentation to the current PR#224.

MEETING UPDATE:

Aug 28, 2025: Merge the current PR and sent to the next TSC meeting.

#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

MEETING UPDATE:

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

241

Chunghwa Telecom

Fraud Hotzone Alert (previously called Communication Risk Check)

The API template is available in PR#243

LAST UPDATES:

• Fraud Hotzone Alert API empowers anti-fraud systems to analyze phone call and SMS activities associated with a phone number during a specified period, offering a comprehensive view of communication behavior.

Jul 10, 2025:

@Eric Murray: This proposal is too broad and intrusive for a CAMARA API. Like Scam Signal — which isn’t a CAMARA API due to its sensitivity — this involves exposing too much personal data. It’s unlikely that users would consent, even for fraud prevention. A better approach would be to compute a risk score from background data, without exposing the details. Otherwise, the API risks being unusable.

• @jasonchan: We consulted the relevant departments at Chunghwa Telecom, and according to user policy and regulations, mobile network contracts include a clause informing users that their data may be accessed for purposes like fraud prevention. So, this privacy concern might be addressed through proper consent management.

@rebecca from MTN: Rebecca from MTN raised a key question: Will this API require user consent? She asked whether sharing such detailed data is allowed without explicit consent, or if consent must be obtained.

• @jasonchan: Currently, no separate consent is involved, as the mobile contract already includes a clause stating that user data may be accessed — effectively serving as implicit consent.

@Tanja de Groot: A suggestion was made to follow a “Know Your Customer” model, where instead of exposing all user data, the API would return a simplified risk score (e.g., high, medium, low, or a percentage). This avoids requiring the application to handle, process, and store sensitive data, and lets the API handle the calculations internally.

@Appelboom, Huub: Even if the API returns only a risk score, processing traffic data for this purpose in Europe still requires explicit user consent under most legislation. The legal issue is fundamental and has also affected similar APIs like Scam Signal. Outside Europe, rules may differ.

Additionally, banks typically prefer raw data to run their own risk models, as fraud patterns evolve rapidly. This makes it difficult to lock the logic on the API side — overly prescriptive APIs may quickly become ineffective.

• @guang-han ma: In Taiwan, user consent is already obtained through standard agreements when they subscribe to services. So, in this use case, the required consent is already in place, and the concern about user permission is addressed by existing practices.

AP1 → Upload the proposal presentation to the API template PR.

AP2 → Answer all these questions for the next meeting

Jul 24, 2025:

Updated presentation: documentation/SupportingDocuments/Fraud Hotzone Alert.pptx

Proposal to change name to Fraud Hotzone Alert, more related to the use case covered.

API proposal modified, in terms of parameters:

• input: phoneNumber, lookBackDays, thresholdRatio, method, FraudHotZone, checkType, checkTarget

• output: anomalyDetected, anomalyDate

Privacy and overlapping with other APIs is addressed in the shared slides, offline validation is required for:

• Ensuring that @Eric Murray comments are addressed

• Ensuring that Scam Signal and Customer Insight groups are ok with the scope of this API. Target group should as well be found

• Review API naming as requested by @Tanja de Groot

Outstanding conversations from the overlap:

• Scam Signal: There could be some functional overlap, as both aim to detect potential fraud scenarios, but their scope and response models are fundamentally different. Scam Signal focuses solely on checking if the potential victim’s phone number is currently in an active call, leaving fraud suspicion assessment to the API consumer. Fraud Hotzone Reports, instead, analyses recent call/SMS history and directly returns a fraud likelihood assessment from the operator. Are separate APIs, but we could still consider them part of the same Working Group, even if one repo is public and the other private. The main complexity would be meeting management, so for now Fraud Hotzone Reports could start independently since Scam Signal meetings are private.

• Customer Insights: No functional or scope overlap. Customer Insights delivers a TrustScore and does not identify fraud victims, while Fraud Hotzone Reports serves a completely different purpose with a different data model and fraud detection approach.

Aug 14, 2025: AP: sent to TSC as a part of the same group of Scam Signal, even if the repository is public and the other one is private, and manage the meeting independently, as Scam Signal meetings are private.

MEETING UPDATE:

The main issue is that the API involves highly sensitive data and, as raised by Herbert (DT), it falls into the same category as Scam Signal, meaning it cannot be hosted in CAMARA’s public repository. The suggested approach is to handle it under a confidential GSMA framework or develop it market-specific for Chunghwa. For this reason, the topic has been removed from the TSC agenda until governance is clarified.

Aug 28, 2025:

AP1: Contact GSMA (e.g., @MarkCornall) to explore private hosting under a confidential framework.
AP2: Validate internally at Chunghwa whether you are comfortable proceeding under GSMA’s confidential model and confirm alignment with local regulatory requirements.

63

MTN

IMEI Fraud

The API template is available PR#64

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

MEETING UPDATE:

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.

AP2: Make a presentation for the next backlog meeting.

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

Issue #

18

Totogi

New Proposal: Receive SMS

The API template is available in PR#75

• 20240327-02 was completed. Herbert responded but not the subgroup owners, no activity seems to had happened for a month: Issue #9 · camaraproject/ShortMessageService

Seems to fit in the SMS as a new scope enhancement 

The issue is not eligible to be closed yet.

ACTION: Ricardo to formally proceed with the scope enhancement os the SMS group.

MEETING UPDATE:

• Reminder sent

→ Follow-up on API onboarding tracker: Pending.

20

Deutsche Telekom

Best Interconnection

The API template is available in PR#88

Input from OGW Drop 3

Seek for support

ACTION: See if there is any overlap within EdgeCloud

ACTION: Nick (centillion) to review with Noel (DT) about the match of use cases and consider support.

DECISION API to be de-prioritised following de-prioritisation by OGW, but to remain in backlog. Issue to remain open.

MEETING UPDATE: Not treated

→ Follow-up on API onboarding tracker: Pending.

91

Telefonica

Fixed Lines in Location

The API template is available in PR#92

METING UPDATE:

Issue open in location API enhancement - Support of landlines · Issue #271 · camaraproject/DeviceLocation

93