Support registration expiry updates and termination event notifications by deepakjaiswal1 · Pull Request #83 · camaraproject/WebRTC

deepakjaiswal1 · 2025-05-26T04:47:17Z

This pull request introduces enhancements to the WebRTC Registration and Event Subscription APIs to support explicit registration expiry handling and corresponding event notifications.

Changes in webrtc-registration.yaml:

Introduced regSessionUpdate schema with optional registrationExpireTime field to allow clients to request a new expiry time.
Added 200 OK response definition for PUT /sessions/{registrationId} to acknowledge successful updates.
Extended regSessionResponse schema to include expiresAt, indicating the assigned expiry time of the registration session.

Changes in webrtc-events-subscription.yaml:

Added new event type webrtc-events:org.camaraproject.webrtc-events.v0.registration-ends to notify subscribers when a registration ends.
Provided a concrete example for the registration-ends event subscription.
Extended TerminationReason enumeration to include REGISTRATION_EXPIRED, allowing precise classification of expiry-based terminations.

These updates support Issue #75 by enabling session expiry semantics and related eventing mechanisms as part of the WebRTC-Registration API.

Which issue(s) this PR fixes:

Fixes #75

Please review and provide feedback.

@stroncoso-quobis @pradeepachar-mavenir @teikuran

webrtc-registration.yaml: - Added regSessionUpdate schema with registrationExpireTime to support client-driven registration expiry updates. - Introduced 200 OK response for PUT /sessions/{registrationId} to confirm update success. - Added expiresAt field to regSessionResponse schema to explicitly convey registration expiry time. webrtc-events-subscription.yaml: - Added new event type: webrtc-events:org.camaraproject.webrtc-events.v0.registration-ends for registration end notifications. - Included example usage for registration ends subscription. - Added REGISTRATION_EXPIRED to TerminationReason enum to distinguish expiry-based termination events.

linux-foundation-easycla · 2025-05-26T04:47:21Z

The committers listed above are authorized under a signed CLA.

✅ login: deepakjaiswal1 / name: Deepak Jaiswal (eef3327, 9ac7ba7, 3a07313, 8d7991f, 739b418, 0b34377, bc029fb, aa748dd, ff46b8c, 8907b7b, 46039b1)

…on-ends CloudEvent type

code/API_definitions/webrtc-registration.yaml

teikuran · 2025-06-03T05:59:54Z

code/API_definitions/webrtc-registration.yaml

            The device-id of the client in UUID format. A unique identifier for
            the physical device where a registration is initiated. Generated
            by the WebRTC application, and consistent within the same device.
+        registrationExpireTime:


If I understand correclty, the client should(can or better to) perform re-registration using a PUT request before the expiry time provided in the 200 OK response. Some description about how to treat the expiry time at client may be beneficial.

@teikuran I've added a description outlining the client's behavior for re-registration. Could you please take a look and share your feedback?

Thank you. And looks fine to me.

teikuran · 2025-06-03T06:03:57Z

code/API_definitions/webrtc-registration.yaml

      security:
        - openId:
            - webrtc-registration:sessions:write
+      requestBody:


Just a clarification in relation to access token lifetime, is it correct to understand that even if the API access token expires while a WebRTC registration is active, the WebRTC registration itself will remain valid?

Based on provided responses during the meeting, they are independent, one related with the API access, the other related with the device registration on the network.

The same applies to subscription-expires, that it is independent of the registration-expires.

stroncoso-quobis · 2025-06-03T15:38:04Z

Comments from today's meeting:

@deepakjaiswal1 , needed to fulfil EasyCLA. Confirmed that it is in progress.

QUESTION: Should we use TTL instead of absolute timestamp for registrationExpireTime field?
- We will keep using timestamps since it is a common field type in CAMARA.
- Non-SIM devices or other no-time-sync devices must take that in account. A documentation note will help to point this issue.
QUESTION: It will be great to include some doc text about how to handle remaining network registration time left on server side when the developer refresh
- Agreed. Deepak will provide some comments to clarify.
QUESTION: Is there any link between access-token and webrtc network registration time to live?
- No, there is a callback access token and the API access token. The first one only lives during the subscription itself, and it depends on the API consumer device, the later is related with the API exposure function (aggregator or network operator).
QUESTION: Is there any link between events registration-ends and subscription-ends?
- No, first refer to the status of the device on the network, the second to the status of the callback mechanism between API exposure function and application.
QUESTION: For webrtc-event-subscriptions. We agree to remove the deviceId and keep configuration based only on registrationId?
- If we declare a requirement on the registrationId, then we imply a sequence: Registration first, then subscription.
- Pointed by @teikuran and their implementation idea for Resolving the gap issue in WebRTC Events #64 , this sequence will always bring a gap between the REGISTER and the SUBSCRIPTION, then a potential loss of signaling.
- It is possible to invert the sequence, but for that, we need to recoved the deviceId as mandatory.
- Agreed to keep discussing on the corresponding issue.
- Need to agree into some flow diagrams before proceed.

code/API_definitions/webrtc-events-subscription.yaml

