Add registration-expiry semantics and notifications to WebRTC-Registration API

[deepakjaiswal1]

Problem description

The current WebRTC-Registration API offers no way for a client to discover, control, or be warned about the lifetime of its registration:

• The POST /sessions response omits any expiresAt/validUntil field, so the app cannot tell when the registration becomes invalid.
• The PUT /sessions/{registrationId} operation cannot extend the existing TTL, nor is the TTL refreshed implicitly when other WebRTC APIs are invoked.
• The platform provides no CloudEvent (via WebRTC-Events) to signal that the registration has lapsed, leaving the client unaware that a new registration is required.

Expected behavior

1. Optional client-requested TTL – Add an optional requestedValiditySeconds or registrationExpireTime in the POST body; if absent, the gateway applies its default.
2. Explicit expiry in responses – Both POST and PUT must return an expiresAt timestamp so the client can schedule proactive renewal.
3. Renewal via PUT – Allow the same TTL fields in PUT /sessions/{registrationId} to extend validity before expiry.
4. Optional sliding-window refresh – Each successful WebRTC API call may refresh the registration server-side (nice-to-have).
5. Expiry notification – Emit a CloudEvent such as org.camaraproject.webrtc-registration.v0.registration-expires over the existing WebRTC-Events channel when the registration reaches expiresAt (or is revoked).

Alternative solution

• Rely solely on the generic org.camaraproject.webrtc-events.v0.subscription-ends event for expiry, but document that it applies to registrations.
• Provide a separate lightweight “keep-alive” endpoint instead of extending PUT semantics.
• Allow clients to query remaining TTL with a HEAD request returning Expires header rather than embedding it in the JSON payload.

Additional context

• Aligns with CAMARA Commonalities TTL handling used in other APIs (e.g., device-location).
• Prevents silent call failures due to stale registrations, improving UX.
• Requires schema updates in webrtc-registration.yaml and corresponding examples; also needs an event-type addition in webrtc-events-subscription.yaml.

[deepakjaiswal1]

@stroncoso-quobis @pradeepachar-mavenir Please review above issue.

[pradeepachar-mavenir]

• Registration time period is determined by the network rather than the clients, providing the expiresAt attribute in the response should be fine.
• Clients tracking the registration expiry and proactively extending the refresh, will it not add overhead on the clients ?
• Refreshing the expiry on each client invoked API would increase the n/w side traffic and hence not recommended.
• Client refreshing the registration on expiry notification is fine.

[stroncoso-quobis]

My feedbck:
1.- Optional register TTL on requests looks good to me as it is optional. Network will have the last word.
2.- Registration status should have a expiresAt, if response brings back the object, it shuold include. LGTM.
3.- PUT extending TTL makes sense to me, as it will help reduce re-creation of teh same events.
4.- Agree with @pradeepachar-mavenir , sliding-window does not look really an advantage here.
5.- Expirity via CloudEvents looks great.

Regards,