Proposal to add error response for not supported method for phone number

[mhfoo]

Problem description
CAMARA APIs may not support all phone numbers for specific functions in any point in time

Possible evolution
Add a 501 status response with the following message "Service not supported for this phone number"

NotSupported:
   description: Not Supported
   content:
    application/json:
     schema:
      $ref: "#/components/schemas/ErrorInfo"
     example:
      status: 501
      code: NOT_SUPPORTED
      message: Service not supported for this phone number

Alternative solution
N.A

Additional context

• CAMARA APIs may support mobile lines first and then landlines later, vice versa.
• A MNO may support the CAMARA API method, but the MVNO (of the same MNO) does not support it.

[rartych]

Similar issue, but not the same is discussed here: #127 .
Is this case covered there?

[mhfoo]

Similar issue, but not the same is discussed here: #127 . Is this case covered there?

@rartych
The scenarios in this issue are not covered in #127.

[mhfoo]

@rartych
Added PR #145 for this proposal

[sachinvodafone]

Camara guidelines use the regular expression ^+?[0-9]{5,15}$ to validate phone numbers across all APIs. This validation simply checks for a valid phone number format and doesn't distinguish between mobile and landline numbers.The Camara guidelines don't mandate providers to implement mobile/landline differentiation on the server side. . In this scenario, if no resources are associated with the validated phone number, the API server should respond with a 204 (No Content) status code.This code indicates successful processing but no data to return, rather than a 501 (Not Implemented) code, which suggests the service is unavailable.

[mhfoo]

@sachinvodafone:
Please see below.

Camara guidelines use the regular expression ^+?[0-9]{5,15}$ to validate phone numbers across all APIs. This validation simply checks for a valid phone number format and doesn't distinguish between mobile and landline numbers.The Camara guidelines don't mandate providers to implement mobile/landline differentiation on the server side. .

Operators are not required to implement both mobile lines and landlines of the same CAMARA API. Agree that the phone number format does not state whether it is a mobile land or landline (only peer operators of the home operator may know the type of phone number, based on prefix or number range)
If this phone number belongs to an MVNO, the operator may not act on behalf of this MVNO (subject to commercial decisions).
This error code is to handle such scenarios.

In this scenario, if no resources are associated with the validated phone number, the API server should respond with a 204 (No Content) status code.This code indicates successful processing but no data to return, rather than a 501 (Not Implemented) code, which suggests the service is unavailable.

In your example above, the phone number is valid and the route to the home operator can be found. The home operator may or may not implement this API function. Example: in the first phase, only mobile lines for call forwarding, and landlines will be a later phase.

501 (Not Supported), with the error message: "Service not supported for this phone number" means the client did not request with any invalid inputs. It is a server-side error, and this API response will not be charged. There is nothing the client can do, to obtain a correct response for this phone number.

204 (No Content), means a successful API call and this API response will be charged to the API consumer, since it is in the 2XX range.

501 (Not Implemented) does not mean unavailable. 503 (Service Unavailable) means unavailable and the client may try at a later time.

[PedroDiez]

This issue has not the same scope as per Issue#127, but a scenario that should be aligned with decision taken as per Issue#127 - Scenario 5.

So far, a specific "code" is agreed, so as analogous one would be needed for this case, and "status" points to be agreed as 422.

Some comments indicated in PR based on this comment

[mhfoo]

@PedroDiez Commented in the PR #145. Please have a look.