Thomas Eizinger

> which means the above code shouldn't kick in. Seems like a bug. The above code is for _candidates_. The candidate is accepted correctly, it is the candidate _pair_ that...

> Ah, got ya. > > This behavior changed with [51acd55](https://github.com/algesten/str0m/commit/51acd55f46a48a8a416d1343c96fdad2bfd0a02e) Yeah I had a hunch that we may have broken that in that commit.

> https://datatracker.ietf.org/doc/html/rfc8445#section-5.1.3 > > ``` > Frequently, a server-reflexive candidate and a host candidate will be > redundant when the agent is not behind a NAT. A candidate is >...

I think this got fixed by not adding server-reflexive candidates to the local agent.

Parsing a `StunMessage` currently also allocates because all attributes are collected into a `Vec`. Given that we only support a constrained set of attributes, this can probably be improved upon...

> Good point! > > I favor `Option`. This is actually exactly equivalent to our RTP header extension values, where do already do it: [`main`/src/rtp/ext.rs#L846](https://github.com/algesten/str0m/blob/main/src/rtp/ext.rs?rgh-link-date=2023-12-24T06%3A23%3A44Z#L846) – it would be really...

> Should be fairly simple. The starting point for fuzzing is in place. See `run-fuzz.sh` in the root. Ha! I should have checked that. I was relying on my memory...

That makes sense, thank you for clarifying. I'll reword the title and description! :)

> @thomaseizinger maybe good to summarize what you found regarding full non-openssl feature during your ice-agent work here. I am not sure I understand. The only reason I made `openssl`...

> Logic needs to be tweaked a little for this, currently we assume the supported SRTP profiles are common across all crypto implementations Yeah that is why I argued for...