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.

MEETING UPDATE:

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.

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

MEETING UPDATE:

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.

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

Telefonica

Line Eligibility for Carrier Billing API

The API template is available in PR#94

MEETING UPDATE:

Issue open in Carrier Billing API enhancement - Line Eligibility · Issue #190 · camaraproject/CarrierBillingCheckOut 

89

China Mobile

IP High-throughput Elastic Network 

The API template is available in PR#90

Approved for Sandbox repository

→ Follow-up on API onboarding tracker: [Onboarding Tracker] HighThroughputElasticNetworks · Issue #133 · camaraproject/APIBacklog

• Work to be done: (no new updates since last meeting)

Onboarding almost done, but scope description in README still not updated. No relevant activity in the repository since its creation.

126

China Mobile

Facial Recognition

The API template is available in PR#130

EasyCLA to be solved

METING UPDATE:

material presented by YinMing Fu.

@Eric Murray proposes in 126 to consider this API as part of already existing ModelAsA Service APi group (also from China Mobile)

YinMing Fu considers API separated as MaaS focused on LLM models

@Eric Murray raises issues on match with CAMARA authentication, privacy and identity existing mechanisms to be applied in this API

@Jorge Garcia Hospital raised question on the telco capabilities been leveraged

--> MNO face database is used

AP to China Mobile to clarify open points

To modify the template to ScopeEnhancement of MaaS.

@YinMing Fu updated  PR#130 and API will be treated in next TSC 19th dec. 15:00 UTC

METING UPDATE:

Approved, pending to decide whether it will be part of same repo or different from MaaS

→ Follow-up on API onboarding tracker: Pending.

50

Verizon

Device Management

The API template is available PR#30

The issue was not treated in this conference call

The issue is not eligible to be closed yet.

Action to contact Verizon to ensure participation in next backlog meeting

API proposal presented by @Mahesh Chapalamadugu , clarified this proposal is targeted for IoT device management to activate/deactivate/manage the connection of those devices.

ACTION:@Mahesh Chapalamadugu to upload current yaml for clarification in PR#30, and present again in next meeting.

@Mahesh Chapalamadugu AP to upload documentation

Slides presented by @Mahesh Chapalamadugu & @joshua

Slide will be uploaded and reviewed offline before approval

ACTION:

Review match with other Device management APIs (home devices or similar) and IoT/Device status (AP Backlog: contact Mahesh)

Also ensure this is a proper telco capacity to be consumed by developers, in comparison with Operate API (TM Forum) that are related to Aggregators.

METING UPDATE:

Potential of merging IoT SIM Status Mgmt API in, will be checked by @Mahesh Chapalamadugu until next meeting.

Confirmed in:

New API proposal- Device management · Issue #50 · camaraproject/APIBacklog

APIs proposals PR to be updated before 17th EoB, and will be brought to TSC approval on 20th.

→ Follow-up on API onboarding tracker: [Onboarding Tracker] IoT Device Management · Issue #180 · camaraproject/APIBacklog