This commit refines the WebRTC registration documentation in three areas: registrationExpireTime guidance Keeps the field as an absolute RFC 3339 timestamp but now explains how devices without a reliable clock can derive a TTL and refresh early. Notes server-side defaulting when the client omits the field. Refresh-time algorithm (PUT /sessions/{registrationId}) Documents the server logic for extending a registration: remaining = prevExpire – requestTime; new = requestTime + operatorTTL. Clarifies when a late refresh may be rejected and states that the same registrationId is reused unless policy dictates otherwise. Aligns request (registrationExpireTime) and response (expiresAt) schema descriptions with this algorithm. Editorial clean-ups

stroncoso-quobis

Great work. Agree on all changes!

But we need to address some mandatory changes:

Remove .DS_Store file
version field, to change to vwip
recover subscription-ends event type

I tried to add suggestions for all changes, so it should be easy to cover on your side.
Thanks a lot for the contribution! 👏

code/API_definitions/webrtc-registration.yaml

code/API_definitions/.DS_Store

code/API_definitions/webrtc-events-subscription.yaml

code/API_definitions/webrtc-registration.yaml

Changed version to vwip and removed .DS_store

Removed .DS_Store

@stroncoso-quobis

@stroncoso-quobis feedback incorporated.

stroncoso-quobis

LGTM!

After meeting and live review, PR is good to go.
Approving and merging.

Thanks for your contribution!

deepakjaiswal1 requested review from stroncoso-quobis and sushanthmavenir as code owners May 26, 2025 04:47

deepakjaiswal1 added 4 commits May 25, 2025 22:45

Fix lint issues with registration-ends event

0b34377

Fix lint issues

8907b7b

Fixed lint issue: added org.camaraproject.webrtc-events.v0.registrati…

aa748dd

…on-ends CloudEvent type

Cleaned notification type conflicts

eef3327

teikuran reviewed Jun 3, 2025

View reviewed changes

code/API_definitions/webrtc-registration.yaml Show resolved Hide resolved

teikuran reviewed Jun 3, 2025

View reviewed changes

stroncoso-quobis mentioned this pull request Jun 3, 2025

Resolving the gap issue in WebRTC Events #64

Open

teikuran reviewed Jun 4, 2025

View reviewed changes

code/API_definitions/webrtc-events-subscription.yaml Show resolved Hide resolved

teikuran reviewed Jun 16, 2025

View reviewed changes

code/API_definitions/webrtc-events-subscription.yaml Outdated Show resolved Hide resolved

code/API_definitions/webrtc-events-subscription.yaml Show resolved Hide resolved

teikuran reviewed Jun 16, 2025

View reviewed changes

code/API_definitions/webrtc-events-subscription.yaml Show resolved Hide resolved

deepakjaiswal1 added 2 commits June 16, 2025 14:01

Lint error removed

bc029fb

stroncoso-quobis suggested changes Jul 2, 2025

View reviewed changes

deepakjaiswal1 added 4 commits July 2, 2025 12:10

Updated version and removed .DS_Store

46039b1

Changed version to vwip and removed .DS_store

Remove .DS_Store

ff46b8c

Removed .DS_Store

Feedback incorporated.

8d7991f

@stroncoso-quobis feedback incorporated.

Trailing spaces removed

739b418

stroncoso-quobis approved these changes Jul 3, 2025

View reviewed changes

stroncoso-quobis merged commit 5fbdae9 into camaraproject:main Jul 3, 2025
2 checks passed

stroncoso-quobis added a commit to stroncoso-quobis/WebRTC that referenced this pull request Jul 3, 2025

Initial draft for PRs camaraproject#83 camaraproject#85 camaraproject#86

487452a

stroncoso-quobis added a commit to stroncoso-quobis/WebRTC that referenced this pull request Jul 7, 2025

doc: update registration after camaraproject#83 pr merged

114d33c

stroncoso-quobis added a commit to stroncoso-quobis/WebRTC that referenced this pull request Jul 15, 2025

Initial draft for PRs camaraproject#83 camaraproject#85 camaraproject#86

91ccfb7

hdamker mentioned this pull request Jul 16, 2025

WebRTC Release r2.1 candidate for Fall25 #91

Merged

stroncoso-quobis added a commit to stroncoso-quobis/WebRTC that referenced this pull request Jul 28, 2025

Initial draft for PRs camaraproject#83 camaraproject#85 camaraproject#86

72eaeb5

stroncoso-quobis mentioned this pull request Sep 9, 2025

UML supporting documentation review for r2.2 #109

Closed

Conversation

deepakjaiswal1 commented May 26, 2025 • edited by stroncoso-quobis Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linux-foundation-easycla bot commented May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

teikuran Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deepakjaiswal1 Jun 16, 2025

Choose a reason for hiding this comment

Uh oh!

teikuran Jul 3, 2025

Choose a reason for hiding this comment

Uh oh!

teikuran Jun 3, 2025

Choose a reason for hiding this comment

Uh oh!

stroncoso-quobis Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stroncoso-quobis commented Jun 3, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stroncoso-quobis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stroncoso-quobis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

deepakjaiswal1 commented May 26, 2025 •

edited by stroncoso-quobis

Loading

linux-foundation-easycla bot commented May 26, 2025 •

edited

Loading

teikuran Jun 3, 2025 •

edited

Loading

stroncoso-quobis Jun 3, 2025 •

edited

Loading