Clarification on Subscriptions

[sachinvodafone]

Hi Team ,

I would like to clarify couple of things on subscription :

1. According to the API design guidelines for subscriptions, startsAt is defined as the "Date when the event subscription will begin/began." However, it is unclear whether this refers to the initiation of the subscription creation process or the actual time when the subscription becomes active.

2. Additionally, should the user expect the "ACTIVATION_REQUESTED" status for synchronous subscriptions? The expectation is that subscription creation and activation should occur immediately for synchronous processes (please correct me if I am wrong). Therefore, using "ACTIVATION_REQUESTED" as a status in a synchronous context would indeed be confusing and typically inappropriate. The status should always be "ACTIVE" in response.

[patrice-conil]

Hi @sachinvodafone,

1. Need a clarification if it's not clear ... for me it's time when subscription becomes active.
2. Because we rely on a sometimes asynchronous system (QoD activation via SCEF/NEF for example)... it is difficult to respond synchronously with low response time and reliable status (and you will have to manage rollbacks when activation starts after timeout).

[sachinvodafone]

My view on that:

1. "startsAt", yes it should not be mandatory, because it is a real value when subscription reaches "ACTIVE" value
2. "ACTIVATION_REQUESTED" status for synchronous subscription would not make sense, as the subscription would be effectively created i.e. "ACTIVE" status

I am aligned with @PedroDiez ; otherwise, we need to explicitly describe it in the documentation for clarity for both scenario.

[sfnuser]

At least in QoD, startedAt refers to the session start and not the session ACTIVE status. The extend endpoint and expiresAt documentation is consistent that it is session start. If the user is interested in the exact duration of session status being ACTIVE, probably a new field needs to be introduced.

[maxl2287]

@sfnuser based on the current main-branch of QoD the definition of startedAt is

Date and time when the QoS status became "AVAILABLE". Not to be returned when qosStatus is "REQUESTED".

An AVAILABLE session has the same meaning here like an ACTIVE subscription.
Means in QoD a sessions starts on the time when it comes AVAILABLE.

I know that you may refer to v0.10.1, but with camaraproject/QualityOnDemand#296 the definition changed for startedAt and expiresAt

[sfnuser]

@maxl2287: Yeah, I am still looking at v0.10.1. Thanks for pointing out the new updates 👍🏼

[sachinvodafone]

At least in QoD, startedAt refers to the session start and not the session ACTIVE status. The extend endpoint and expiresAt documentation is consistent that it is session start. If the user is interested in the exact duration of session status being ACTIVE, probably a new field needs to be introduced.

Hi @sfnuser , If we move forward with the QoD implementation where 'startedAt' refers to the session 'start' (despite @maxl2287 highlighting that it’s not the case as per current v0.10.1.), then the asynchronous response should also include the 'startedAt' date with the status 'ACTIVATION_REQUESTED'. Currently, we are only sending the 'subscriptionID' in response like:

{
  "subscriptionId": "550e8400-e29b-41d4-a716-446655440000"
}

Additionally, if we consider 'startedAt' as the session 'start' and the asynchronous process takes significant time to create a subscription (like 5 minutes) while the expireTime is only 10 minutes, that means 5 minutes are already consumed, and the client won't be able to utilize that time.

Regarding point two of my original post, I still believe that the status should always be 'Active' in the case of synchronous processes, and 'ACTIVATION_REQUESTED' should not apply.