WebRTC Call not closed correctly


I’m calling asterisk using a webRTC session and sip protocol.

The call is forwarded from asterisk to an ASR agent (virtual agent), and this is managed by agi commands.

The problem is that when the call is closed by the web page, closing the WebSocket connection, asterisk does not close the call, the call is closed by the agi commands when after a timeout.

Is there a way to close immediately the asterisk connection to the ASR engine when the websocket connection is closed?
I’m using JsSIP 3.7 library.

My webrtc session is:

var session = phone.call(‘sip:’ + asterisk_extension + ‘@’ + serverIp, options);

when the user call the session terminate:


the session is closed only by user side.

any help is appreciated, thank you

I think you mean the, deprecated, chan_sip driver, not the SIP protocol.

The SIP protocol requires you to close a session with BYE, not just drop the underlying transport. In non-WebRTC contexts, it is perfectly legal to drop the transport and then replace it.

Actually David, WebRTC connection should also be included in your statement. If I can re-establish a web socket connection, there should be no reason why I can’t continue to control the established dialog. In my tests i’m able to do this without a problem.

You really should have no reason to close the WebSocket connection. It’s required to be open the entire session, however if a user closes the tab for example, you can fire off code in that event. the onbeforeunload event is called on any browser tab at this moment, and you can use it to terminate any call in place. It will be fire-and-forget because of the asynchronous nature of code, and the server response to this will not reach you, but im sure that’s fine as the call would be ended on the server side, and you page would be unloaded.

In the event that the browser crashes, or there is a power failure, or the user force-quits the application, without this code getting a chance to fire, your best bet is to have rtp_timeout parameter set to something like 120 seconds, so that after 2 min of no audio packets, the call ends. Either way, its pretty messy, and there is little you can do.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.