Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add/refactor set_local_description and create_answer #7

Merged
merged 4 commits into from
Oct 31, 2023
Merged

Conversation

LVala
Copy link
Member

@LVala LVala commented Oct 30, 2023

No description provided.

@LVala LVala requested a review from mickel8 October 30, 2023 12:23
@LVala LVala self-assigned this Oct 30, 2023
Comment on lines 202 to 206
answer =
case ExSDP.get_attribute(remote_offer, :ice_options) do
{:ice_options, "trickle"} = attr -> ExSDP.add_attribute(answer, attr)
_other -> answer
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just FYI we don't support anything other than trickle ice so this attribute has to always be in offer/answer


defp update_local_transceivers(:offer, transceivers, sdp) do
sdp.media
|> Enum.zip(transceivers)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am really not sure about zipping those two lists. We can discuss this offline but consider the following scenario:

  1. remote sends to us two tracks
  2. at some point, remote stops one track - the first one in SDP. In such the case we should probably delete our first transceiver as it will be marked as stopped. We will have two mlines (the first one inactive, the second one recvonly from local perspective) and one transceiver.
  3. If at this point, we decide to add a track on local side, we will add a new transceiver that will correspond to the first mline (which will be recycled). So we will end up with two transceivers and two mlines but the first transceiver will correspond to the second mline and the second transceiver will correspond to the first mline.

Does it make sense?

That's why I didn't decide to zip those two lists in RTPTransceiver.update_or_create.

We can also merge this as is and go back to the problem once it appears i.e. when we support track removal or stopping transceivers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applying the local offer is the moment when mids are assigned to the transceivers, so if we want to prevent the issues that you have mentioned (so basically order of transceivers != order of mlines) we would need to map mline <-> transceiver in some other way (keep the mline index in transceiver state?).

For now I would probably leave it as it is, as that a bigger issue.

Also there's question: what if I create an offer, remove a transceiver and then apply the offer? Should it fail? Will need to take care of such cases in the near future probably.

@LVala LVala requested a review from mickel8 October 31, 2023 08:00
@codecov
Copy link

codecov bot commented Oct 31, 2023

Codecov Report

Attention: 7 lines in your changes are missing coverage. Please review.

Files Coverage Δ
lib/ex_webrtc/peer_connection.ex 70.00% <100.00%> (+45.16%) ⬆️
lib/ex_webrtc/session_description.ex 0.00% <0.00%> (ø)
lib/ex_webrtc/sdp_utils.ex 82.66% <70.00%> (-4.61%) ⬇️

... and 2 files with indirect coverage changes

📢 Thoughts on this report? Let us know!.

@LVala LVala merged commit 56d1d12 into master Oct 31, 2023
4 checks passed
@LVala LVala deleted the set-local-desc branch October 31, 2023 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants