Hello Michael, The SIP.sj part is working as I expect, the problem as far as I understand is that FS does not realize that the connection related to the call changed. I must admit that I don't know how FS handles SIP over TCP, but it seems to be storing the connection that start the call. I believe it would make sense to store the connection where the last re-INVITE was received. 2015-03-27 16:43 GMT-03:00 Michael Jerris <mike@jerris.com>:
This is not a feature in any of the sip js stacks I know of, and I'm not quite sure how it would be implemented on top of sip. As Brian said, this is a feature in verto.
On Mar 27, 2015, at 3:28 PM, Mateus Dalepiane <mdalepiane@gmail.com> wrote:
Hello Brian,
Thank you for the answer. We will consider using Verto in the future.
Right now we will have to stick with WebRTC over SIP, we are using SIP.js for that.
I ran some more tests and once the Websocket connection drops and is re-established, even if we send a re-INVITE, FS identifies it as belonging to the old call, and responds to it, after a while FS hangs up the call reporting a NORMAL_TEMPORARY_FAILURE.
If the Websocket is not disconnected, I can see that FS sends an re-INVITE to the client after a while, so I guess that what is happening is that when FS tries to send this re-INVITE it realizes that the old connection was closed and hangs up the call.
My question now is: Why FS does not update the connection information for the call once the re-INVITE from the new connection is received?
2015-03-26 15:15 GMT-03:00 Brian West <brian@freeswitch.org>:
Have you taken a look at Verto?
On Thu, Mar 26, 2015 at 12:08 PM, Mateus Dalepiane <mdalepiane@gmail.com> wrote:
We have the following scenario: The session is established between WebRTC and FreeSWITCH using Websockets.
Once the session is established, if the websocket connection drops the media continues to flow util FreeSWITCH tries to send a re-INVITE to the client. At this point it realizes that the connection was closed and hangs up the call.
Now, if the websocket connection drops and is re-established, would it be possible to inform FreeSWITCH that the new connection should be used for the previously established session?
If the WebRTC client sends an INVITE message with the old session parameters, FreeSWITCH will be able to understand that it belongs to the old session?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org