Conditional vs Unconditional forwarding

[enlaichu]

Is there a need to be able to 1) query by and/or 2) receive a response detailing conditional and unconditional forwarding on the phone number?

To consider:
-Fraudsters can use both unconditional and conditional forwarding to fulfill their goals (i.e. conditional forwarding can be triggered by a second call calling the phone while a first call is ringing the phone)
-Legitimate services such as enhanced voicemail (e.g. Youmail) will mean conditional forwarding is set up on those numbers

[FabrizioMoggio]

I think that, unless we have a specific use case supporting this, I suggest to limit the information the API returns. Having conditional or unconditional setup is, at the end of the day, a personal information. Anyway I'm checking with TIM's Marketing department if they see a possible use case on this.

[enlaichu]

My question was more to ask if both conditional and unconditional forwarding would be considered for the response (or only unconditional forwarding).

There was discussion of whether voicemail forwarding would be considered and voicemail forwarding is conditional (not unconditional) forwarding.

[FabrizioMoggio]

you are totally correct, this discussion as also an impact on: #4

For that requirement (FWD to Voice Mail), the actual proposal is to "park" it. maybe it is better to concentrate on a simple use case at first.

I propose to consider any kind of forwarding for these release. I mean if any kind of FWD is configured, we report it (with no details).

[enlaichu]

Yes I agree. To clarify, any kind of user-configured forwarding (conditional and unconditional) should be reported as forwarding enabled.

Carrier-configured forwarding (e.g. default voicemail forwarding) should not be reported as forwarding enabled.

Correct? Otherwise, the forwarding status will always be "true" since (in the USA at least), default voicemail forwarding is always enabled.

[FabrizioMoggio]

@enlaichu I have checked with my marketing department and they think this can be a useful information to provide to the API Consumer. Actually the Unconditional case is a stronger indicator for a possible fraud than the conditional case.

And I agree with you, the Conditional could be active by default. Anyway, I suggest to report it anyway giving the information with a new output providing this level of information.

So I propose to the information about the Call FWD type (conditional/unconditional) as output.

#11 (comment)

[bigludo7]

For my perspective I'm not sure about the value to add this conditional/unconditional attribute in the response regarding the additional complexity to this API (to the consumer to understand the conditional but also to the API producer to get this info).

But perhaps I missed an UC where providing conditional information is a must.

[FabrizioMoggio]

Let's consider the use cases (#3)

For UseCase-1 (Bank Frauds) and For UseCase-2 (Telecommunication Frauds), Unconditional FWD can be seen as a fraud indicator, while Conditional FWD can be considered as normal. For these UCs the information about the type of FWD is required.

For UseCase-3 (Call FWD Verification), the "Voice Mail Service" could be interested to verify is Conditional or Unconditional is configured.

[bigludo7]

Thanks @enlaichu & @FabrizioMoggio
I understood the UC and browsing the internet I find here something very aligned with your view.
I've still one point... adding this information makes the API a bit more complex because if it's a conditional we need to explain which conditions right? If I follow you we have very distinct UC and so distinct consumer for conditional/unconditional?

In order to keep thing simple perhaps we can consider to have 2 resources in our API ? WDYT ?

[bigludo7]

Hello @FabrizioMoggio
Thanks.
Understood your 3 proposals and I've still preference for 2 because if I put myself as developer what I have to understand about 'conditional' call forwarding information.

I took again my previous example: As a bank, insurance, healthcare, etc... service I want to be sure that calling to this number I will not be "silently" redirected to another line but reach this number
This is for me the main UC where our API brings value (agreed?... and it could be for fraud prevention but also for any other purpose)

If the answer is conditional what our consumer do with this information ? can the call be trusted? how the consumer knows the conditions?

This is still the blocking point for me.

[bigludo7]

BTW @FabrizioMoggio I looked to our API proposal that triggered this work (here) ... we were very focused on fraud & straighforward: The Call Forwarding Signal API can be used by the bank to verify if a "call forwarding" option is active on the customer's phone, avoiding such a fraud.

