Intent-2: outputs proposal

[FabrizioMoggio]

#6 (comment)

Intent 2: provide me the status of the call FWD Service on a specific phone number

Output 1: [inactive, conditional, unconditional]

Status: under discussion

[StefanoFalsetto-CKHIOD]

I have two proposals, to take into account the possibility that conditional and unconditional call forwarding is active at the same time:

P1: Continue to use an array. The elements into the array are to be considered "active".
Example P1.1: The end customer set the call forwarding conditional
Output P1.1: [conditional]
Example P1.2: The end customer set the call forwarding for conditional and unconditional
Output P1.2: [conditional, unconditional]
Example P1.3: The end customer doesn't set any forwarding
Output P1.3: [inactive]

P2: Use an array of objects. This could be more easy to further improve, in case we will add in future the conditional call forwarding details
Example P2.1: The end customer set the call forwarding conditional
Output P2.1: [{conditional: true}]
Example P2.2: The end customer set the call forwarding for conditional and unconditional
Output P2.2: [{conditional: true}, {unconditional: true}]
Example P2.3: The end customer doesn't set any forwarding
Output P2.3: [{inactive: true}]

At the moment I have no preference between the two proposals.

Do someone have any clue?

[FabrizioMoggio]

Actually I see more future proof the first option. With that option we can provide back any kind of string we want:

• Inactive
• Conditional
• Unconditional

And we can expand it with:

• Conditional_Busy
• Conditional_Unreachable

If the output is an array of string we can mix those values as needed. And it is up to the Operator implementation to support a subset or them all.

Example P1.4: The end customer set the call forwarding for conditional on busy and unconditional.
Output P1.4.1 (For Operator supporting all the parameters): [Conditional_Busy, Unconditional]
Output P1.4.2 (For Operator not supporting all the parameters): [Conditional, Unconditional]

In the API Documentation we should explain that the Conditional types can be not supported by a specific implementation. Anyway let's stick to the point, the format (Boolean or String), while we can discuss about Conditional Options in a second moment. @StefanoFalsetto-CKHIOD did you had a different view on expandability? In term of "coding" is it better to manage Boolean than Strings maybe?

[StefanoFalsetto-CKHIOD]

Hi Fabrizio,
I agree with you, the first option is also future proof.

Regarding the value format, from the development point of view, I think there is no real difference between boolean and string, hence I think we can focus on offering the data in the most easy and profitable way.

So I vote for the first proposal: Inactive, Conditional, Unconditional, and maybe in future adding new values with prefixes.

Please note: As you said, here we are talking about the values returned by the call-forwardings endpoint. Regarding the unconditional-call-forwardings endpoint I think we can stick on boolean values.

[FabrizioMoggio]

supported with #36

[FabrizioMoggio]

I open again this discussion because of: #17 (comment)

It has been requested by @enlaichu to evaluate to add the following information to "/call-forwardings":

-conditional_busy
-conditional_unavailable
-conditional_no-reply

[FabrizioMoggio]

If we agree on the need of the above details for the Conditional Call FWD, we can add them in the CallForwardingSignal resource.

Currently that resource returns the information on the conditional call fwd as:

• 'inactive'
• 'unconditional'
• 'conditional'

We can modify it as:

enum

• 'inactive'
• 'unconditional'
• 'conditional_busy'
• 'conditional_unavailable'
• 'conditional_no-reply'

example:
- 'unconditional'
- 'conditional_unavailable'
- 'conditional_no-reply'

[FabrizioMoggio]

This must be closed to move to Alpha. This is required for the Meta release process.

#38

[FabrizioMoggio]

It was agreed to implement the proposed additional parameters.

https://wiki.camaraproject.org/display/CAM/2024-07-02+CFS+Minutes

[FabrizioMoggio]

Implemented in R1.3