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_CHANGEDevent notification withqosStatusasAVAILABLEafter the network notifies that it has created the requested session, or - a
QOS_STATUS_CHANGEDevent notification withqosStatusasUNAVAILABLEandstatusInfoasNETWORK_TERMINATEDafter 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.