Code change:
clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage: <del> Bothe the WHIP client and the media server SHALL use SDP bundle RFC8843.  The SDP offer created by the WHIP client must include the bundle-only attribute in all m-lines as per RFC8843.  Also, RTCP muxing SHALL be supported by both the WHIP client and the media server. </del> <ins> Both the the WHIP client and the WHIP endpoint SHALL use SDP bundle RFC8843.  Each "m=" section MUST be part of a single BUNDLE group. Hence, when a WHIP client sends an SDP offer, it MUST include a "bundle-only" attribute in each bundled "m=" section.  The WHIP client and the Media Server MUST support multiplexed media associated with the BUNDLE group as per RFC8843 section 9.  In addition, per RFC8843 the WHIP client and Media Server will use RTP/RTCP multiplexing for all bundled media.  The WHIP client and media server SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections. </ins> When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in

Related discussion:
text: We've already found out that Tim always sends passive from servers, while Janus always sends active when it receives an offer: this means that whatever you force on the WHIP client will break one of the two servers. I think clients should send actpass as the RFC says.
Mandating clients to implement both active and passive is a no go for me. The goal has always been to reduce the burden on the clients because there was none available. Increasing the complexity of implementing them is not going to help.
btw, I think that Tim is referring that his servers respond as passive, while their clients sends active. So his (whip) clients would be able to talk with janus server, which is what we intended.
No, they wouldn't, because Janus expects actpass when it receives an offer, and will set the role of active for itself. Two actives won't get anywhere.
When you say 'clients', what exactly are you referring to? The WebRTC library that you are using in the application?
No, I am referring to the WHIP clients
Imagine I have a smart camera acting as a WHIP source which can only do Active DTLS (because of a hardware limitation). Let's assume when it tries to talk to Janus it will fail because Janus will only do active. If the camera signals this in it's WHIP offer with setup:active then the O/A fails early with a sensible error message http status:402 If it sends a (mendacious) setup:actpass then the connection will silently fail after ice connects and a 16 second DTLS timeout. So sending setup:active in the offer is the right thing for the camera to do. The other option is to say that such hardware shouldn't be doing WHIP, which seems like a needless limitation on hardware encoder design.
Incidentally I checked my (open source) Whipi client and it actually sends ! Which is why it works with Janus. (The target hardware (raspberry pi) does not have a secure element, so it is just a code size simplification not a hardware limitation - It still halves the complexity of the DTLS layer by only having to implement dtls server)
Back to the High level point.