Seems like a little bit of NumberVerification 👀

{
  "code": "NUMBER_VERIFICATION.INVALID_TOKEN_CONTEXT",
  "message": "Phone number cannot be deducted from access token context"
}

Thanks for the comment. This is aligned with the other Device Status API endpoints. If there is a change needed, I can apply here as well.

Hi @gmuratk,
which "other" DeviceStatus APIs are you referencing?
I do not see any mention of verifying a number within the access token in those APIs.

The only instance I found related to this is in the NumberVerification API.

As we are not currently expecting to extract and verify phone numbers from the access token for the DeviceStatus API, do you think we can proceed with a general 403 response in such cases?

Wdyt?

Hi @maxl2287,
PR152, has the 2 files for separating the endpoints, and I used them as the basis for this yaml. Error message you pointed out exist in those files as well. https://github.com/camaraproject/DeviceStatus/pull/152/files

4G you have not used here inside your enum:

  enum:
        - 2G
        - 3G
        - 4GLTE
        - 5GNSA
        - 5GSA
        - NON3GPP4G
        - NON3GPP5G
        - NOT-CONNECTED

Maybe you wanted to use 4GLTE ?

We are hearing of one use case more regularly "Companies want to check if a number is a VoIP number vs a nonVoIP number" , any chance we could get that as one of the options here?

Change this to NOT_CONNECTED

Remove the trailing spaces in line 177

I disagree with using NOT_CONNECTED. It should be UNKOWN (or NOT_KNOWN, or similar).

There are two reasons for this:

• There are various reasons why the API provider might not know the network type, and not being connected to the network at all is just one of them. Rather than have separate codes for all these reasons, and the API provider trying to work out what the reason is, better just to say "I don't know".
• The purpose of the API is to return the network type. Saying the device is not connected is providing information over and above this and, indeed, is information that is anyway provided by a different API (device-reachability-status). We should avoid having two APIs that do the same thing in different ways.

If there is an insistence that this API also returns information as to whether or not the device is connected to the network, then it should be an extension of device-reachability-status and not a new API.

There are two issues with separate NON3GPP4G and NON3GPP5G option as part of a single enum:

• A device might be connected both to the mobile network and to WiFi for WiFi calling at the same time. Or it could be connected for WiFi calling and not connected to the mobile network. But we can only return one value.
• For WiFi calling, I anyway don't see the value in distinguishing being connected to a 4G or 5G "network" (really, it is the core we are referring to here). Just knowing the device is additionally connected via WiFi should be sufficient.

I'd suggest to have a separate but optional WiFiConnected or WiFiCalling response field, which could be true, false or just not present if the API provider doesn't know or doesn't want to provide that information.

I appreciate that "WiFi" may one day become an outdated term, and other "non 3GPP" bearers may be possible, but the term is commonly understood (unlike "non 3GPP", which is a good example of the type of "telco-specific" language we are trying to avoid).

It will be hard enough trying to work out what radio technology the device is using, without having to also work out which core it is connected to. I would suggest a single 5G option. What is the use case where the core technology is important?

Suggestion above is to add non-terrestrial network (satellite) access, because it will incur increased propagation delay and reduced throughput vs. terrestrial 4G/5G

Suggestion above is to add non-terrestrial network (satellite) access

The problem with adding this option is that almost certainly nobody will support it. Why not? Because the device will almost certainly be roaming on such networks. And I don't see any API provider implementing a solution to determine what access technology a roaming device is using.

Non-terrestrial networks would be better detected using the roaming API, as they should be using a non-geographic PLMN.

Because the device will almost certainly be roaming on such networks

Ah, no, this is rather intended for the case where satellite is filling coverage gaps to regular UEs - in which case the PLMN ID is the same as the terrestrial network (so not roaming).

The same can apply to NB-IOT (i.e. terrestrial | LEO | GEO).

It may be cleaner to restrict the enum to the radio access type but include an additional field to indicate non-terrestrial access (default: false).

... where satellite is filling coverage gaps to regular UEs

But you are still referring to a "direct to mobile" service using a 3GPP standard (4G or 5G)? Who is proposing to offer such a service using their normal terrestrial PLMN ID?

Who is proposing to offer such a service using their normal terrestrial PLMN ID?

Too early to say, but with reports of dozens of markets considering satellite-coverage deployment, then it makes sense to me to cover the valid 'same PLMN ID' option in the API (either as an enum value or with the optional modifier I mention above).