Aaron Clauson

> @sipsorcery this seems to be a major issue, which also affects all the previous versions of SIPSorcery Do you mean for applications that want to use the library? Yes,...

> It is a bit deceptive to provide a software package with a declared 3-Clause BSD license when said package also includes files with AGPLv3 license. That's a fair call....

@henca in case you're still interested I did dig further into the origins of the Java DTLS/SRTP classes that were added to this library. The origins appear to have been:...

I did toy with the idea of splitting the library up along functional lines #1271. That would potentially help in this case. The SIP/VoIP part of the library does not...

Sounds like it might have been the nuget versions getting out of sync. Should be OK now. If not please open an issue on the SDL2 repo.

It looks like a bug might have been introduced. The SIPUserAgent class should send the BYE request to hangup once it gets the 202 accepted response for the blind transfer....

Actually looks like the "bug" might have always been there. This [blind transfer test scenario](https://github.com/sipsorcery-org/sipsorcery/tree/master/examples/SIPScenarios/BlindTransferScenario) from circa 5 years ago has the transferee hanging up the call.  The [SIP...

> It sounds like I can just do userAgent.Hangup() after I call userAgent.BlindTransfer() as long as the result is true? Yes.

Can't say I've heard of that behaviour before. Some NATs will delete a mapping after as little as 30s of inactivity so calls are likely to drop with that approach....

There should be a release this week. I'm waiting for confirmation of another in-train fix.