Fix minor code style points and redundancies.

[randruc]

Fix minor code style points and redundancies.

[paulomorgado]

On such a large code base, I would avoid merely cosmetic changes.

For such changes, I would author a .editorconfg with the definitions and have dotnet format do its work.

There's a potential performance benefit (depending on the runtime) in the LINQ code, but nothing beats getting rid of LINQ to Objects alltoghedther.

[randruc]

Thanks for your review.
From what I understand, one of the goals of the project is to get rid of LINQ where unnecessary. Am I right?

[paulomorgado]

Thanks for your review. From what I understand, one of the goals of the project is to get rid of LINQ where unnecessary. Am I right?

It's not my project!

But, from my experience in .NET performance tuning and optimization, LINQ To Objects is a performance hog.

It erases the types transforming everything in IEnumerable<T>. There are optimizations for know types, but that incurs in type checking, which is not free.

And then there are the delegate costs with the the creation of the delegate and its invocation.

The convenience and readability of the code given by LINQ methods can be achieved by creating specialized methods that do not need delegates and operate on the specific collections.

[ha-ves]

Sometimes the magic of LINQ falls apart when you really look at it.

https://stackoverflow.com/a/21194850

[randruc]

Careful with this. I also read the same kind of thing at the time. This benchmark was done more than 10 years ago, before .net Core 1. And I said in the comments, the same benchmark performed way better with newer revisions.

[paulomorgado]

@randruc, this project is targeting .NET Framework 4.6.2. How old do you think it is?

And it's impossible or not cost effective to create a JIT compiler that handles every particular use case.

[randruc]

From what I read in the code comments, the project started in 2005.
How long have you been working on this project?

[paulomorgado]

I came across this project a couple months ago.

[randruc]

OK.
I think this project has big potential. I like the idea that it is quite simple, very few assemblies and dependencies, yet complete.

[paulomorgado]

I have the opposite opinion regarding the number of assemblies. It's everything and the kitchen sink. Even demo code.

I would split it into specialized assemblies. Why do I have to take RTSP if I only want WebRTC?

[randruc]

IMHO, for a small project like this one, maintaining a whole lot of specialized assembly is not an easy task. The codebase is small, the resulting assemblies are small, and the big interest of this project is that it comes batteries included. No bad surprises with missing dependencies etc.
To give you an example, on the project I started a few days ago, I plugged this library that I just discovered, tinkered with it to fit my need, and on the first run it worked directly! Nothing to configure, to download etc. It just worked right on the very first test!
I see this project like a Swiss army knife for SIP on .NET, and that's what I appreciate about it.

[paulomorgado]

Separation of concerns.

Take only what you need.

[randruc]

I understand. But again, for such a small project I don't see the point honestly.

[sipsorcery]

I appreciate it's a subjective choice but given I'm curently the one that spends the most time on the code base I prefer the explicit boolean checks.

AudioStream.LocalTrack.NoDtmfSupport == false

instead of

!AudioStream.LocalTrack.NoDtmfSupport

I find I often miss the '!' character and even without it I spend extra time calculating whether an expression is meant to be true/false. When it's explicitly stated I find it quicker to grasp>

Happy for the whitespace fixes, they always bug me as well.

[randruc]

Thanks for the review. I'll soon update the submission.