-
Notifications
You must be signed in to change notification settings - Fork 14
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
Conversation
lib/ex_webrtc/peer_connection.ex
Outdated
answer = | ||
case ExSDP.get_attribute(remote_offer, :ice_options) do | ||
{:ice_options, "trickle"} = attr -> ExSDP.add_attribute(answer, attr) | ||
_other -> answer | ||
end |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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:
- remote sends to us two tracks
- 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 oneinactive
, the second onerecvonly
from local perspective) and one transceiver. - 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.
There was a problem hiding this comment.
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.
Codecov ReportAttention:
... and 2 files with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
No description provided.