[Freeswitch-users] Re-establish connection within a SIP session

[Mateus Dalepiane]

Hey guys,

Thank you all for the attention and patience to respond my questions.

I understand that the ideal solution would be to use Verto, but that's not
practicable in our project right now.

So, about the reconnected session, I am not sure if I made myself clear
about what is happening, and what I am trying to do.

    WebRTC client  . . . nginx  . . . . FreeSWITCH
      (SIP.js)           proxy               |
         |                 |                 |
         |     CONNECT     |                 |
         |---------------->|                 |
         |              INVITE               |
         |---------------------------------->|
         |                OK                 |
         |<----------------------------------|
         |                ACK                |
         |---------------------------------->|
         |           Media Session           |
         |<=================================>|
         |                 .                 |
         |                 .                 |
         |                 .                 |
         | CONNECTION FAIL |                 |
         |<-----XXXX------>|                 |
         |       Media continues to flow     |
         |<=================================>|
         |     CONNECT     |                 |
         |---------------->|                 |
         |              re-INVITE            |
         |---------------------------------->|
         |                OK                 |
         |<----------------------------------|
         |                ACK                |
         |---------------------------------->|
         |                 .                 |
         |                 .                 |
         |                 .                 |
         |                 |     INVITE      |
         |                 |<------XXX-------|
         |                 |                 | FS hang up call
         |         Media stop flowing        |
         |<==============XXXXX==============>|

So, based on this scenario, when the Websocket connection to nginx fails,
we reconnect it, but since the media is going through other connections,
RTP over UDP, it is not affected.

Now, with the new websocket connection in place the client is able to send
re-INVITEs and BYE to FS, and it is recognized as requests for the session
established using the first connection.

The problem is that when FS tries to send a message to the client it fails
(NORMAL_TEMPORARY_FAILURE) and hangs up the call.

Right now my question is:
 - How does FS know which connection it should use to send SIP messages to
the client?

Thank you!

2015-03-27 17:15 GMT-03:00 Michael Jerris <mike at jerris.com>:

> verto has its own JS client in tree.
>
> On Mar 27, 2015, at 4:05 PM, Abdul Hakeem <alhakeem at gmail.com> wrote:
>
> Hi Guys,
> What’s the best recommended client to connect to Verto ?
> Cheers,
> Abdul Hakeem
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [
> mailto:freeswitch-users-bounces at lists.freeswitch.org
> <freeswitch-users-bounces at lists.freeswitch.org>] *On Behalf Of *Michael
> Jerris
> *Sent:* Friday, March 27, 2015 7:43 PM
> *To:* FreeSWITCH Users Help
> *Subject:* Re: [Freeswitch-users] Re-establish connection within a SIP
> session
>
> 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 at 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 at freeswitch.org>:
> Have you taken a look at Verto?
>
> On Thu, Mar 26, 2015 at 12:08 PM, Mateus Dalepiane <mdalepiane at 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 utilFreeSWITCH 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150327/2f737d98/attachment-0001.html