From 9f0044a9debf8b67e2b9424a75bfa9b0b8fb4434 Mon Sep 17 00:00:00 2001 From: Santiago Troncoso Date: Sat, 10 Oct 2026 09:07:31 +0200 Subject: [PATCH] fix: r3.x Documentation review - Inline documentation examples and definitions - READMEs and links review - Supporting docs disclaimers --- README.md | 1 - code/API_definitions/README.MD | 47 -------------- .../API_definitions/webrtc-call-handling.yaml | 55 ++++++---------- .../webrtc-events-subscriptions.yaml | 64 +++++++++---------- code/API_definitions/webrtc-registration.yaml | 26 +++++--- code/Test_definitions/README.md | 25 +------- documentation/MeetingMinutes/README.md | 4 +- documentation/README.md | 14 ++-- documentation/SupportingDocuments/README.md | 14 ++-- .../uml-diagrams/README.md | 6 +- .../SupportingDocuments/webrtc voice api.md | 2 + 11 files changed, 91 insertions(+), 167 deletions(-) delete mode 100644 code/API_definitions/README.MD diff --git a/README.md b/README.md index 916334a..0765e1c 100644 --- a/README.md +++ b/README.md @@ -61,7 +61,6 @@ _The above section is automatically synchronized by CAMARA project-administratio * Find API reference documentation at folder: [code/API_definitions](code/API_definitions/) * Find API testing documentation at folder: [code/Test_definitions](code/Test_definitions/) -* Find release status documentation at folder: [documentation/API_documentation](documentation/API_documentation) * Find UML and complementary documentation at folder: [documentation/SupportingDocuments](documentation/SupportingDocuments) * For other information refer to [Confluence CAMARA project wiki](https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14560817/WebRTC) diff --git a/code/API_definitions/README.MD b/code/API_definitions/README.MD deleted file mode 100644 index e1c2d5a..0000000 --- a/code/API_definitions/README.MD +++ /dev/null @@ -1,47 +0,0 @@ -# WebRTC APIs definitions - -This folder contain the OpenAPI definitions of the WebRTC subgroup - -## APIs included - -* `webrtc-registration` [Registration and Authentication management](webrtc-registration.yaml) - * This API definition provides functionality for a REST client, browser or native application to manage Registration and Connectivity (RACM) towards Internet Multimedia Subsystem (IMS) Network. - * [View main on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/WebRTC/main/code/API_definitions/webrtc-registration.yaml&nocors) - * [View main on Swagger Editor](https://camaraproject.github.io/swagger-ui/?url=https://raw.githubusercontent.com/camaraproject/WebRTC/main/code/API_definitions/webrtc-registration.yaml) - -* `webrtc-call-handling` [Call handling service](webrtc-call-handling.yaml) - * This API definition provides functionality for REST clients, browser or native application, to create and manage 1-1 calling. Both incoming and outgoing. - * [View main on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/WebRTC/main/code/API_definitions/webrtc-call-handling.yaml&nocors) - * [View main on Swagger Editor](https://camaraproject.github.io/swagger-ui/?url=https://raw.githubusercontent.com/camaraproject/WebRTC/main/code/API_definitions/webrtc-call-handling.yaml) - -* `webrtc-events` [WebRTC Event Subscription](webrtc-events.yaml) - * This API definition provides functionality for REST clients, browser or native application, to track session events. This will allow the client to receive server side updates about new incoming calls and other needed updates regarding the media negotiation and session progress (ringing, hangup, etc). - * [View main on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/WebRTC/main/code/API_definitions/webrtc-events.yaml&nocors) - * [View main on Swagger Editor](https://camaraproject.github.io/swagger-ui/?url=https://raw.githubusercontent.com/camaraproject/WebRTC/main/code/API_definitions/webrtc-events.yaml) - -Detailed descriptions, diagrams and more information could be found at [API documentation](../../documentation/API_documentation/) section - -## Check APIs online - -Use the previous links to check the DEV main version of the API. Copy & paste any raw file to check them: - -* ReDoc: https://redocly.github.io/redoc/ -* Swagger: https://editor.swagger.io/ -* CAMARA dedicated swagger instance: https://camaraproject.github.io/swagger-ui/ - - -## Build HTML from sources - -Build an HTML from sources using a local build OpenAPI v3 compatible like Node `redocly/cli` - -Execute redocly for each API document, use -o to -``` -$ npx @redocly/cli build-docs API_description_file.yaml -``` - -Or install the tool globaly and then build it -``` -$ npm install @redocly/cli -g - -$ redocly build-docs API_description_file.yaml -``` \ No newline at end of file diff --git a/code/API_definitions/webrtc-call-handling.yaml b/code/API_definitions/webrtc-call-handling.yaml index c1d5f04..22795db 100644 --- a/code/API_definitions/webrtc-call-handling.yaml +++ b/code/API_definitions/webrtc-call-handling.yaml @@ -84,39 +84,20 @@ info: You must check the webrtc-registration API to retrieve a valid registration on the network that allows you to send calls (IMS registration). - Once this is completed, you can consume the POST /sessions/ endpoint to call - a remote destination. + Once this is completed, you can consume the `POST /sessions` endpoint to call + a remote destination. The request MUST include the local SDP `offer`. - ``` - POST /webrtc-call-handling/v0.2/sessions - { - "originatorAddress": "tel:+17085852753", - "receiverAddress": "tel:+17085854000", - } - ``` - - This will create a call, but without local media you will have a problem, or - maybe the network will reject your call. You need to add a local SDP offer. - - > **The WebRTC SDP local candidate** + > **The WebRTC SDP local offer** > - > What is usually done, before attempt to create a call, is to solve the SDP local - description. This is, how you are going to send the media. To explain it briefly, - browsers offer the - [WebRTC API](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API) that - include `getUserMedia()` and `RTCPeerConnection` interfaces that will simplify - the process. - > - > In summary, we need to obtain the media, create the `RTCPeerConnection` - and use it's SDP on our CAMARA webrtc-call-handling API as the offer. There - is extra information about this concept on the SupportingDocuments folder. - - Once you retrieve you local SDP offer, you modify your session including it, - or maybe you prefer to solve the local candidate before attempt the call, in - that case, you will include your local offer on the audio/video session creation. + > Before creating a call, the client obtains its local SDP description, which + > describes how it is going to send the media. Browsers offer the + > [WebRTC API](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API), + > including the `getUserMedia()` and `RTCPeerConnection` interfaces, to obtain + > the media and create the SDP offer. Extra information about this concept is + > available in the SupportingDocuments folder. ``` - POST /webrtc-call-handling/v0.2/sessions + POST /sessions { "originatorAddress": "tel:+17085852753", "receiverAddress": "tel:+17085854000", @@ -127,10 +108,10 @@ info: ``` Following this point, your call is progressing and the network will inform - about extra information required and connection status via de the + about extra information required and connection status via the webrtc-events-subscriptions API. - Check webrtc-events-subscriptions API inline documentation and supporting documents + Check webrtc-events-subscriptions API inline documentation and Supporting Documents for further information. ## 2. Hanging up a call @@ -152,15 +133,14 @@ info: using the GET request, afterwards, you can present to the user some confirmation option to accept the call. - Final step is to include a local offer. We already seen at 3.1 that a local - SDP is required, in this case, we will use the PUT request to modify the - audio/video session and include the information about the responding device. + Final step is to accept the call with the local SDP `answer`, using the PUT + request with status `Connected`. Let's say that we are responding this session `0AEE1B58BAEEDA3EABA42B32EBB3DFE0DEAD`: ``` - PUT /webrtc-call-handling/v0.2/sessions/0AEE1B58BAEEDA3EABA42B32EBB3DFE0DEAD/status + PUT /sessions/0AEE1B58BAEEDA3EABA42B32EBB3DFE0DEAD/status { - "status": "InProgress", + "status": "Connected", "answer": { "sdp": "v=0\r\no=- 4808447918291752114 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0\r\na=extmap-allow-mixed\r\nm=audio 13765 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126\r\nc=IN IP4 123.123.123.123\r\na=ice-ufrag:YoUo\r\na=ice-pwd:kK5J6IAgiKFDFU+2rC+FyZal\r\n...\r\n" } @@ -168,6 +148,7 @@ info: ``` + # Additional CAMARA error responses The list of error codes in this API specification is not exhaustive. Therefore the API specification MAY not document some non-mandatory error statuses as indicated in `CAMARA API Design Guide`. @@ -178,6 +159,7 @@ info: + # Request body strictness This API rejects requests with JSON request bodies that contain properties not declared in this specification, at any nesting level. Unknown properties result in a `400 INVALID_ARGUMENT` response. @@ -209,6 +191,7 @@ info: - If `callType` is omitted, it defaults to `REGULAR`. + # Authorization and authentication The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile. diff --git a/code/API_definitions/webrtc-events-subscriptions.yaml b/code/API_definitions/webrtc-events-subscriptions.yaml index 678f796..2d20d99 100644 --- a/code/API_definitions/webrtc-events-subscriptions.yaml +++ b/code/API_definitions/webrtc-events-subscriptions.yaml @@ -4,22 +4,22 @@ info: description: |- # Introduction - This API provide REST API for a client, browser or native application, to - receive events about updates of an active session or new sessions requests - (incoming calls) or registration termination. + The WebRTC Events Subscriptions API lets a client, browser or native + application, receive events about active session updates, new session + requests (incoming calls) and registration termination. - This API allows a WebRTC client to subscribe to events associated with a specific device, - identified by its `deviceId`. The deviceId uniquely represents a physical device on which - registrations and sessions may occur. + Subscriptions are bound to a specific device, identified by its `deviceId`, + which represents a unique physical device on which registrations and + sessions may occur. Instead of requiring separate subscriptions per registration (`registrationId`) or per session - (`mediaSessionId`), event delivery is consolidated under the deviceId. This enables the client to - receive all relevant notifications — such as new call invitations or session status updates — + (`mediaSessionId`), event delivery is consolidated under the `deviceId`, so the client + receives all relevant notifications — such as new call invitations or session status updates — for any registration or session belonging to the same device. - This allows the device applications to update the UI while media sessions - are progressing and also, allows the device to receive new session request, - generating incoming call scenarios for non-SIM devices. + As a result, device applications can update the UI while media sessions + progress, and receive new session requests, enabling incoming calls on + non-SIM devices. A classic use case is the negotiation of a live media session (call), that requires multiple asynchronous events from server side. Other classic @@ -62,7 +62,7 @@ info: The CAMARA subscription model is detailed in the CAMARA API design guideline document and follows CloudEvents specification. - This API allows to create an explicit notification channel for two types of + This API allows to create an explicit notification channel for three types of events. It is mandatory in the subscription to provide the event type for which the client would like to subscribe. @@ -103,7 +103,7 @@ info: A `org.camaraproject.webrtc-events-subscriptions.v0.session-status` event includes session information updates. With the same schema that is used with the WebRTC Call Handling API, when retrieving information from the - `GET /webrtc-call-handling/session/{mediaSessionId}` endpoint. + `GET /webrtc-call-handling/sessions/{mediaSessionId}` endpoint. In general lines, it is emitted each time that an event happens within the subscribed session. This might happen when SDP updates are included for any @@ -169,6 +169,7 @@ info: From a developer's point of view, reception of the `registration-ends` event should be treated as a signal to renew the WebRTC registration in order to continue receiving or initiating calls for the registered phone number. + # Authorization and authentication The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile. @@ -179,6 +180,7 @@ info: + # Additional CAMARA error responses The list of error codes in this API specification is not exhaustive. Therefore the API specification MAY not document some non-mandatory error statuses as indicated in `CAMARA API Design Guide`. @@ -189,6 +191,7 @@ info: + # Request body strictness This API rejects requests with JSON request bodies that contain properties not declared in this specification, at any nesting level. Unknown properties result in a `400 INVALID_ARGUMENT` response. @@ -1591,10 +1594,11 @@ components: # Subscription examples REGISTRATION_ENDS_SUBSCRIPTION: description: |- - A sample of `registration-ends` subscription for registrationId - `+xsmcaum3z4zw4l0cu4w115m0` at `acme.opentelco.com`. + A sample of `registration-ends` subscription for a `deviceId` at + `acme.opentelco.com`. This will be used to receive WebRTC registration termination events + for any registration of the device. value: protocol: HTTP sink: https://notificationServer.opentelco.com @@ -1610,20 +1614,16 @@ components: deviceId: "7d444840-9dc0-11d1-b245-5ffdce74fad2" INVITE_SUBSCRIPTION: description: |- - A sample of media `session-invitation` subscription for phone number - `+1234567890` at `acme.opentelco.com`. + A sample of media `session-invitation` subscription for a `deviceId` + at `acme.opentelco.com`. - This will be used to receive incoming sessions (incoming - calls). The implicit subscription to `subscription-ended` will make - the client aware of registration status updates from the server. - (i.e. when a REGISTRATION expires). + This will be used to receive incoming sessions (incoming calls) for + any registration of the device. Registration termination is notified + through the `registration-ends` event type, which requires its own + subscription. The example uses `sinkCredential` for authenticated event delivery and - a `subscriptionExpireTime` to control the subscription lifetime. Check - callback examples to check some possible events received: - - - New incoming call - - Registration revoked + a `subscriptionExpireTime` to control the subscription lifetime. value: protocol: HTTP sink: https://notificationServer.opentelco.com @@ -1640,11 +1640,11 @@ components: subscriptionExpireTime: "2024-11-17T13:18:23.682Z" SESSION_SUBSCRIPTION: description: |- - A sample of media `session-status` subscription for a specific - `mediaSessionId` at `acme.opentelco.com`. + A sample of media `session-status` subscription for a `deviceId` at + `acme.opentelco.com`. - Identified by for `mediaSessionId`, and validated via a `registrationId` - the endpoint is able to interact with its own media session. + This will be used to receive status updates of any media session of the + device, identified in each event by its `mediaSessionId`. This could be used to remotely control the call or to handle the async session establishment. For instance, updating the user interface for different statuses: InProgress, Ringing, Cancel, etc. @@ -1770,8 +1770,8 @@ components: When a re-registration is requested from server, maybe due to expire or administrative token revocation or due any other technical reason. It is expected from the endpoint to re-register. No new sessions will be - delivered to the user endpoint, as the subscription is not valid - anymore. + delivered to the user endpoint until it re-registers. Event + subscriptions are bound to the `deviceId` and remain active. Here, an example of how the network will communicate to the client that the registration is not valid anymore, detailing on diff --git a/code/API_definitions/webrtc-registration.yaml b/code/API_definitions/webrtc-registration.yaml index d106abd..75b2f00 100644 --- a/code/API_definitions/webrtc-registration.yaml +++ b/code/API_definitions/webrtc-registration.yaml @@ -88,6 +88,7 @@ info: - Event subscriptions created via webrtc-events-subscriptions API are not affected. + # Authorization and authentication The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile. @@ -98,6 +99,7 @@ info: + # Additional CAMARA error responses The list of error codes in this API specification is not exhaustive. Therefore the API specification MAY not document some non-mandatory error statuses as indicated in `CAMARA API Design Guide`. @@ -108,6 +110,7 @@ info: + # Request body strictness This API rejects requests with JSON request bodies that contain properties not declared in this specification, at any nesting level. Unknown properties result in a `400 INVALID_ARGUMENT` response. @@ -163,8 +166,8 @@ paths: in: query required: true description: |- - The deviceId of the client in UUID format. Only registrations - associated with this deviceId will be returned. + The `deviceId` of the client in UUID format. Only registrations + associated with this `deviceId` will be returned. schema: type: string format: uuid @@ -175,7 +178,7 @@ paths: responses: '200': description: |- - List of active registrations for the given deviceId. + List of active registrations for the given `deviceId`. Returns an empty array if no active registrations exist. headers: x-correlator: @@ -365,8 +368,11 @@ paths: remaining = t_prev - t_req (values ≤ 0 indicate the client is late; operators MAY reject or treat it as a new registration). - 3. Apply the operator's configured TTL (`TTL_cfg`, e.g. 3600 s) **from - `t_req`, not from `t_prev`**: + 3. Compute the new expiry **from `t_req`, not from `t_prev`**: + - if the request includes `registrationExpireTime`, apply it as + described in that field (capped at the operator's maximum, or + rejected below the operator's minimum); + - otherwise apply the operator's configured TTL (`TTL_cfg`, e.g. 3600 s): newExpire = t_req + TTL_cfg 4. Persist `newExpire` and return it in `expiresAt` inside the response body. @@ -485,7 +491,7 @@ components: format: uuid maxLength: 36 description: |- - The deviceId of the client in UUID format. A unique identifier for + The `deviceId` 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. phoneNumber: @@ -533,6 +539,9 @@ components: and initiate a refresh *before* `ttl` elapses (a safety margin of ~120 s is recommended). + ▸ The operator's allowed minimum and maximum are durations relative + to the server-side receipt time of the request. + ▸ If the client includes a value exceeding the operator's allowed maximum, the server caps the value and returns the authoritative expiry in `expiresAt`. @@ -583,6 +592,9 @@ components: Optional **absolute** UTC timestamp that *requests* a new expiry. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must include a time offset. + The operator's allowed minimum and maximum are durations relative + to the server-side receipt time of the request. + If the client includes a value exceeding the operator's allowed maximum, the server caps the value and returns the authoritative expiry in `expiresAt`. @@ -595,8 +607,6 @@ components: If the client omits this field, the server extends the expiry according to its own TTL policy and returns the authoritative expiry in `expiresAt`. - - It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. RegistrationStatus: description: Current registration status of the WebRTC device type: string diff --git a/code/Test_definitions/README.md b/code/Test_definitions/README.md index b1f4f9e..80d6bd3 100644 --- a/code/Test_definitions/README.md +++ b/code/Test_definitions/README.md @@ -1,24 +1 @@ -This directory contains the `.feature` files with test definitions for the 3 repository API(s). -There is a separate Feature file per API operation. - -The test plan has to be enhanced - -WebRTC Registration - -* webrtc-registration-createRegistration.feature -* webrtc-registration-updateRegistrationById.feature -* webrtc-registration-deleteRegistrationById.feature - -WebRTC Call Handling - -* webrtc-call-handling-createSession.feature -* webrtc-call-handling-getSessionDetailsById.feature -* webrtc-call-handling-deleteSessionById.feature -* webrtc-call-handling-updateSessionStatus.feature - -WebRTC Events Subscriptions - -* webrtc-events-subscriptions-createNotificationChannelSubscription.feature -* webrtc-events-subscriptions-retrieveNotificationChannelSubscriptionList.feature -* webrtc-events-subscriptions-retrieveNotificationChannelSubscription.feature -* webrtc-events-subscriptions-deleteNotificationChannelSubscription.feature +This directory contains the `.feature` files with the test definitions for the 3 repository APIs, one file per API operation. diff --git a/documentation/MeetingMinutes/README.md b/documentation/MeetingMinutes/README.md index 5bde81e..eef91ac 100644 --- a/documentation/MeetingMinutes/README.md +++ b/documentation/MeetingMinutes/README.md @@ -1,5 +1,3 @@ # Meeting notes -These meetings notes are stored her for archive purposes, find updated Meeting notes at CAMARA main Wiki website - -* https://wiki.camaraproject.org/display/CAM/WebRTC+Meeting+Minutes +These meeting notes are stored here for archive purposes. Find the current meeting notes at the [CAMARA wiki](https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14564608/Minutes+-+WebRTC). diff --git a/documentation/README.md b/documentation/README.md index dee80b0..c683054 100644 --- a/documentation/README.md +++ b/documentation/README.md @@ -1,13 +1,9 @@ # Documentation -This folder include extra documentation about the API beyond the technical OpenAPI v3 API description of the `code` folder - -* [MeetingMinutes](MeetingMinutes/) - * Check this folder for the original meeting minutes. - * Newer meeting minutes can be found at [CAMARA Wiki](https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14564608/WebRTC+Meeting+Minutes) - -* [API_documentation](API_documentation/) - * Check this folder for release status documentation. +This folder includes documentation about the APIs beyond the inline documentation of the OpenAPI definitions in the `code` folder. * [SupportingDocuments](SupportingDocuments/) - * Check this folder for extra documentation to support the API definition, UML activity diagrams, API overview description, how to use guides, and other documentation related.. + * UML diagrams, call flows, user stories and other documentation supporting the API definitions. + +* [MeetingMinutes](MeetingMinutes/) + * Archive of the original meeting minutes. Newer meeting minutes are available at the [CAMARA wiki](https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14564608/Minutes+-+WebRTC). diff --git a/documentation/SupportingDocuments/README.md b/documentation/SupportingDocuments/README.md index 8b478fa..e2b002c 100644 --- a/documentation/SupportingDocuments/README.md +++ b/documentation/SupportingDocuments/README.md @@ -1,12 +1,18 @@ # Supporting documents -This folder include documentation to support the API definition, API overview description, how to use guides, and other documentation related with the OpenAPI v3 specs of the `API_definitions` folder. +The API definitions in [`code/API_definitions`](../../code/API_definitions/) are the authoritative source of truth, and their inline documentation is the closest description of them. The documents in this folder are supporting material, with longer explanations and developer guidance. * [UML diagrams](uml-diagrams/) - * Check the UML diagrams included for the documented use cases. They include UML activity diagrams that depict a detailed interaction between apps, WebRTC GW and IMS network. + * UML activity diagrams of the main use cases, depicting the interaction between apps, WebRTC GW and IMS network. + +* [WebRTC API call flows](uml-diagrams-APIprovider/) + * Example call flows and messages for implementers of a WebRTC Gateway exposing the WebRTC APIs. + +* [WebRTC API user story](WebRTC-API-User-Story_ASP-WebRTCGW.md) + * User story for an Application Service Provider using a WebRTC Gateway. * [WebRTC voice API](webrtc%20voice%20api.md) - * Check this document for introduction to the API, and brief expanation of the API itself, use cases and status descriptions. + * Introduction to the APIs, use cases and status descriptions. * [Obtaining a WebRTC SDP to create calls](webrtc-call-handling-sdp-gathering.md) - * CAMARA `webrtc-call-handling` API requires basic usage of the WebRTC API to create calls. You need to obtain and create an `SDP`(Session Description Protocol) body to use in the call creation. This document review that process. + * How to obtain the `SDP` (Session Description Protocol) body required to create calls with the `webrtc-call-handling` API. diff --git a/documentation/SupportingDocuments/uml-diagrams/README.md b/documentation/SupportingDocuments/uml-diagrams/README.md index 416fb09..f824e28 100644 --- a/documentation/SupportingDocuments/uml-diagrams/README.md +++ b/documentation/SupportingDocuments/uml-diagrams/README.md @@ -1,15 +1,15 @@ # UML diagrams -This folder includes UML files and PNG rederizations of the three main use cases. +This folder includes UML files and PNG renderings of the three main use cases. - [UML diagrams](#uml-diagrams) - - [WebRTC Events sucription](#webrtc-events-sucription) + - [WebRTC Events subscription](#webrtc-events-subscription) - [WebRTC Registration process](#webrtc-registration-process) - [WebRTC Call handling](#webrtc-call-handling) - [Originating use case (create a call)](#originating-use-case-create-a-call) - [Terminating use case (receive a call)](#terminating-use-case-receive-a-call) -## WebRTC Events sucription +## WebRTC Events subscription ![WebRTC EventsSubscription]() diff --git a/documentation/SupportingDocuments/webrtc voice api.md b/documentation/SupportingDocuments/webrtc voice api.md index e448b46..fd161eb 100644 --- a/documentation/SupportingDocuments/webrtc voice api.md +++ b/documentation/SupportingDocuments/webrtc voice api.md @@ -1,3 +1,5 @@ +> **Note:** This document may be outdated. The API definitions in [code/API_definitions](../../code/API_definitions/) and their inline documentation are the source of truth. + # Overview Bring your own number (BYON) service aims to provide consumers with the ability to use their phone number (MSISDN) for outgoing and incoming calls from non-SIM card devices. To access the service, users are required to authenticate using their digital credentials associated with their MNO account, in example their operator app credentials. As registration from a web endpoint is necessary to enable the service on non-SIM card devices.