search

InnovateAsterisk / Browser-Phone

A fully featured browser based WebRTC SIP phone for Asterisk
https://www.innovateasterisk.com
GNU Affero General Public License v3.0
470 stars 239 forks source link

Disconnecting call for lack of RTP activity in 16 seconds #482

Open Raul2023BC opened 7 months ago

Raul2023BC commented 7 months ago

Hello, Everything works well but sometimes Asterisk disconnect my call with this message

chan_sip.c: Disconnecting call 'SIP/1082-0000e7fd' for lack of RTP activity in 16 seconds

This situation occurs randomly. So, I've run Wireshark on my computer, and it seems that my computer stops sending RTP packets to the server.

PcapImage

At the same time, other calls were stablished without issues.

My Asterisk is Asterisk 16.28.0 and I am using chan_sip.

Is this a problem with SIP.JS?

InnovateAsterisk commented 7 months ago

chan_sip.c: Disconnecting call 'SIP/1082-0000e7fd' for lack of RTP activity in 16 seconds

The old sip.conf file has a rtptimeout= setting that will hang up the call after that amount of time without being sent RTP packets. Your setting is set to 16. As you saw in the log.

Making this setting more, may not fix your problem tho. The real problem is why is your server not getting any RTP packets for 16 seconds?

At the same time, other calls were stablished without issues.

If you have concurrent calls, and only some are being ended, then something is causing this per channel.

So, I've run Wireshark on my computer, and it seems that my computer stops sending RTP packets to the server.

From what I see, your pc keeps sending packets to the server (asterisk.pbx) but, firstly the server is not receiving them (hence the timeout), and second the server stops sending packets to the client (your pc). The only reason that Asterisk would stop sending packets to the client is if it performed a re-invite. It shouldn’t be doing this, since it’s not possible to re-invite DTLS sessions in Asterisk.

This situation occurs randomly.

When things happen randomly, it’s often network or hardware related. Maybe a faulty NIC, not sure. (Although if it was that, it would probably affect all calls). You would need to find out if this is truly random, or some pattern that you are not picking up yet.

Is this a problem with SIP.JS?

No, sip.js is not a media stack. It’s only handles the sip messages. The RTP is all handled by the browsers internal media stack.

One thing to make sure works is STUN. This is used in the media negotiations. It should not be left out, even if you are using a local lan. Asterisk rtp.conf also requires the stun settings.

Raul2023BC commented 7 months ago

Thank you for your prompt reply.

Well, I added a "Stun/Turn" server to my topology, and it works well. However, it works only in the beginning of the negotiation. When the soft phone can't establish a peer-to-peer connection with the server, it sends RTP Stream to the TURN server (I can confirm it in the logs of the TURN Server and also in chrome://webrtc-internals/)

But when the RTP gets lost with a call that already was established, nothing happens. After 16 seconds, Asterisk Server disconnects the call.

Can SIP.js handle this event and renegotiate the ICE? I think the name of the event is iceconnectionstatechange.

InnovateAsterisk commented 7 months ago

From my understanding the TURN server would just end up being "before" Asterisk. This is often just an unnecessary hop for the media path. In a way Asterisk always has to be the TURN server / media relay / whatever you want to call it. This is because if Asterisk doesn't get a constant stream of RTP packets, it will consider the call dead, and hang it up. Asterisk is not a proxy, its a back-to-back user agent (B2BUA).

Without encryption, Asterisk has a neat trick, that can "optimise" itself out of a media path if the conditions are correct. This is rarely the case. Any setting from rtptimeout to MixMonitor will make it not possible for the media directly between the peers.

What are you trying to achieve here? Do you want peer-to-peer? If this is the case Asterisk just isn't the correct tool. Asterisk can't receive the call, route it to the correct endpoint, and then expect media to flow between the two endpoints (the way a proxy can)

Also, you mention "when the RTP gets lost with a call that already was established". My question here is, why would this happen? Your server IP would never change during a call. Maybe your client IP address would change... are you asking in the event that your PC changes connectivity during a call?