RTPSession and Azure Web Apps

[hiagotakaki]

Hi everyone!

I've built a solution using SIPSorcery that acts as a bridge in the back-end of my web app.
Basically, users shares the same SIP account to make SIP calls and the app manages both RTPSession and RTCPeerConnection, forwarding RTP packets between them.

It works perfectly when running on a VPS provided by some hostinf services, but when deployed on an Azure VPS or an Azure Web App Service, the app fails to stablish RTPSession nor RTCPeerConnection.

I've set up an NSG with inbound and outbound rules to allow the necessary ports, and the network does not have a NAT gateway configured.

I've been troubleshooting this issue for weeks and found the following logs related to the problem:

dbug: sipsorcery[0]
ICE RTP channel sending connectivity check for udp:[::]:50576 (host)->udp:192.168.0.11:9 (host) from [::]:50576 to 192.168.0.11:9 (use candidate False).
dbug: sipsorcery[0]
ICE RTP channel sending connectivity check for udp:[::]:50576 (host)->udp:[2804:14c:5782:8443::141a]:56711 (host) from [::]:50576 to [2804:14c:5782:8443::141a]:56711 (use candidate False).
warn: sipsorcery[0]
SocketException RTPChannel EndSendTo (99). Cannot assign requested address
System.Net.Sockets.SocketException (99): Cannot assign requested address
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow)
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.SendToAsync(Socket socket, CancellationToken cancellationToken)
at SIPSorcery.Net.RTPChannel.Send(RTPChannelSocketsEnum sendOn, IPEndPoint dstEndPoint, Byte[] buffer)
at SIPSorcery.Net.RtpIceChannel.SendSTUNBindingRequest(ChecklistEntry candidatePair, Boolean setUseCandidate)
at SIPSorcery.Net.RtpIceChannel.ProcessChecklist()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
at SIPSorcery.Net.RtpIceChannel.ProcessChecklist()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.TimerQueueTimer.Fire(Boolean isThreadPool)
at System.Threading.TimerQueue.FireNextTimers()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
--- End of stack trace from previous location ---
at System.Threading.Tasks.TaskToApm.End[TResult](IAsyncResult asyncResult)
at SIPSorcery.Net.RTPChannel.EndSendTo(IAsyncResult ar)

My networking skills aren't great, and that's why I'm stuck.

Any help would be greatly appreciated!

[sipsorcery]

I suspect your Azure VM is not enabled for IPv6. You could add a public IPv6 address to it or you could update your app to restrict it to only bind to the IPv4 interface:

RTCConfiguration config = new()
{
	X_BindAddress = IPAddress.Any
};
var pc = new RTCPeerConnection(config);

[sipsorcery]

Seems like the SDP negotiation should be ok then.

It wouldn't hurt to add the STUN server to the browser as well:

pc = new RTCPeerConnection({ iceServers: [{ urls: STUN_URL }] });

It would probably also be easier to run one of the WebRTC GetStarted examples on your Azure VM to isolate the WebRTC Part of the app. Azure (and most cloud environments) are not always that friendly to UDP although in your case you seem to have the SIP call working.

[hiagotakaki]

Oh, my friend! We've made some progress here.
Some calls work well, but others still have issues.

I discovered that the RTPSession between my app and my SIP provider only starts when we send some audio... So, I send DTMF tones to trigger RTP packet reception, but when I try to send them via RTCPeerConnection, I see the log below:

2025-02-26T13:00:03.9617941Z warn: sipsorcery[0]
2025-02-26T13:00:03.9618610Z       SendRtpPacket cannot be called on a secure session before calling SetSecurityContext.

[hiagotakaki]

My app is currently in 😺 Schödinger mode — it's both working and not working at the same time.

I'll share both successful and failed logs... Maybe it will help.

Successful logs:
successful.txt

Failed logs:
failed.txt

[sipsorcery]

The BIG difference is you are now getting a public IPv4 ICE candidate from the remote peer. If you check your previous traces you'll notice the equivalent of the line below is missing. I suspect you added a STUN server to your browser webrtc config.

2025-02-26T11:56:58.5476800Z RTP ICE Channel received remote candidate: 2433181933 1 udp 1685724927 177.100.219.19 57355 typ srflx raddr 192.168.0.11 rport 57355 generation 0

The most likely reason some attemtps work and some don't is NAT on the network your browser is sitting on. To amke that relibale you'll need to use a TURN server at one of the end points. A TURN server is not ideal as it acts as a middleman for your webrtc media packets but if you have finicky NATs on your netowrk path it's the only viable option.

[hiagotakaki]

Yes, I did add the same STUN server to my front-end application.

I'll try adding a TURN server as well, but I don't understand why the same browser can connect to some servers but not to Azure.

[hiagotakaki]

Thank you @sipsorcery for your help!

We just added a TURN server to relay network traffic on both the front-end and back-end of our app as suggested, and it worked perfectly!

I truly appreciate your help — I couldn't have done it without you.