From 271eddf34d3012ab4b3c2d288399d23fda2cf6aa Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Tue, 26 Nov 2024 10:50:43 +0000 Subject: [PATCH 01/15] Update quality-on-demand.yaml --- code/API_definitions/quality-on-demand.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/code/API_definitions/quality-on-demand.yaml b/code/API_definitions/quality-on-demand.yaml index f02a13db0..f94154aea 100644 --- a/code/API_definitions/quality-on-demand.yaml +++ b/code/API_definitions/quality-on-demand.yaml @@ -88,6 +88,15 @@ info: - For scenarios which do not have a single device identifier associated to the token during the authentication flow, e.g. 2-legged access tokens, the `device` object MUST be provided in the API request. This ensures that the device identification is explicit and valid for each API call made with these tokens. + # Multi-SIM scenario handling + + In multi-SIM scenarions where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the enhanced QoS profile should apply from that phone number. If the phone number is used as the device identifier when creating a QoS session in a multi-SIM scenario, the API may respond with an error, or may apply the enhanced QoS profile to a device other than the intended device. + + Possible workarounds in such a scenario include: + - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device + - Identifying the intended device from a unique identifier for that device, such as its source IP address and port + - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device + # Further info and support (FAQs will be added in a later version of the documentation) From 9eb5a3487a087ac5681c72e317c21411163205be Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Tue, 26 Nov 2024 10:54:19 +0000 Subject: [PATCH 02/15] Update qod-provisioning.yaml --- code/API_definitions/qod-provisioning.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/code/API_definitions/qod-provisioning.yaml b/code/API_definitions/qod-provisioning.yaml index 7b1a4bcb7..07ae32c83 100644 --- a/code/API_definitions/qod-provisioning.yaml +++ b/code/API_definitions/qod-provisioning.yaml @@ -57,6 +57,16 @@ info: ### Restrictions for tokens without an associated authenticated identifier: - For scenarios which do not have a single device identifier associated to the token during the authentication flow, e.g. 2-legged access tokens, the `device` object MUST be provided in the API request. This ensures that the device identification is explicit and valid for each API call made with these tokens. + + # Multi-SIM scenario handling + + In multi-SIM scenarions where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to a device other than the intended device. + + Possible workarounds in such a scenario include: + - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device + - Identifying the intended device from a unique identifier for that device, such as its source IP address and port + - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device + license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html From ad80eb9bc3717762ed9b0b36258fd40d2f036d99 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Tue, 26 Nov 2024 11:00:23 +0000 Subject: [PATCH 03/15] Update qos-profiles.yaml --- code/API_definitions/qos-profiles.yaml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/code/API_definitions/qos-profiles.yaml b/code/API_definitions/qos-profiles.yaml index 68ddde1a6..02727c434 100644 --- a/code/API_definitions/qos-profiles.yaml +++ b/code/API_definitions/qos-profiles.yaml @@ -48,6 +48,13 @@ info: - For scenarios which do not have a single device identifier associated to the token during the authentication flow, e.g. 2-legged access tokens, the `device` object MUST be provided in the API request. This ensures that the device identification is explicit and valid for each API call made with these tokens. + # Multi-SIM scenario handling + + In multi-SIM scenarions where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify a single device from that phone number. When filtering QoS profiles by device in such scenarios, one of the following options should be used: + - Use the authorisation code flow to obtain a 3-legged access token, which will automatically identify the intended device + - Identify the intended device from a unique identifier for that device, such as its source IP address and port + - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device + # Further info and support (FAQs will be added in a later version of the documentation) From 97d3d5080fc65bb0e1396a5010f2d1042dbe3020 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Tue, 26 Nov 2024 11:03:16 +0000 Subject: [PATCH 04/15] Update quality-on-demand.yaml --- code/API_definitions/quality-on-demand.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/API_definitions/quality-on-demand.yaml b/code/API_definitions/quality-on-demand.yaml index f94154aea..855562fdb 100644 --- a/code/API_definitions/quality-on-demand.yaml +++ b/code/API_definitions/quality-on-demand.yaml @@ -90,7 +90,7 @@ info: # Multi-SIM scenario handling - In multi-SIM scenarions where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the enhanced QoS profile should apply from that phone number. If the phone number is used as the device identifier when creating a QoS session in a multi-SIM scenario, the API may respond with an error, or may apply the enhanced QoS profile to a device other than the intended device. + In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the enhanced QoS profile should apply from that phone number. If the phone number is used as the device identifier when creating a QoS session in a multi-SIM scenario, the API may respond with an error, or may apply the enhanced QoS profile to a device other than the intended device. Possible workarounds in such a scenario include: - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device From 7306ed43d9d6b4cbaebee63bb75920389e4d1eeb Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Tue, 26 Nov 2024 11:03:36 +0000 Subject: [PATCH 05/15] Update qod-provisioning.yaml --- code/API_definitions/qod-provisioning.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/API_definitions/qod-provisioning.yaml b/code/API_definitions/qod-provisioning.yaml index 07ae32c83..6df7b1238 100644 --- a/code/API_definitions/qod-provisioning.yaml +++ b/code/API_definitions/qod-provisioning.yaml @@ -60,7 +60,7 @@ info: # Multi-SIM scenario handling - In multi-SIM scenarions where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to a device other than the intended device. + In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to a device other than the intended device. Possible workarounds in such a scenario include: - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device From 5f9423bf1ef11c566ae9e1c7ee37c47233895d88 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Tue, 26 Nov 2024 11:03:56 +0000 Subject: [PATCH 06/15] Update qos-profiles.yaml --- code/API_definitions/qos-profiles.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/API_definitions/qos-profiles.yaml b/code/API_definitions/qos-profiles.yaml index 02727c434..8aadea041 100644 --- a/code/API_definitions/qos-profiles.yaml +++ b/code/API_definitions/qos-profiles.yaml @@ -50,7 +50,7 @@ info: # Multi-SIM scenario handling - In multi-SIM scenarions where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify a single device from that phone number. When filtering QoS profiles by device in such scenarios, one of the following options should be used: + In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify a single device from that phone number. When filtering QoS profiles by device in such scenarios, one of the following options should be used: - Use the authorisation code flow to obtain a 3-legged access token, which will automatically identify the intended device - Identify the intended device from a unique identifier for that device, such as its source IP address and port - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device From 64aeabe2a626ab14515ae6aa44c5b31d99b9e486 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 13:09:30 +0000 Subject: [PATCH 07/15] Update qod-provisioning.yaml --- code/API_definitions/qod-provisioning.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/code/API_definitions/qod-provisioning.yaml b/code/API_definitions/qod-provisioning.yaml index 6df7b1238..ffa1a24f2 100644 --- a/code/API_definitions/qod-provisioning.yaml +++ b/code/API_definitions/qod-provisioning.yaml @@ -60,9 +60,9 @@ info: # Multi-SIM scenario handling - In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, or may apply the provisioning to a device other than the intended device. + In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, apply the provisioning to all devices in the multi-SIM group, or apply the provisioning to a device in the multi-SIM group other than the intended device. - Possible workarounds in such a scenario include: + Possible solutions in such a scenario include: - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device - Identifying the intended device from a unique identifier for that device, such as its source IP address and port - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device From bf1c29ae79e9ad9a35778270fa528c20604f854a Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 13:13:11 +0000 Subject: [PATCH 08/15] Update quality-on-demand.yaml --- code/API_definitions/quality-on-demand.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/code/API_definitions/quality-on-demand.yaml b/code/API_definitions/quality-on-demand.yaml index 855562fdb..079f0953e 100644 --- a/code/API_definitions/quality-on-demand.yaml +++ b/code/API_definitions/quality-on-demand.yaml @@ -90,9 +90,9 @@ info: # Multi-SIM scenario handling - In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the enhanced QoS profile should apply from that phone number. If the phone number is used as the device identifier when creating a QoS session in a multi-SIM scenario, the API may respond with an error, or may apply the enhanced QoS profile to a device other than the intended device. + In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the enhanced QoS profile should apply from that phone number. If the phone number is used as the device identifier when creating a QoS session in a multi-SIM scenario, the API may respond with an error, apply the enhanced QoS profile to all devices in the multi-SIM group, or apply the enhanced QoS profile to a single device in the multi-SIM group other than the intended device. - Possible workarounds in such a scenario include: + Possible solutions in such a scenario include: - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device - Identifying the intended device from a unique identifier for that device, such as its source IP address and port - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device From 4c03f0bbd81d28cc9a9bda9f252423c690bc2bc7 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 14:39:16 +0000 Subject: [PATCH 09/15] Update code/API_definitions/qod-provisioning.yaml Co-authored-by: Jose Luis Urien --- code/API_definitions/qod-provisioning.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/API_definitions/qod-provisioning.yaml b/code/API_definitions/qod-provisioning.yaml index ffa1a24f2..ff73e4e8f 100644 --- a/code/API_definitions/qod-provisioning.yaml +++ b/code/API_definitions/qod-provisioning.yaml @@ -65,7 +65,7 @@ info: Possible solutions in such a scenario include: - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device - Identifying the intended device from a unique identifier for that device, such as its source IP address and port - - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device + - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device if available. license: name: Apache 2.0 From 84887b239a60516a35e72e289d01ae06c9b9f263 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 14:49:10 +0000 Subject: [PATCH 10/15] Update qod-provisioning.yaml --- code/API_definitions/qod-provisioning.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/API_definitions/qod-provisioning.yaml b/code/API_definitions/qod-provisioning.yaml index ff73e4e8f..dd0fc9509 100644 --- a/code/API_definitions/qod-provisioning.yaml +++ b/code/API_definitions/qod-provisioning.yaml @@ -60,7 +60,7 @@ info: # Multi-SIM scenario handling - In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, apply the provisioning to all devices in the multi-SIM group, or apply the provisioning to a device in the multi-SIM group other than the intended device. + In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the QoS provisioning should apply from that phone number. If the phone number is used as the device identifier when provisioning in a multi-SIM scenario, the API may respond with an error, apply the provisioning to all devices in the multi-SIM group, or apply the provisioning to a single device in the multi-SIM group which may not be the intended device. Possible solutions in such a scenario include: - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device From 88f8353b32143c409147b7c059baf4d2514d9202 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 14:51:26 +0000 Subject: [PATCH 11/15] Update quality-on-demand.yaml --- code/API_definitions/quality-on-demand.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/code/API_definitions/quality-on-demand.yaml b/code/API_definitions/quality-on-demand.yaml index 079f0953e..fa53cfae2 100644 --- a/code/API_definitions/quality-on-demand.yaml +++ b/code/API_definitions/quality-on-demand.yaml @@ -90,12 +90,12 @@ info: # Multi-SIM scenario handling - In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the enhanced QoS profile should apply from that phone number. If the phone number is used as the device identifier when creating a QoS session in a multi-SIM scenario, the API may respond with an error, apply the enhanced QoS profile to all devices in the multi-SIM group, or apply the enhanced QoS profile to a single device in the multi-SIM group other than the intended device. + In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the enhanced QoS profile should apply from that phone number. If the phone number is used as the device identifier when creating a QoS session in a multi-SIM scenario, the API may respond with an error, apply the enhanced QoS profile to all devices in the multi-SIM group, or apply the enhanced QoS profile to a single device in the multi-SIM group which may not be the intended device. Possible solutions in such a scenario include: - Using the authorisation code flow to obtain an access token, which will automatically identify the intended device - Identifying the intended device from a unique identifier for that device, such as its source IP address and port - - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device + - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device if available # Further info and support From dd73326494d73ffcb6ddc073b47bb76759d82a53 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 14:52:43 +0000 Subject: [PATCH 12/15] Update qos-profiles.yaml --- code/API_definitions/qos-profiles.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/API_definitions/qos-profiles.yaml b/code/API_definitions/qos-profiles.yaml index 8aadea041..9a4cdadd8 100644 --- a/code/API_definitions/qos-profiles.yaml +++ b/code/API_definitions/qos-profiles.yaml @@ -53,7 +53,7 @@ info: In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify a single device from that phone number. When filtering QoS profiles by device in such scenarios, one of the following options should be used: - Use the authorisation code flow to obtain a 3-legged access token, which will automatically identify the intended device - Identify the intended device from a unique identifier for that device, such as its source IP address and port - - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device + - Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device if available # Further info and support From 4918460317e2f6950f3fba1781d93f537d5e982e Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 14:55:26 +0000 Subject: [PATCH 13/15] Update qod-provisioning.yaml --- code/API_definitions/qod-provisioning.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/code/API_definitions/qod-provisioning.yaml b/code/API_definitions/qod-provisioning.yaml index dd0fc9509..5c4eeea4e 100644 --- a/code/API_definitions/qod-provisioning.yaml +++ b/code/API_definitions/qod-provisioning.yaml @@ -70,7 +70,7 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: 0.1.0 + version: wip x-camara-commonalities: 0.4.0 externalDocs: @@ -78,7 +78,7 @@ externalDocs: url: https://github.com/camaraproject/QualityOnDemand servers: - - url: "{apiRoot}/qod-provisioning/v0.1" + - url: "{apiRoot}/qod-provisioning/vwip" variables: apiRoot: default: http://localhost:9091 From 98e4650a4ea8b590d0df4758744695a6d1bd35b0 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 14:55:55 +0000 Subject: [PATCH 14/15] Update qos-profiles.yaml --- code/API_definitions/qos-profiles.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/code/API_definitions/qos-profiles.yaml b/code/API_definitions/qos-profiles.yaml index 9a4cdadd8..01bfa195c 100644 --- a/code/API_definitions/qos-profiles.yaml +++ b/code/API_definitions/qos-profiles.yaml @@ -62,7 +62,7 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: 0.11.0 + version: wip x-camara-commonalities: 0.4.0 @@ -71,7 +71,7 @@ externalDocs: url: https://github.com/camaraproject/QualityOnDemand servers: - - url: "{apiRoot}/qos-profiles/v0.11" + - url: "{apiRoot}/qos-profiles/vwip" variables: apiRoot: default: http://localhost:9091 From e53c32044310d9895b2cb90f6bb9c6f82dd4fad4 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Fri, 29 Nov 2024 14:56:25 +0000 Subject: [PATCH 15/15] Update quality-on-demand.yaml --- code/API_definitions/quality-on-demand.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/code/API_definitions/quality-on-demand.yaml b/code/API_definitions/quality-on-demand.yaml index fa53cfae2..40035b987 100644 --- a/code/API_definitions/quality-on-demand.yaml +++ b/code/API_definitions/quality-on-demand.yaml @@ -104,7 +104,7 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: 0.11.0 + version: wip x-camara-commonalities: 0.4.0 externalDocs: @@ -112,7 +112,7 @@ externalDocs: url: https://github.com/camaraproject/QualityOnDemand servers: - - url: "{apiRoot}/quality-on-demand/v0.11" + - url: "{apiRoot}/quality-on-demand/vwip" variables: apiRoot: default: http://localhost:9091