Updated yaml files

[pradeepachar-mavenir]

• Updated RACM and CallHandling specifications.
• Notification Channel specification are added.

What type of PR is this?

Add one of the following kinds:

• bug
• correction
• enhancement/feature
• cleanup
• documentation
• subproject management
• tests

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[pradeepachar-mavenir]

@sushanthmavenir @TEF-RicardoSerr , please review the pull request.

[TEF-RicardoSerr]

Hello,

How would it fit the integration of other notification methods in the specifications? In the previous versions of the API, PNS was integrated in the RACM specification but it is no longer in any of these new specs. Would it be possible to include PNS in the new specification?

[pradeepachar-mavenir]

Hello,

How would it fit the integration of other notification methods in the specifications? In the previous versions of the API, PNS was integrated in the RACM specification but it is no longer in any of these new specs. Would it be possible to include PNS in the new specification?

In the new notification API, there is channelType defined, this can be extended to support new notification channels as requried.

[TEF-RicardoSerr]

Do you find it feaseable to include PNS in this specification @pradeepachar-mavenir? Could you please include it?

[deepakjaiswal1]

@pradeepachar-mavenir We should eliminate the use of userId within the CallHandling APIs, as users can be identified through the access/identification token.

Additionally, we should consider removing the responseCode from SessionInvitationNotification, SessionStatusNotification, and ReceiverStatusNotification. This information is redundant and could cause confusion for developers using the endpoints.

[deepakjaiswal1]

@pradeepachar-mavenir @TEF-RicardoSerr

We firmly believe that the Channel service provider could function as an independent service rather than being integrated into the WebRTC GW. In our perspective, the RACM & channel APIs should follow this call-flow:

A) The client app initiates the creation of a channel (WebSocket).

POST /channels { "notificationChannel": { "channelType": "WebSockets", "channelData": { "maxNotifications": "1" }, "clientCorrelator": "xyz123" } }

HTTP/1.1 201 Created { "notificationChannel": { "callbackURL": "http://example.com/callBackUrl/cbu112", "channelData": { "channelURL": "ws://example.com/exampleAPI/notificationchannel/v1/tel%3A%2B19585550100/channels/ch378/ws", "maxNotifications": "1" }, "channelType": "WebSockets", "clientCorrelator": "xyz123", "resourceURL": "http://example.com/exampleAPI/notificationchannel/v1/tel%3A%2B19585550100/channels/ch378" } }

B) Subsequently, the client app establishes an active session, providing the callback for the previously created notification channel.

POST /session { "deviceId": "string", "notificationChannel": { "callbackURL": "http://example.com/callBackUrl/cbu112" } }

HTTP/1.1 201 Created { "clientId": "string", "resourceURL": "string" }

The WebRTC GW posts client notifications using the callbackURL. By adopting this framework, the WebRTC GW is relieved from managing the intricacies of different notification channels. However, we need to consider cases where clients utilize multiple channels, such as a PNS channel for initial notification and a WebSocket channel for subsequent notifications.

We have two options to address this: (A) Implement a combined channel for PNS + WebSocket, where the channel itself manages the logic to send notifications through the appropriate channel. (B) Utilize multiple channels alongside a subscription model, where the client subscribes to specific events over each channel. We recommend option A.

[pradeepachar-mavenir]

@pradeepachar-mavenir We should eliminate the use of userId within the CallHandling APIs, as users can be identified through the access/identification token.

Additionally, we should consider removing the responseCode from SessionInvitationNotification, SessionStatusNotification, and ReceiverStatusNotification. This information is redundant and could cause confusion for developers using the endpoints.

[pradeepachar-mavenir]

Closed with unmerged commits

[deepakjaiswal1]

@pradeepachar-mavenir Appreciate the updated YAML files. The NotificationChannel schema lacks the necessary callbackURL for posting notifications on the channel. Could we include the callbackURL in the notification channel schema?

[pradeepachar-mavenir]

@pradeepachar-mavenir Appreciate the updated YAML files. The NotificationChannel schema lacks the necessary callbackURL for posting notifications on the channel. Could we include the callbackURL in the notification channel schema?

@deepakjaiswal1 In the RACM API, a new element notificationUri is added. The clients are expected to establish the notification channel with the notification server and include the callback uri provided by notification server in the notificationUri attribute.

[deepakjaiswal1]

@pradeepachar-mavenir We're good with the RACM API, and our feedback was regarding the Notification Channel API. The schema for the NotificationChannel, returned in the response body of the POST /channels request, should contain the callbackURL. This inclusion ensures that the implementation of notification channels outside of the WebRTC Gateway aligns with CAMARA specifications.