Handle sending and receiving RTP capabilities separately#359
Closed
6uliver wants to merge 1 commit intoversatica:v3from
Closed
Handle sending and receiving RTP capabilities separately#3596uliver wants to merge 1 commit intoversatica:v3from
6uliver wants to merge 1 commit intoversatica:v3from
Conversation
Member
|
Thanks @6uliver. It looks good but honestly this change is too sensitive and I need to redo it on my own to be sure of what these changes do. Probably I'll end copy&pasting 99% of your PR but I need to do it. Let me please check these changes and work on this these days. |
ibc
added a commit
that referenced
this pull request
Feb 17, 2026
# Details - Fixes #141 - This PR replaces PR #359 but it's basically a copy&paste of it with some minimal cosmetic changes. So absolutely all credits to @6uliver. - Now we generate different RTP capabilities for sending and receiving and the only change in the public API is that `device.rtpCapabilities` getter is now deprecated and instead the app should use `device.recvRtpCapabilities` and `device.sendRtpCapabilities`. # TODO * [ ] In the documentation website, document that `device.rtpCapabilities` getter is now deprecated and instead the app should use `device.recvRtpCapabilities` and `device.sendRtpCapabilities`.
1 task
Member
Author
|
Great, thanks for your quick response! |
ibc
added a commit
that referenced
this pull request
Feb 17, 2026
- Fixes #141 - This PR replaces PR #359 but it's basically a copy&paste of it with some minimal cosmetic changes. So absolutely all credits to @6uliver. - Now we generate different RTP capabilities for sending and receiving and the only change in the public API is that `device.rtpCapabilities` getter is now deprecated and instead the app should use `device.recvRtpCapabilities` and `device.sendRtpCapabilities`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@ibc as you mentioned in this ticket (#141):
"The device can later create send transports and recv transports. There is where we should run different code to get capabilities from a local SDP offer. But unfortunately we don't do that (yet)."
As the library has separate transports we don't need to set the direction in the Device constructor anymore but we can have a direction parameter in the getNativeRtpCapabilities. This will solve the problem mentioned in #141 that our team has as well: if the device can not encode (send) something the library won't detect the capability for decoding (receiving). By setting the direction for the transceivers in the getNativeRtpCapabilities we will get the correct capabilities for sending and receiving which are possibly different.
I tried to keep the public interface backward compatible (rtpCapabilities is doing the same as before but with the fix so it's really the capabilities for receiving media) and extend it with new functionalities: rtpReceiveCapabilities, rtpSendCapabilities.
The getRecvRtpCapabilities is working as before, I've just refactored it to a helper function and added the new getSendRtpCapabilities.
I hope you like it and can merge as soon as possible. In case you have any requests feel free to ask, I'm more than happy to fix anything related to this problem.