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 QoD APIs #362

Open
jlurien opened this issue Sep 20, 2024 · 3 comments
Open

Support of Multi-SIM lines in QoD APIs #362

jlurien opened this issue Sep 20, 2024 · 3 comments
Labels
enhancement New feature or request Fall24 Relevant for maintenance of Fall24 release Spring25 Issue in scope of Spring25 meta-release cycle

Comments

@jlurien
Copy link
Collaborator

jlurien commented Sep 20, 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 QoD 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.

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.
  • We may also try to define some specific behaviour for this service, such as applying the service to a default SIM id providers have this concept (but this may not be a universal solution).
  • 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.
@jlurien jlurien added the enhancement New feature or request label Sep 20, 2024
@hdamker hdamker added the Fall24 Relevant for maintenance of Fall24 release label Sep 20, 2024
@hdamker
Copy link
Collaborator

hdamker commented Sep 20, 2024

Notes as of QoD Call Sept 20th:

  • Target: define a common behaviour across operators (which all operators can implement)
  • Secondary MSISDNs: not known to users/developers, can't be used in public
  • Just using the "main" device not sufficient (way to notify the application about the chosen device/SIM missing)
  • Enabling all devices with same MSISDN? 
    • Maybe an option, but only in combination with a selected application (IP) flow
  • Request to those who have implemented to share their current solution
    • Target: Derive some guideline/documentation update for the current version
  • Documentation of expected behaviour also relevant for a Fall24 patch release

@eric-murray
Copy link
Collaborator

In Vodafone, each SIM still has a unique MSISDN. For multi-SIM scenarios, one of the group (usually the smartphone) is denoted "primary", but each SIM keeps its own "secondary" MSISDN. Generally, this secondary MSISDN is the identifier used by our network elements.

So, de facto, we are treating the phoneNumber in a CAMARA API call as the secondary MSISDN.

And because the primary device has the same primary and secondary MSISDN, this generally does not matter. The issue, of course, is how does the API consumer learn the secondary MSISDN of one the secondary device if that is the device they want to identify. Maybe CAMARA needs a separate API that returns all secondary MSISDNs associated with a primary MSISDN, along with some "friendly" name.

Specifically for QoD, I think there is scope to identify the secondary device if the flow that ends up in a request for enhanced QoS originates on the secondary device itself. For example:

  • the application server could use the authorisation code flow to get the secondary device to identify itself, with the identity being associated with the (3-legged) token; or
  • the application server could capture the IP address / port of the device and either:
    • request a 3-legged access token using the CIBA flow, with IP / port being used in the login_hint; or
    • request a 2-legged access token and then fill in the device IP / port in the service API call

But if the API consumer does not know the secondary MSISDN of the secondary device and wants to enable enhanced QoS for that device without it initiating that request, then I agree they will currently be unable to do that.

@hdamker
Copy link
Collaborator

hdamker commented Oct 7, 2024

From discussion within the QoD Call on Oct 4th:

  • the unambiguous identification in case of multi-SIM is network operator specific, as there are different ways of implementation of multi-SIM (multiple SIMs associated with one MSISDN)
  • if the data provided is sufficient to identify a single device (for examples see above Support of Multi-SIM lines in QoD APIs #362 (comment)) there is no problem.
  • if the network operator can't identify a multi-SIM unambiguous an error code and message must be returned (proposal in call: 422). The message should NOT reveal the fact that the MSISDN is associated with a multi-SIM.

There are currently no ideas for a long-term solution - the issue should be presented to OGW OPAG (Operator Platform API Group).

Short-term (for the planned patch release 0.11.x) a clarification along the lines above to be added to documentation (and test cases?).

@hdamker hdamker added the Spring25 Issue in scope of Spring25 meta-release cycle label Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Fall24 Relevant for maintenance of Fall24 release Spring25 Issue in scope of Spring25 meta-release cycle
Projects
None yet
Development

No branches or pull requests

3 participants