[FabrizioMoggio]

@bigludo7 sure, that is the main Use Case for me too. Anyway, with Conditional FWD it can be "silently" redirected, just not always. Who decides if this is a potential fraud. It can depend by the different system from the Bank or by their policies.

Moreover, as a general API design guideline, I would prefer to be able to use the API also for other use cases if this does not request too much complexity. In this case I really don't the see the complexity in the API. For sure the Developer needs to be able to understand which scenario can be potentially dangerous and which one is not. Anyway the alternative is that it is us deciding which is the dangerous scenario (only Unconditional). Are we sure, about that? Maybe for UseCase-1. For UseCase-2 (Telecommunication Frauds) also Conditional FWD could be relevant. @chinaunicomyangfan what do you think.

About UseCase-1 (Bank Frauds). with Option 3: it is up to the Bank to decide which kind of Call FWD setting is safe. I assume that they will detect a potential fraud if the answer is Unconditional, while they can consider as "safe" the situation if the answer is Inactive or Conditional. Or maybe the would like to consider it safe only if it is Inactive. It is up to them.

I would suggest to leave the choice to the API Consumer on how to identify the Fraud. It is different if we decide to provide an API tailored to just one scenario: the potential fraud is only with Unconditional FWD. Is this our decision to make?

[chinaunicomyangfan]

@FabrizioMoggio For use case 2, the fraudster usually set unconditional call forwarding for the victim's phone. If the type of call forwarding (Inactive, Unconditional, Conditional) can be added to the output, it should help the police reduce the misjudgment rate，Inactive and Conditional can be considered secure.

[FabrizioMoggio]

@chinaunicomyangfan and @bigludo7 thank you both for this interesting discussion.

@bigludo7 in my understanding your goal is to provide to the API Consumer a simple information focusing on the Unconditional Call FWD. Anyway, we see a value on the added information on the Call FWD type. So I see a further option, similar to Option-2 for the Intent but also providing the Call fwd type as an output. So, who is interested in that detail can do some further reasoning:

Option 4: New Intent-1: "is the unconditional call fwd service active on a specific phone number? ". as for Option 2 but with a second optional output callFwdType: (Inactive, Unconditional, Conditional). So the outputs are:

• active: TRUE/FALSE
• callFwdType: [Inactive, Unconditional, Conditional]

Anyway, I still prefer Option 1 or 3 :-) they are more generic and open to new use cases.

[FabrizioMoggio]

@bigludo7 what do you think about the above Option-4?

I also tried to think about your proposal of having two Resources. This could lead to Option-5 :-).

Option-5:

• two Intents
• Intent-1: "is the unconditional call fwd service active on a specific phone number? "
• Intent-2: "is the call fwd service active on a specific phone number? "
• Resource-1: CreateUnconditionalCallForwardings
• Resource-2: CreateCallForwardings
• POST-1: unconditionl-call-forwardings: output -> active (Boolean)
• POST-2: call-forwardings: output -> active (Boolean), type (Inactive, Unconditional, Conditional)

Is this what you meant?

[bigludo7]

Hello @FabrizioMoggio
Thanks a lot for these proposals !!
I like a lot your proposal 4 :)

It offers flexibility if implem wants to manage only unconditional it works, it implem manages conditional/unconditional it works also.

We need to be very clear in the documentation about conditional meaning.

Let's see what other members prefer.

[FabrizioMoggio]

According to: https://wiki.camaraproject.org/display/CAM/2024-04-23+CFS+Minutes

Option 5 has global team preference (its granularity allows flexibility to market, to manage consent at each level and accommodate partial implementation)

[FabrizioMoggio]

Conlusion:

Option 5 will be implemented.

Two intents will be supported:

Intent 1: is the unconditional call fwd service active on a specific phone number?
Intent 2: provide me the status of the call FWD Service on a specific phone number

Identified Pros:

Pros: open to many scenarios
Pros: anti-Fraud oriented
Pros: more flexible for the Operator to implement and for Consent management