Rejecting m-lines

[k0nserv]

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]

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