search

algesten / str0m

A Sans I/O WebRTC implementation in Rust.
MIT License
323 stars 50 forks source link

Rejecting m-lines #188

Open k0nserv opened 1 year ago

k0nserv commented 1 year ago

Related to #187, I noticed that when Str0m doesn't match any codecs for an m-line it still indicates that the m-line is okay to use.

I believe str0m should be rejecting the m-line by setting the port to 0 in the resulting SDP.

This is specified in section 5.3 of JSEP

For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in [RFC3264], Section 6, and further processing for this m= section can be skipped:

  • The associated RtpTransceiver has been stopped.
    • None of the offered media formats are supported and, if applicable, allowed by codec preferences.
    • The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section.
    • The bundle policy is "balanced", and this is not the first m= section for this media type or in the same bundle group as the first m= section for this media type.
    • This m= section is in a bundle group, and the group's offerer tagged m= section is being rejected due to one of the above reasons. This requires all m= sections in the bundle group to be rejected, as specified in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 7.3.3.

(emphasis mine)

algesten commented 1 year ago

Sure. Let's reject it. I guess we should both reject on SDP level, and also for Rtc::media()