Create QoS Session to manage latency/throughput priorities
If the qosStatus in the API response is "AVAILABLE" and a notification callback is provided the client will receive in addition to the response a
QOS_STATUS_CHANGED
event notification with qosStatus
as AVAILABLE
.
If the qosStatus
in the API response is REQUESTED
, the client will receive either
- a
QOS_STATUS_CHANGED
event notification withqosStatus
asAVAILABLE
after the network notifies that it has created the requested session, or - a
QOS_STATUS_CHANGED
event notification withqosStatus
asUNAVAILABLE
andstatusInfo
asNETWORK_TERMINATED
after the network notifies that it has failed to provide the requested session.
A QOS_STATUS_CHANGED
event notification with qosStatus
as UNAVAILABLE
will also be send if the network terminates the session before the requested duration expired
NOTE: in case of a QOS_STATUS_CHANGED
event with qosStatus
as UNAVAILABLE
and statusInfo
as NETWORK_TERMINATED
the resources of the QoS session
are not directly released, but will get deleted automatically at earliest 360 seconds after the event.
This behavior allows clients which are not receiving notification events but are polling to get the session information with
the qosStatus
UNAVAILABLE
(the statusInfo
parameter is not included in the current version but will be adding to SessionInfo
in an upcoming release). Before a client can attempt to create a new QoD session
for the same device and flow period they must release the session resources with an explicit delete
operation if not yet automatically deleted.
Check the Authorization guide on how to get an OAuth2 token, with the following scope:
dpv:RequestedServiceProvision#qod
Create an app on our Sandbox to get credentials and retrieve tokens so you can perform API calls to our operators' production environments, or use the following convenience token to test in mock mode:
mock_sandbox_access_token
You can explore our QoD sample code for additional guidance on using this API.