I have a .Net Core application that is the back-end of my application. In it, I am using the SIPSorcery library as a bridge between a SIP Server and my front-end application.
Basically, I forward every RTP packet received via RTPSession to an RTCPeerConnection and vice versa, according to the example in the library.
This works very well when I run my application on localhost (I only had a small problem with the Firewall that I resolved without difficulty), but when I deploy the same application on a Windows Server the RTP packets never arrive, even with all the ports released by the firewall .
I started to suspect some problem related to the Codec. Do I need to have something previously installed on the virtual machine for this to work well?
A sample code for creating RTP Session in my application:
RTPSession session = new(false, false, false, portRange: new(51200, 52399))
{
AcceptRtpFromAny = true
};
session.OnStarted += () => SendMessage("RTPSession Started", null);
session.OnClosed += () => SendMessage("RTPSession Closed", null);
session.OnRtpPacketReceived += (_, mediaType, rtpPacket) =>
{
if (!_peerConnections.Any() || mediaType != SDPMediaTypesEnum.audio) return;
_peerConnections.ForEach(peer =>
{
try
{
peer.PeerConnection.SendAudio((uint)rtpPacket.Payload.Length, rtpPacket.Payload);
}
catch
{
DisconnectPeerConnection(peer, "Erro na transmissão do pacote de áudio.");
}
});
};
MediaStreamTrack audioTrack = new(SDPMediaTypesEnum.audio, false, new List<SDPAudioVideoMediaFormat> { new SDPAudioVideoMediaFormat(SDPWellKnownMediaFormatsEnum.PCMU) });
session.addTrack(audioTrack);
Then, I answer the call (already accepted previously) with the created session:
await _sipUserAgent.Answer(sipIncomingCall, session);
Important information is that the SIP server is correctly configured to accept my connection, the problem is not on that side.
After deploying to IIS on Windows Server 2022, I ran the same tests I had done on localhost. Everything worked fine, until I tried to answer a call, in which no RTP packet was received, even though the UDP connection was opened.