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

Sat Mar 28 02:12:09 MSK 2015

Alright, now I am convinced that this is not a viable approach.

> Out of curiosity, what about using verto makes it not practical in your
project right now?
Michael, I am working on Mconf, a project based on BigBlueButton. We do
plan on moving the WebRTC support from SIP.js to Verto, but right now we
were looking into this as a temporary solution to mitigate connection
problems that we are having with some clients.

Thank you very much for your help!

2015-03-27 19:38 GMT-03:00 Anthony Minessale <anthony.minessale at gmail.com>:

> You could probably use a proxy like kamailio or opensips to translate the
> websockets to UDP or TCP and pass it on to FS but FS itself cannot be
> modified to do what you want.
>
>
> On Fri, Mar 27, 2015 at 5:31 PM, Michael Jerris <mike at jerris.com> wrote:
>
>> I understand what you are trying to do.  The current sofia code has no
>> way to handle this currently, and we don't have plans to add this
>> functionality, because we can already do so with mod_verto.  If you want
>> this functionality in freeswitch, your options are using mod_verto, or a
>> huge amount of c code in mod_sofia that will be very error prone as it will
>> have to turn the state engine in that module on its head.
>>
>> On Mar 27, 2015, at 5:31 PM, Mateus Dalepiane <mdalepiane at gmail.com>
>> wrote:
>>
>> 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
>>>
>>
>> _________________________________________________________________________
>> 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
>>
>>
>>
>> _________________________________________________________________________
>> 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
>>
>
>
>
> --
> Anthony Minessale II       ♬ @anthmfs  ♬ @FreeSWITCH  ♬
>
> ☞ http://freeswitch.org/  ☞ http://cluecon.com/  ☞
> http://twitter.com/FreeSWITCH
> ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+
> <http://freeswitch.org/g+>*
>
> ClueCon Weekly Development Call
> ☎ sip:888 at conference.freeswitch.org  ☎ +19193869900
>
> https://www.youtube.com/watch?v=9XXgW34t40s
>
> _________________________________________________________________________
> 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/8aad39d7/attachment-0001.html 