Re-establish connection within a SIP session
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?
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
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com ClueCon 2015 Call for Speakers <https://www.cluecon.com/call-for-speakers/> | Register <https://freeswitch.com/cart.php?gid=1> TODAY! *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
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
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com
ClueCon 2015 Call for Speakers <https://www.cluecon.com/call-for-speakers/> | Register <https://freeswitch.com/cart.php?gid=1> TODAY!
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
_________________________________________________________________________ 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
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 <mailto:brian@freeswitch.org>>: Have you taken a look at Verto?
On Thu, Mar 26, 2015 at 12:08 PM, Mateus Dalepiane <mdalepiane@gmail.com <mailto: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?
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
Hi Guys, What's the best recommended client to connect to Verto ? Cheers, Abdul Hakeem From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@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@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?
verto has its own JS client in tree.
On Mar 27, 2015, at 4:05 PM, Abdul Hakeem <alhakeem@gmail.com> wrote:
Hi Guys, What’s the best recommended client to connect to Verto ? Cheers, Abdul Hakeem <> From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@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@gmail.com <mailto: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 <mailto:brian@freeswitch.org>>: Have you taken a look at Verto?
On Thu, Mar 26, 2015 at 12:08 PM, Mateus Dalepiane <mdalepiane@gmail.com <mailto: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 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?
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@jerris.com>:
verto has its own JS client in tree.
On Mar 27, 2015, at 4:05 PM, Abdul Hakeem <alhakeem@gmail.com> wrote:
Hi Guys, What’s the best recommended client to connect to Verto ? Cheers, Abdul Hakeem
*From:* freeswitch-users-bounces@lists.freeswitch.org [ mailto:freeswitch-users-bounces@lists.freeswitch.org <freeswitch-users-bounces@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@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 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@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
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@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@jerris.com <mailto:mike@jerris.com>>: verto has its own JS client in tree.
On Mar 27, 2015, at 4:05 PM, Abdul Hakeem <alhakeem@gmail.com <mailto:alhakeem@gmail.com>> wrote:
Hi Guys, What’s the best recommended client to connect to Verto ? Cheers, Abdul Hakeem <> From: freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@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@gmail.com <mailto: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 <mailto:brian@freeswitch.org>>: Have you taken a look at Verto?
On Thu, Mar 26, 2015 at 12:08 PM, Mateus Dalepiane <mdalepiane@gmail.com <mailto: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 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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ 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
Out of curiosity, what about using verto makes it not practical in your project right now?
On Mar 27, 2015, at 6:31 PM, Michael Jerris <mike@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@gmail.com <mailto:mdalepiane@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@jerris.com <mailto:mike@jerris.com>>: verto has its own JS client in tree.
On Mar 27, 2015, at 4:05 PM, Abdul Hakeem <alhakeem@gmail.com <mailto:alhakeem@gmail.com>> wrote:
Hi Guys, What’s the best recommended client to connect to Verto ? Cheers, Abdul Hakeem <> From: freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@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@gmail.com <mailto: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 <mailto:brian@freeswitch.org>>: Have you taken a look at Verto?
On Thu, Mar 26, 2015 at 12:08 PM, Mateus Dalepiane <mdalepiane@gmail.com <mailto: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 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?
_
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@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@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@jerris.com>:
verto has its own JS client in tree.
On Mar 27, 2015, at 4:05 PM, Abdul Hakeem <alhakeem@gmail.com> wrote:
Hi Guys, What’s the best recommended client to connect to Verto ? Cheers, Abdul Hakeem
*From:* freeswitch-users-bounces@lists.freeswitch.org [ mailto:freeswitch-users-bounces@lists.freeswitch.org <freeswitch-users-bounces@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@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 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@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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
-- 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@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s
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@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@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@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@jerris.com>:
verto has its own JS client in tree.
On Mar 27, 2015, at 4:05 PM, Abdul Hakeem <alhakeem@gmail.com> wrote:
Hi Guys, What’s the best recommended client to connect to Verto ? Cheers, Abdul Hakeem
*From:* freeswitch-users-bounces@lists.freeswitch.org [ mailto:freeswitch-users-bounces@lists.freeswitch.org <freeswitch-users-bounces@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@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 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@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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
-- 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@conference.freeswitch.org ☎ +19193869900
https://www.youtube.com/watch?v=9XXgW34t40s
_________________________________________________________________________ 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
Anthony, there was a question earlier in the thread about how Websockets and TCP differ in this scenario. Is it not the case that they are conceptually equivalent here? Would this issue also manifest with TCP, or are the code paths significantly different between Websocket and TCP? On 27 March 2015 at 19:38, Anthony Minessale <anthony.minessale@gmail.com> wrote:
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@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@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@jerris.com>:
verto has its own JS client in tree.
On Mar 27, 2015, at 4:05 PM, Abdul Hakeem <alhakeem@gmail.com> wrote:
Hi Guys, What’s the best recommended client to connect to Verto ? Cheers, Abdul Hakeem
*From:* freeswitch-users-bounces@lists.freeswitch.org [ mailto:freeswitch-users-bounces@lists.freeswitch.org <freeswitch-users-bounces@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@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 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@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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
-- 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@conference.freeswitch.org ☎ +19193869900
https://www.youtube.com/watch?v=9XXgW34t40s
_________________________________________________________________________ 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
participants (6)
-
Abdul Hakeem
-
Anthony Minessale
-
Ben Langfeld
-
Brian West
-
Mateus Dalepiane
-
Michael Jerris