algesten
Allow more control over SDP negotiation
I'm writing a service where I want to ahead of time accept/reject an SDP offer (specifically for a WHIP like scenario). My service for example accepts one, and only exactly one audio media. Arguably SDP is a bad choice to begin with here, but its sadly still the standard and as such I need to support it.
Right now str0m doesn't really seem to expose the ability to introspect the SDP ahead of time (#385 all over again?) - in my case rejecting an SDP offer would result in a HTTP 400 response on the WHIP offer endpoint. I could now move to the direct API, but str0m already does an excellent job at SDP negotiation and handling all the weirdness.
The MediaAdded event is too late, since at this point I already have accepted a for my use case non-sensible SDP.
So you want access to the Sdp struct before you apply it and you don't want to munge the string?
Effectively yes - the only other reasonably working SDP implementation is from the webrtc-rs crate, however, that would mean parsing the SDP twice and I also find str0m's implementation cleaner.
In fact I would even like to have str0m's SDP implementation as a totally separate crate, but the API being public would suffice my use case for now.
Another alternative would be adding a WHIP, WHEP APIs where you provide your sdp and some whip/whep config and str0m does the check for you. (But I don't know how complicated WHIP/WHEP is)
But yeah, we will see what @algesten says :)
WHIP/WHEP API might work, what I'm looking for is a way to restrict which media line combinations/counts are accepted. My reason for simply making the SDP API public is that attempting to provide an API which is flexible enough and covers all use cases sounds nearly impossible, while giving access to the SDP allows the application developer to put that logic application side.
@Janrupf what level of introspection are you looking for?
At the lowest level we of course have the parser creating the SDP struct, understanding stuff like the MediaAttributes and how they affect the m-line is in my head the semantic level.
In some respects you always need to get to that semantic level for the SDP to be useful. Especially stuff like what's detailed in our SDP note. This level could made in code, but right now we go straight modifying the session.
Regarding exposing the SDP API, I'm a bit weary of increasing the API surface that we maintain. We could potentially release it in a similar way I got "unversioned" API in ureq – this means the API is there without guarantees. It might break without major version release.
Right now my logic checks these conditions:
- offer SDP has exactly 2 media lines
- of these 2 media lines:
- 1 is of type application
- 1 is of type audio
- both of them are sendrecv
If the checks succeed, the SDP offer is accepted and the MID's are extracted from it, then saved for later use.
I think the checks are somewhat simple in this case and could probably be expressed using constraints, but in reality they may evolve and potentially make str0m chase an ever increasing complexity - I'm rather worried that the level of introspection gets deeper and deeper, leading back to needing to inspect the SDP again. Personally I would be fine with an "unversioned" API
As an example, my service could in theory also accept 2 audio media lines - one for sending, one for receiving. The service doesn't care as long as it can send and receive audio (and data via data channels). Adding an API to str0m for expressing such constraints sounds like a complexity nightmare
@Janrupf See #718 – we could have a follow-up PR that exposes the SDP API you want access to under the unversioned module.