STUN Server null reference exception fix

[ispysoftware]

If you add a TURN option to ice it sends allocate requests to the STUN server which results in null reference exceptions as the STUN server only accepts binding requests. This adds a more helpful error message to debug output.

[sipsorcery]

What's actually changing in this PR? Which line has the change and is not just a refactor?

[ispysoftware]

It's not returning null..when it returned null you got a null reference exception.

[sipsorcery]

Is this the non-refactor change?

default://Allocate not supported - this is a STUN server only not a full TURN server
    throw new ApplicationException("Unsupported MessageType " + stunRequest.Header.MessageType);

Is there any reason to throw an exception? With protocols like STUN & RTCP there are regularly unsupported message types. In 99% of cases it's safe to ignore them and allow the connection to proceed. Throwing an exception will potentially mean WebRTC connections will be blocked by an unknown STUN message type.

[ispysoftware]

I only found two references to it in the code base and there was no null check on the result hence the null reference exception. You make a good point though it should probably be fixed upstream.

[ispysoftware]

Actually.. The method i changed is private and it's only called in 2 locations in SipSorcery code, both of which will throw a null reference exception immediately afterwards if GetResponse returns null. I think it's better design to throw a meaningful exception message rather than let it fail with a null reference exception which is basically meaningless to consumers.

STUNMessage stunResponse = GetResponse(receivedEndPoint, stunRequest, true);
byte[] stunResponseBuffer = stunResponse.ToByteBuffer(null, false);