UseCase-3: Call FWD Verification

[FabrizioMoggio]

Use Case description here: #3 (comment)

[FabrizioMoggio]

@enlaichu is it fine with you the name for the Use Case: "Call FWD Verification"?

In my understanding, the scenario is not about frauds. It is about an External System that manages "voice mails kind of numbers". The call forwarding service is legitimate. The External System, with the API, can detect if the Call FWD System is correctly activated on a specific phone number.

In this case a possible new Intent could be:

"is this destination phone number configured in the Call FWD Service?"

The goal of this new intent is to let the External System to verify if the Call FWD activation was successful on the correct destination phone number.

If we consider this new intent, it is important to define policies and consent management to allow the request only to authorized API consumers.

[FabrizioMoggio]

Comment from @bigludo7 : (it was originally commented in #3. I would like to delete that comment to keep that Discussion clean.)

Hello @enlaichu
The UC is fair but for me the consumer of this information for this UC (does the forward to voice mail works?) is not a external developer (working for a bank app for example) but internal network provider developer (as network provider I want to programatically detect if the forwarding rule has been applied correctly)

Adding this UC will add an additional layer of complexity (is it conditional/unconditional ? if conditional what is the conditions?) that is not necessary for the "consumer" identified in the UC 1&2.
So for me, I prefer to consider this UC as a specific network provider one and not a generic one for external developer.

[FabrizioMoggio]

With v0.1.7, adopting Option 5, this use case is supported, isn't it?

@enlaichu what do you think?

[FabrizioMoggio]

can we declare this UC supported or is there something missing like having more details on Conditional?

[enlaichu]

Hi @FabrizioMoggio could I trouble you to the link to v0.1.7 Option 5 please?

Internal consumers (network provider) should already have access to this information.

How do we enable this UC to also be made available to an external application developers?

Leaving the list here for reference:

1]unconditional

2]conditional
-conditional_busy
-conditional_unavailable
-conditional_no-reply

[enlaichu]

To add some color to the issue that we'd like to solve:

1] app operation requires user to set up all three conditional forwarding settings to the service's phone number (e.g. the enhanced voicemail server). This is currently performed by giving the user forwarding codes to call from their phone
e.g.
all conditional forward
004<service's number>#

individual conditional forward:
61<service's number>#
62<service's number>#
67<service's number>#

2] Sometimes, the forwarding rules are not set as expected

• when users tap the number (carrier network issue that requires user to reset the network by turning airplane mode ON and then OFF, or by restarting phone)
• user error for not tapping all the codes

3] we try to verify that the forwarding was performed correctly by calling the number programmatically and receiving the call on the forwarded number. However, this only tests one of the three conditional forwarding codes. It is difficult to verify that all three codes were correctly set.

If one or more of the conditional forwarding codes were not set up and the service doesn't work occasionally, user has to request support and we need to ask the user to manually retrieve the forwarding number using the status codes and tell us the results:
*#0 04#
*#61#
*#62$
*#67#

Users and customer support find this tedious and subject to human error.

Being able to somehow verify that the conditional forwarding was set to the correct destination number for the service would be helpful.

Ideas for how to accommodate this use case would be appreciated! Thanks.

[FabrizioMoggio]

Some comments and considerations:

• we can consider the current version that is now Rel 0.1.8. The one currently available in the main repository: https://github.com/camaraproject/CallForwardingSignal/blob/main/code/API_definitions/Call_Forwarding_Signal.yaml
• I don't see any problem adding more details (busy, unavailable, no-reply) in "/call-forwardings" we can discuss about this topic here: Intent-2: outputs proposal #31
• about checking if the correct destination number is set, I don't have a solution right now, considering we have decided not to provide it back: Destination Phone Number as Output #15.

[FabrizioMoggio]

Additional parameters added in the YAML (#48) according to: #31 (comment)

Now Use case 3 is supported: as stated here: #3 (comment)

I will introduce UseCase-3 in the YAML documentation.

@enlaichu it would be great to have a user story to link in the YAML (I will start linking just the use case description). please use this as a template: https://github.com/camaraproject/CallForwardingSignal/blob/main/documentation/API_documentation/CFS_UserStory_UseCase-1.md

[FabrizioMoggio]

Supported by R1.3