Consider removing specific targeting unsupported runtimes

[paulomorgado]

.NET Framework 4.6.2 fully implements .NET Standard 2.0 and there is no code using anything specific to .NET Framework 4.6.2. So, .NET Standard 2.0 is enough to cover that.

.NET Core 3.1, .NET 5.0 and .NET 6.0 fully implements .NET Standard 2.1 and there is no code using anything specific to .NET Core 3.1, .NET 5.0 or .NET 6.0. So, .NET Standard 2.1 is enough to cover that.

There might be some usage of .NET 6.0 features in the future, but I would delay targeting it specifically to when that happens.

.NET Standard

[sipsorcery]

The plan is to split this repo into probably 3 separate repo's in the short to medium term, depending on when I can get time to do it. The general consensus seems to be:

• A SIP package
• A WebRTC package
• An everything else package probably Realtime.Net or something.

If/when that happens it would be the right time to fix up the runtime support. I'd strongly lean towared >= net8.0.

[paulomorgado]

You don't need to split a repo into several for this.

From the same repo/solution you can publish as many NuGet packages. If you look at dotnet repos (https://github.com/dotnet/extensions, https://github.com/dotnet/runtime, https://github.com/dotnet/aspnetcore) you can see it done.

My recommendation would be to concentrate everything sipsorcery into a single repo/solution (solution filters can be created) for ease of development and split it into NuGet packages that make sense.

I can help in all things C#, .NET, NuGet, MSBuild. Networking is one of the subjects I know the least.

[sipsorcery]

What's the advantage of keeping the source together?

The feedback has been that most devs are using the library for either a VoIP use case or a WebRTC use case. It would make it cleaner and more digestible for each individual case if the code was separated along those two lines. The infrastructure classes, which are not typically a primary use case would be in a 3rd repo for ease of sharing between the two.

[DavidMartynWood]

I'm torn on this.

Reasons to split:

Differing concerns.

The SIP portion of this library is very mature, and implements most use cases imho. Due to it being mature is it written in a way that was influenced by the capabilities of older versions of .net framework. But it works and works well. It might not always be the most efficient of code when it comes to parsing and serialising, but generally speaking that's not a huge concern due to the fact that sip messages don't arrive every 20 milliseconds. I think a lot of people use this as a base for stable applications.
Furthermore, debates over changes can be backed up to some extent by the sip standards (although of course there are differing interpretations and implementations).

The realtime audio part of this library is a great implementation that works well for many uses cases. But it is lacking in some areas, for example there is no jitter buffer, and no memory optimisation (which is important when you're processing a packet every 20 milliseconds and don't want audio glitches). Those wishing to concentrate on efficiency and audio/video quality can focus on this portion of the solution.

Webrtc is probably the least mature part of the library (understandably!). And I expect it to receive the most changes in the near future. It's likely to be fast changing and have to constantly worry about changing web browser requirements and new edge cases.

Maintainer spread

If the library is split, maintainers/contributers can focus on issues in their area of expertise.

Licensing

Parts of the library around encryption of media required for webrtc have an ambiguous license. The sip portion of the library is a very clean implementation, and the standards are very well adhered to.

Reasons not to split

Ease of changes

If the interfaces between the libraries is not stable, changing interfaces and keeping the repos in sync will be a maintenance headache.

Nuget dependencies

If projects are built in separate solutions they will need nuget references to each other which may be challenging to maintain.

And yes, please let's ditch .net framework and unsupported versions of dotnet 👍

[sipsorcery]

@DavidMartynWood agree with all those points.

The multiple nuget packages should be manageable and that problem does already exist with the SIPSorceryMedia.Abstractions etc. It's most likely manageable but is one extra thing that needs to be considered.

Some further context is that I do know of commercial services that rely on the SIP stack. I don't know of any that rely on the WebRTC implmentation and do not recommend it when asked. The WebRTC stack is still an immature implementation and there are lots of missing features including core ones such as an optimised video pipeline capable of 1080p.

[paulomorgado]

I agree with all that, I just want to make clear that there is no benefit in keeping multiple repos,

A single repo/solution can produce multiple NuGets.