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

MEETING UPDATE:

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

241

Chunghwa Telecom

Communication Risk Check

The API template is available in PR#243

LAST UPDATES:

• Communication Risk Check 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

MEETING UPDATE:

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

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

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

Blocked as done together with first API definition yaml in one PR.

143

TIM

IoT Network Optimization

The API template is available in PR#144

INITIAL CONTEXT:

Focused on booking resources for a non-warranted connection for IoT, group of many devices at once, during a certain period. Not directly related to QoD or HighThroughput API.

LAST UPDATES:

Feb 13, 2025:@Kevin Smith posible overlap with Dedicated Network API (proposal), related to configure a network for a set of devices. To be reviewed.

Issue#14 raised to discuss about posible overlap

@fabrizio moggio : Proposal to include IoT API (separate repo) as part of the Dedicated Network “family” (share participants and meetings) to align use cases and definitions.

@Jan Friman : this API looks like a specialization of Dedicated network API

Proposal: To be proposed in the Dedicated network issue to validate Issue#14

TIM proposed an alternative approach to complement Dedicated Networks API, so that developer can manage energy modes, IoT slice selection os similar for a IOT device.

@Tanja de Groot @Thorsten Lohmar proposed those features to be generic, not dedicated to IoT use cases

Continue discussion with the new scope, including new API name.

Dedicated network group will still be used to include the previous scope (scheduling a network config for IoT)

New scope of API will be discussed separately.

AP: modify current API proposal (PR and name) with new use cases (TIM)

@fabrizio moggio will provide feedback of the status in the next backlog call

• naming will be adapted based on updated scope, API ready for TSC approval.