Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of Multi-SIM lines in DeviceStatus APIs #212

Open
jlurien opened this issue Sep 27, 2024 · 1 comment
Open

Support of Multi-SIM lines in DeviceStatus APIs #212

jlurien opened this issue Sep 27, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@jlurien
Copy link

jlurien commented Sep 27, 2024

Problem description
As introduced in camaraproject/Commonalities#302, for Multi-SIM services. providing a phoneNumber as input does not identify a single device uniquely.

Current DeviceStatus specs do not consider or give guidelines about how to behave in scenarios when the input is only a phoneNumber of a Multi-SIM service and specific device (SIM) cannot be inferred from the access token or other device identifier.

Possible evolution
Discuss the problem and alternatives. There may be impact in other tracks, such as IC&M. We may need also to discuss implications in the short term when dealing with this situation in current versions.

In the case of DeviceStatus each API has each own considerations, as each SIM may have a different status:

  • For device-roaming-status, a user may have left one device linked to the multiSIM phone number at home while is travelling abroad with another one. Should API return roaming=True in that case? A corner case would be that several devices were roaming in different countries, and in that case a single countryCode/countryName couldn't be returned.
  • For device-reachability-status, several SIMs may have different reachabilityStatus. Should API return a consolidated response taking into account if any of the SIMs is connected?
  • For the subscription APIs, should an event be triggered if any of the SIMs changes its status? Should each device be identified uniquely in the event?

Alternative solution

  • Relying on 3-legged tokens as much as possible would minimize the problem, but currently we cannot assure that they always identify a single device instead of a phone number.
  • Finally we can handle the situation with errors, such as 422 UNIDENTIFIABLE_DEVICE, or another dedicated code, informing clients to provide an alternative identifier that can identify the specific device. But this should be limited to corner situations as it is not dev friendly and in most cases developers do not know if a phone number belongs to a multi-SIM service.

(this discussion is similar to the one being held in camaraproject/DeviceLocation#257)

@jlurien jlurien added the enhancement New feature or request label Sep 27, 2024
@eric-murray
Copy link
Collaborator

@jlurien

Discussing this internally for device-reachability-status, the conclusion was:

  • if the MSISDN is the primary MSISDN, then it is the reachability status of the multi-SIM group that is required (so if any device is reachable, the assumption is that the customer themselves is reachable)
  • if the MSISDN is a secondary MSISDN (i.e. the MSISDN of one of the secondary devices), then it is the reachability status of that device that is of interest

We can implement this using the existing specification based on the Device object, but using different logic dependent on whether the phoneNumber is a primary or secondary MSISDN.

This only works because our multi-SIM implementation uses primary and secondary MSISDNs, but any specification that allows these requirements to be met is fine.

The one "gap" is that our implementation cannot query the reachability status of the primary device (the smartphone) alone, because for that device, the secondary MSISDN is the primary MSISDN. That's not particularly important for us, but could be supported by introducing a multi-SIM "flag" to indicate whether the response should be for an individual device or multi-SIM group.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants