Support of Multi-SIM lines in QoD APIs

[jlurien]

Problem description As introduced in https://github.com/camaraproject/Commonalities/issues/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.

[hdamker]

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]

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.