pub struct ChangeSet<'a> { /* private fields */ }
Expand description
Changes to apply to the m-lines of the WebRTC session.
Get this by calling Rtc::create_change_set
.
No changes are made without calling ChangeSet::apply()
, followed by sending
the offer to the remote peer, receiving an answer and completing the changes using
Rtc::pending_changes()
.
Implementations§
source§impl<'a> ChangeSet<'a>
impl<'a> ChangeSet<'a>
sourcepub fn has_changes(&self) -> bool
pub fn has_changes(&self) -> bool
Test if this change set has any changes.
let mut rtc = Rtc::new();
let mut changes = rtc.create_change_set();
assert!(!changes.has_changes());
let mid = changes.add_media(MediaKind::Audio, Direction::SendRecv, None);
assert!(changes.has_changes());
sourcepub fn add_media(
&mut self,
kind: MediaKind,
dir: Direction,
cname: Option<String>
) -> Mid
pub fn add_media(
&mut self,
kind: MediaKind,
dir: Direction,
cname: Option<String>
) -> Mid
Add audio or video media and get the mid
that will be used.
Each call will result in a new m-line in the offer identifed by the Mid
.
The mid is not valid to use until the SDP offer-answer dance is complete and
the mid been advertised via Event::MediaAdded
.
let mut rtc = Rtc::new();
let mut changes = rtc.create_change_set();
let mid = changes.add_media(MediaKind::Audio, Direction::SendRecv, None);
sourcepub fn set_direction(&mut self, mid: Mid, dir: Direction)
pub fn set_direction(&mut self, mid: Mid, dir: Direction)
Change the direction of an already existing m-line.
All media m-line have a direction. The media can be added by this side via
ChangeSet::add_media()
or by the remote peer. Either way, the direction
of the line can be changed at any time.
It’s possible to set the direction Direction::Inactive
for media that
will not be used by the session anymore.
If the direction is set for media that doesn’t exist, or if the direction is
the same that’s already set ChangeSet::apply()
not require a negotiation.
sourcepub fn add_channel(&mut self, label: String) -> ChannelId
pub fn add_channel(&mut self, label: String) -> ChannelId
Add a new data channel and get the id
that will be used.
The first ever data channel added to a WebRTC session results in an m-line of a special “application” type in the SDP. The m-line is for a SCTP association over DTLS, and all data channels are multiplexed over this single association.
That means only the first ever add_channel
will result in an Offer
.
Consecutive channels will be opened without needing a negotiation.
The label is used to identify the data channel to the remote peer. This is mostly useful whe multiple channels are in use at the same time.
let mut rtc = Rtc::new();
let mut changes = rtc.create_change_set();
let cid = changes.add_channel("my special channel".to_string());
sourcepub fn apply(self) -> Option<Offer>
pub fn apply(self) -> Option<Offer>
Attempt to apply the changes made in the change set. If this returns Offer
, the caller
the changes are not happening straight away, and the caller is expected to do a negotiation
with the remote peer and apply the answer using
Rtc::pending_changes()
.
In case this returns None
, there either were no changes, or the changes could be applied
without doing a negotiation. Specifically for additional ChangeSet::add_channel()
after the first, there is no negotiation needed.
let mut rtc = Rtc::new();
let changes = rtc.create_change_set();
assert_eq!(changes.apply(), None);