Branded Calls impact in WebRTC API

[jgarciahospital]

Problem description

Based on API backlog request https://github.com/camaraproject/APIBacklog/issues/35

We'd like to know the feedback from WebRTC subproject, to ensure that the API is aligned or not, overlapping or not with current WebRTC definitions.

Expected action

Feedback from WebRTC subgroup about the API proposal described in https://github.com/camaraproject/APIBacklog/issues/35

Additional context

• https://github.com/camaraproject/APIBacklog/pull/31/files?short_path=08ff391#diff-08ff391d7d086ce1f96b0e66b5f2b79ce51f6071984d87d75a538999ecf2dcdc
• https://www.gsma.com/get-involved/gsma-foundry/5g-new-calling/
• https://membergateway.sharepoint.com/sites/cg-5GNCTF/MeetingDocuments/Forms/AllItems.aspx?csf=1&web=1&e=1hVuvO&CID=de7eb239%2D629c%2D46cb%2D8c07%2D36238e21855c&FolderCTID=0x012000C1734E61FA5E7F44ADC92440D8D4E1D4&id=%2Fsites%2Fcg%2D5GNCTF%2FMeetingDocuments%2F5GNCTF%20Meeting%231

[stroncoso-quobis]

Hi @jgarciahospital ,

I was discussing this topic with @deepakjaiswal1 during the last work group meeting

• https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14564610/WebRTC+2024+Minutes

As part of the SDP negotiation, the datachannel is something inherent to the WebRTC session negotiation, so the POST /session endpoint will include the ability to add a datachannel connection included at the embedded SDP. The whole concept is that a voice / video / data negotiation is considered part of the same session, same negotiation, we consider that we should not split it on a different API.

In any WebRTC-to-WebRTC use case, the negotiation using our API should include extra information for session context for spam prevention and improved promotion calls (branded company calls with summary or even with presentation logos). Other use cases like interactive navigation of presentation control (BFCP) covered using datachannels seems a natural part of the WebRTC API. In any of these cases, yes, branded and interactive calls will be covered.

There is a corner case, the legacy SIP integration: The WebRTC gateway must grant a way to interact with this datachannel as it provides a way to interact with aduio/video vía SIP. Currently, we cover this JSON to SIP translation for audio/video, so it must cover somehow an exposition of the datachannel (i.e.: live subs). In this case, does it make sense in a complete new, different API? Does it justify a different working group? We are not sure. Maybe it can be handled by the SIP server on the other side, or just with an extra endpoint inside the WebRTC API? It should be simpler and consistent. A dedicated endpoint for NewCalling inside the WebRTC API makes more sense to us.

Anyway, it will be great if you can join the next group meeting (Tuesday 4th 3pm UTC), expose the case, and we can discuss it a little further.

Best regards,

[stroncoso-quobis]

Hi @jgarciahospital ,

We are wondering if you receive our feedback, if you can confirm, or you want to add extra comments here. We are happy to discuss any extra topic or comment that you share.

If no news, we will close this issue during next working group meeting.

Regards,