WebRTC Connection Timeout and TLS Exception #1465
Answered
by
ha-ves
JulianSchmidt1996
asked this question in
Q&A
-
|
Hey, I'm currently having a problem where my connection times out, and I haven't been able to figure out why. Here is the source code: I am currently testing the code exclusively on my local network without any complex firewalls in between. However, I have already checked whether simple things like disabling the Windows firewall or using a different router would help, but this was not the case. Wireshark did not provide me with any new insights in this regard, but I am happy to send you the recording. Maybe someone else has an idea of what else I can try or what the problem might be. I look forward to your feedback. Best regards, |
Beta Was this translation helpful? Give feedback.
Answered by
ha-ves
Nov 17, 2025
Replies: 5 comments 4 replies
-
|
Are both your peers using sipsorcery or is one peer a browser? If both peers are sipsorcery you could check a connection can be established on your machine using the webrtccmdline app: Start the first peer (it's called a server due tot he signalling) using:
and the second
Exmaple server peer output: Client peer output: |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Hello Aaron, Thanks for the quick reply. To answer your first question, both clients are sipsorcery. I ran the WebRCTCMD-Line app, and the handshake and connection establishment seem to work here. server peer output: Client peer Output Do you have any idea why it doesn't work with my code? |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone, Since the response so far has not been that great, I thought I would try uploading my C# Visual Studio project to GitHub so that the code can be tested more effectively. You can find my project here: To test it, simply publish it and run it twice. I use a simple Node.js script with HTTPS and WebSocket as the signaling server. It can be started via the console: “node signaling-server.js”. I would be delighted if someone could check out the project and see why the handshake error occurs. I look forward to your feedback. Best regards, Julian |
Beta Was this translation helpful? Give feedback.
-
|
Hi @JulianSchmidt1996, I tried your code with the exception I directly passed the offer-answer, not via websocket, and it works. It might have something to do with your WebSocket signalling setup. You could try enabling logging, and we may know where it went wrong. public MainWindow()
{
InitializeComponent();
// Configure logging to output to debugger
var loggerFactory = LoggerFactory.Create(builder =>
{
builder
.AddDebug() // Outputs to debugger window
.SetMinimumLevel(Microsoft.Extensions.Logging.LogLevel.Trace);
});
// Set the logger factory for SIPSorcery
SIPSorcery.LogFactory.Set(loggerFactory);
} |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi @ha-ves, Here is the output from the debug log. I tried to understand what you mean by passing the offer-answer directly and not through websocket. Can you tell me what you mean? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@JulianSchmidt1996 this pattern: var offer = _peerConnection_a.createOffer(null);
_peerConnection_a.setLocalDescription(offer);
_peerConnection_b.setRemoteDescription(offer);
var answer = new RTCSessionDescriptionInit
{
type = RTCSdpType.answer,
sdp = _peerConnection_b.CreateAnswer(null).ToString()
};
_peerConnection_b.setLocalDescription(answer);
_peerConnection_a.setRemoteDescription(answer);And so, This part of the log Could you switch around the debugging? If debugging is on the peer that you clicked "connect" first, now try it being second and send the logs. Or you could switch to file logging. (explained by copilot below) They should show the handshake as a client. If both are as server, it might be a negotiation bug. Copilot: File loggingHere’s the minimal change to add file logging while keeping your existing Debug provider. Using NReco.Logging.File (smallest/cleanest for this scenario): 1. Install packagedotnet add package NReco.Logging.File2. Update your constructorpublic MainWindow()
{
InitializeComponent();
var loggerFactory = LoggerFactory.Create(builder =>
{
builder
.AddDebug()
.AddFile("logs/sipsorcery.log") // ← add file output
.SetMinimumLevel(LogLevel.Trace);
});
SIPSorcery.LogFactory.Set(loggerFactory);
}3. Result
If you want rolling files, size limits, timestamps in filename, etc., I can give an example. |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Sure, I changed the debugging settings again. Here are the logs. Client B (Server) |
Beta Was this translation helpful? Give feedback.
-
|
@JulianSchmidt1996 Thanks for the confirmation, it seems like they both operate as A workaround I could think of is not to send offer on connected to the signaling websocket, but rather an additional mechanism to avoid this "race condition", maybe check for the availability of |
Beta Was this translation helpful? Give feedback.
Answer selected by
JulianSchmidt1996
-
|
@ha-ves Thank you, that's the problem. The workaround works like this. For my application, I have now defined a peer as a server that does not send any offers. Thanks for your help, I probably wouldn't have figured it out on my own. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@JulianSchmidt1996 Thanks for the confirmation, it seems like they both operate as
server, so they couldn't handshake successfully. The issue is at #1463A workaround I could think of is not to send offer on connected to the signaling websocket, but rather an additional mechanism to avoid this "race condition", maybe check for the availability of
offerand only sendanswer.