Propose additional RegistrationStatus enum

[mhfoo]

Problem description
Current RegistrationStatus enum is only "Registered"

Possible evolution
add the following enum:

• Expired - updated when registrationExpireTime has lapsed
• Unregistered - updated when the DELETE /session/{registrationId} is requested successfully

Alternative solution
NA.

Additional context
Allow additional RegistrationStatus values

[teikuran]

@mhfoo
Thank you for this comment.

Just to share my understading on the current speccification: The current API specification limits RegistrationStatus only to Registered as it is returned within a successful 200 OK response context (regisration is successful). Because of this nature, it only has Registered.

To my understanding, Expired is handled via the registration-ends event in the WebRTC Events API, and Unregistered is represented by the 204 No Content response of the DELETE operation.

With that, is there any reasoning of Expired and Unregistered?

[mhfoo]

@teikuran

To have Expired and Unregistered for audit trail purposes. Currently there is no GET endpoint, so this serves as an internal reporting to understand whether it is an API Consumer action / intention.

[stroncoso]

Hi @mhfoo ,

As @teikuran commented, there's no GET, so expired is a message, not an status. Indeed, the endpoint lacks of a GET operation, and it makes sense to include it. It will make the endpoint fulfilled. That will be a great point.

Under valid request, a GET operation should bring the following responses:

• 200 OK + registrationStatus
• 404 Not found. Meaning unregistered.

Nevertheless, the expired status, as a subset of unregistered due timeout condition included on the GET response, demands that the network keeps the status of sessions already expired. In consequence, the network needs to store all the sessions, keep them during some amount of time, then, finally remove them. That opens a configuration parameter (expiration_retention) and bring extra complexity.

As an alternative, expired as a UX state for endpoints can be handled by the API consumer (apps) using the status updates. But it demands too much if exposed directly from the network.

Anyway, the GET operation is a great addition. Are you open to contribute enhancing the endpoint with the GET operation and these two responses (200/404)?

Best regards,