Mid and SSRC setting when adding Media to SdpApi

[evdokimovs]

What you think about adding ability to set mid and ssrc of Media when adding it with SdpApi::add_media? So signature of SdpApi::add_media function will be:

    pub fn add_media(
        &mut self,
        kind: MediaKind,
        dir: Direction,
        stream_id: Option<String>,
        track_id: Option<String>,
        mid: Option<Mid>,
        ssrc: Option<Ssrc>,
    ) -> Mid

Or we can do it even better with builder pattern for creating Media. Something like this:

struct MediaBuilder {
  // ...
}

impl MediaBuilder {
  pub fn new(kind: MediaKind, direction: Direction) -> Self { /* ... */ }
  pub fn ssrc(self, ssrc: Ssrc) -> MediaBuilder { /* ... */ }
  pub fn stream_id(self, ssrc: Ssrc) -> MediaBuilder { /* ... */ }
  pub fn ssrc(self, ssrc: Ssrc) -> MediaBuilder { /* ... */ }
  pub fn track_id(self, ssrc: Ssrc) -> MediaBuilder { /* ... */ }
}

impl SdpApi {
  pub fn add_media_with_builder(&mut self, media_builder: MediaBuilder) -> Mid;
}

Or maybe like this:

struct MediaBuilder {
  // ...
}

impl MediaBuilder {
  pub fn new() -> Self { /* ... */ }
  pub fn ssrc(self, ssrc: Ssrc) -> MediaBuilder { /* ... */ }
  pub fn stream_id(self, ssrc: Ssrc) -> MediaBuilder { /* ... */ }
  pub fn ssrc(self, ssrc: Ssrc) -> MediaBuilder { /* ... */ }
  pub fn track_id(self, ssrc: Ssrc) -> MediaBuilder { /* ... */ }
}

impl SdpApi {
  pub fn add_media_with_builder(
    &mut self,
    kind: MediaKind,
    direction: Direction,
    media_builder: MediaBuilder
  ) -> Mid { /* ... */ }
}

[algesten]

The way I think about this is:

• SDP sucks. It is error prone and fragile. "Perfect negotiation" is trying to shut the stable door after the horse has already bolted.
• Most people approach str0m from an RTCPeerConnection background.
• RTCPeerConnection is a leaky abstraction. It tries to be high and low level at the same time.
• However RTCPeerConnection API almost doesn't expose SSRC, and mid is read only.
• Specifically the user of RTCPeerConnection cannot set SSRC or mid.

The idea is that str0m's SDP API should roughly give you the same control that RTCPeerConnection does. If RTCPeerConnection lets you do it, str0m SDP API will let you do it (we're still missing stuff). For SDP, this would be a "safe" set of operations. With "safe" we means things that can't fail if you use the API correctly, and preferably the API doesn't even let you fail.

Setting SSRC or mid are not safe operations. They can both clash with existing IDs in the session, and thus must be picked carefully. Needing direct control over SSRC and mid is possible in the Direct API, but then str0m will not provide an SDP.

The combination of unsafe operations over SDP is not a space str0m is currently aiming at. Not saying it's ruled out for all future, but I would want more evidence this would actually be used. Adding comments to this issue would help me gauge that.