API Proposal - OGW Call Forwarding signal

[FabrizioMoggio]

Part of OGW Drop 3.

The Application Function (AF) of the Service calls the Call Forwarding Signal API (provided by the OP) to determine if a specific MSISDN has an active call forwarding setup

Related to: #359

[jordonezlucena]

@FabrizioMoggio: some early comments:

• Avoid using GSMA OPG specific terminology, e.g. "OP". Use other well-know terms such as (mobile) network operator, communication service provider, etc.
• Clarify and elaborate the concept of 'call forwarding' concept. It is used through the API description, but no clear hint what it represents.
• Technical viability is empty -- it cannot be. This field shall identify which are the technical enablers (at network, IT, OSS side) on the SBI for this API to be defined on the NBI.
• Hint on Privacy issues is somewhat missed.
• This seem to be another API belonging to the fraud category. Differences with another similar/related APIs (CAMARA APIs related to fraud) should be better highlighted.

[FabrizioMoggio]

@jordonezlucena I have addressed you first three comments (by the way, thank you).

About Privacy: it is important and for sure relevant for this API, but it is not a characteristic of the API itself and it needs a discussion in the group to understand how privacy must be addressed so I think, for this stage, that the Privacy issue must be postponed

About Fraud Category, this API is indeed part of that Category but I don't see any other API overlapping. IMEI Fraud is maybe the most similar one but it is related to the Device, the Call FWD Signal is instead related to the Phone Number

[bigludo7]

Hi @FabrizioMoggio
One comment regarding the UC journey. We have one different:

• Fraudsters will call customer and pretend to be a customer service representative from mobile network operator
• They'll tell the customer that her/his account has been hacked or there is some issue with his/her SIM card.
• They'll then tell customer that they have a quick fix for this and ask customer to dial a number from his/her phone, starting with (for exemple here in France if I do **61*06123456789*11# all my calls are redirect to 06123456789)

What the fraudsters are actually doing is trick individuals into unknowingly enabling call forwarding on their phones.

It absolutely change nothing about the API interface requested .... but the way to trigger the call forwarding is completely different (in your scenario it's coming from the CRM application whilst in my scenario it comes directly from the network).

Do you think both scenario could be considered in your proposal?

[FabrizioMoggio]

@bigludo7 your scenario is totally correct and, in my understanding, it is covered by our proposal. Your use case helps to identify a way for the fraudster to trick the customer into activating a call FWD. As you said the API is not effected because this "trick" happens upfront. Independently by how or way the Call FWD is activated, the API invocation alerts on that configuration.
About your comment about the API being called by an external API (e.g. CRM) or by the Network, I'm not sure to get your point :-). We just proposed a UC with an external Application involved as a possible example, but any authorized API Consumer obviously is in scope.

[jordonezlucena]

@FabrizioMoggio: a couple of comments on the (latest version of the) application template:

• "Validated with operators" row is duplicated
• "List of supporter companies" row is not part of the template, so it should be removed. If a company wants to become a supporter, then this company shall submit a PR against the API backlog table, adding their name as supporting company (5th column).

[jordonezlucena]

/LGTM

[jordonezlucena]

It was decided in the 25th Jan call (minutes here) to bring this API proposal for approval to next TSC meeting, so the PR can be merged.