Commonalities 0.5 aligment

[stroncoso-quobis]

What type of PR is this?

Add one of the following kinds:

• correction
• enhancement/feature

What this PR does / why we need it:

• Align with Commonalities 0.5 for CAMARA APIs

Which issue(s) this PR fixes:

Fixes #63

Special notes for reviewers:

Work in progress

Changelog input

 release-note
- Aligment with Commonalities 0.5 for the three APIs
- Added `openId` as securitySchema.
  - `webrtc-events` already using it. No changes there
  - `webrtc-registration` and `webrtc-call-handling`:
    - remove BearerAuth and leave openId as security schema
    - APIs scope naming review: commit 54d1048
- Review response codes
  - `webrtc-registration`: added x-correlator and API reponses review: commit 66ce28
  - `webrtc-call-handling`: added x-correlator and API reponses review: commit 93e54d8

Additional documentation

docs

[teikuran]

Regarding webrtc-registration, channelId cannot be used because it is assigned through webrtc notification-channel, which is not included in the Spring 25 release.
Therefore, channelId data schema should be removed. I believe this removal will have no impact, as the Spring 25 release relies on the webhook callback method, which does not use the concept of channelId.

channelId:
 type: string  
 description: ID of an existing notification channel.  
 example: "channel_id_123"

[deepakjaiswal1]

I agree; we should remove channelId since the notification channel has been descoped from the current release.

[deepakjaiswal1]

@stroncoso-quobis @teikuran
The deviceId is a unique identifier for the physical device where a WebRTC session is initiated. It is provided by the WebRTC application, it remains consistent across multiple installations or logins on the same device. Its primary function is to ensure that only one WebRTC session is active per device at a time, enabling the gateway to clean up any stale sessions if a new session is initiated on the same device.

The clientId, on the other hand, is assigned by the WebRTC gateway for each client instance or session. It is best practice for the gateway to issue a new clientId for each login or session. This approach helps the gateway maintain clear indexing or mapping for quicker processing and simplifies troubleshooting by clearly distinguishing one session from another.