Notify Event must be define on callback part in the same openapi spec

[BenjaminBusvel]

Problem description You have create a specific yaml file for notification (BYON-Notification-Channel.yaml) but

Expected behavior the guideline (https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#12-subscription-notification--event) define it on callback part on the same swagger BYON-CallHandling-Service.yaml

See the best practice API : https://github.com/camaraproject/QualityOnDemand/blob/main/code/API_definitions/qod-api.yaml#L104

Alternative solution

Additional context

[deepakjaiswal1]

@BenjaminBusvel The existing notification guideline is designed for a single notification channel type, specifically Webhooks. However, in the case of BYON, developers require support for multiple notification channel types based on the type of application they are building. These notification channels could include Webhooks, WebSocket, Push-Channel, and more.

I agree that it is necessary to integrate the Subscription API into the BYON-Challing.yml to define different notification events and register the required type of notification channel for the application created by the application using create notification channel API.

[stroncoso-quobis]

While documenting interaction on the UML sequence diagrams, I faced this problem. I just limit the documentation to the happy path but that makes clear for me this as a requirement.

[stroncoso-quobis]

Hi @BenjaminBusvel,

This notification compliance problems was addressed also by @hdamker at https://github.com/camaraproject/WebRTC/pull/47#issuecomment-2293530246

We are looking for a way to support this, @deepakjaiswal1, me and others discussed this today, but we need to get more consensus. May are you open to discuss live or maybe include extra information here as comments?

Some points to get it clear:

• We need a communication channel with the client for async events (ex.: far end pickup) that's why this WS was defined. A way to communicate from the server with the web browser client.
• Full agree to have a common notification channel, webhook makes sense to me when addressing mobile devices (PUSH notif) and server-side communications.... but not sure if we can support WS with this common approach.

Any idea about to help unblock this feature?

Regards,

[stroncoso-quobis]

Hi all,

Discussed today (MoMs), we are finally addressing this problem. Well, two problems, in fact:

• How to solve the websocket events issue (web use case)
• Formality about how to include the callback on the API

First, the classic example of WebRTC API that we want to cover is a browser login on a web and making calls from it. To cover it, the solution should include several notification channels (Websockets, Push Notification Systems and webhooks).

Since CAMARA compliance demands explicitly https webhooks defined by the consumer, we need to separate the gateway itself (WebRTC GW) from the Notification System.

So, we purpose a separated optional system (the Notification System), where the consumer can create a WS, or any other notification method. Now, when requesting a subscription (eg.: when making a call), you can specify as sink your own notification URL or provide the one created on the Notification System.

This allows us to explain, with confidence, an async method like the session creation and provide a valid implementation logic for web (user) consumers and server consumers. In addition, we consider this architecture isolated and something that we can export to any other system, or API, so fell free to take it as inspiration.

This will be translated on the callback referred by @BenjaminBusvel , convered on the API-design-guidelines and the API template on the commonalities repo at the event-subscription-template.

So, in summary:

• The WebRTC GW will be CAMARA compliant, supporting webhooks
• The Notificatation System will be an optional component, that can be used to create WS notification channels.

Summary: it will be great that CAMARA consider some kind of WS, but it does not, so, meanwhile, we will accept to keep it isolated as an optional extra feature. So, I will start to work on PR on this line and try to fix this compliance problem. The PR will refer as a fix for this issue.

Best regards,