VoIP Mailing List Archives

[jason at jasonjgw.net]

Ken Rice <krice@freeswitch.org> wrote:

[rs at runsolutions.com]

Shouldn't be so hard, right? But there's human nature, even if the
corporations get to save, like, 100k worth of licenses and hardware
and other costs it is very hard to get them to spend a little back to
the community which helped to achive that goal.

I think my first, very ambitous goal to make the sofia rewrite a
personal long-term hobby is not going to be very realistic, because of
my daytime job and my private life.

But I will try to persuade my employer to make at least a little
contribution, as I really want this in FS, maybe we should

* make it a bounty project
* try to bring in some big sponsors (who are the biggest companys
using FS anyway?)
* make some awareness in the voip scene??

seriously what else can be done to get the estimated 100k to become
reality?

I really want this feature in FS!

best,

--
Raimund Sacherer
-
RunSolutions
Open Source It Consulting
-

Parc Bit - Centro Empresarial Son Espanyol
Edificio Estel - Local 3D
07121 - Palma de Mallorca
Baleares

On Aug 31, 2009, at 7:57 AM, Jason White wrote:

[pete at privateconnect...]

Actually, getting the 100K is probably the easiest part of the battle. The problem will come in with the strings attached to the 100K. I could persuade my company to give FS devs the money, but there would be conditions, such as:
- There would need to be a defined timeline, milestones, and release date
- That release cannot be too far in the future (no one will fund an 18 month project any more)
- If those dates are missed, penalties will be applied
- There will be some of branding/marketing/PR agreement (turning the payment of development into a marketing tool)
- There will be all sorts of legal waivers the devs will have to sign (indemnifications, perpetual licenses, etc)

From previous OSS experience, the "baggage" that comes with a large payment is usually undesirable to dev groups. Which leave collecting a lot of little payments from many places. Anyone that has worked for some time fund raising for an organization will know how much of a logistical mess that is. Not to mention people that commit to pay, then back out.

One good way to get funding for a project like this is to target the government or non-industry related corporate entities. Both cases you target groups that don't compete in your market space (or rely on your competitors), but would benefit from the outcome of the project.

An example would be Dell. Dell would not see FS as competition in any way, but if the case was made that adding feature X would increase sales of Dell computers in the telcom space, or that Company X would buy Dells to run FS if this features existed, then Dell could look at investing in the project as a marketing expense.

There are down sides with this method. Devs need to walk a fine line with the corporation, ensuring that their product does not conflict with some corporate initiative or large client. Many times you will be partnering with VARS or SIs to present the proposal, as there has to be a project to justify the work. Also, expect a long sales cycle (5+ months). And, some purists would argue that the app is not FOSS once your get some large corp to fund all/part of it. Other are just content with getting the job done.

I offer my help in this area if the devs are interested in exploring this style of fund raising.
-pete

[rs at runsolutions.com]

Hello Pete,

wow, i like it when you say getting the money is the easiest part!


I think if you are able to help procure the money we should have, as Jim Burke indicated, a rather good brainstorming session behind us.
I will create today a Wiki Page where we can define the Project, break up the development parts, generelly layout what has to be done and what will be the best and cleanest way to do it, as well define what and when to failover, etc.


If we have a pretty clear Idea on what will be the best way, you can get and fetch the money


Seriously, i think we should discuss the possibility with Anthony how, if you/the community can come up with the money, this could be integrated into the development cycle!


Let's keep this rolling,
best


--
Raimund Sacherer
-
RunSolutions
Open Source It Consulting
-

Parc Bit - Centro Empresarial Son Espanyol
Edificio Estel - Local 3D
07121 - Palma de Mallorca
Baleares






On Aug 31, 2009, at 12:33 PM, Pete Mueller wrote:

[dave at 3c.co.uk]

A random thought. It strikes me that adding support for live call
failover to FreeSWITCH might well be the wrong thing to do - it's
something which is probably not too difficult to achieve if starting
from the ground up, but which is going to be a right PITA to do
retrospectively. And, once you've done switching, there's conferencing,
IVR stuff...

Here's an alternative approach. Have two FS boxes (which I'll call FS1
and FS2 - you can't fault *my* imagination) and a front-end B2BUA/RTP
proxy with a bit of a difference. The B2BUA sends incoming stuff to
both FS1 and FS2 as two separate call legs, and the RTP proxy forwards
inbound RTP to both FS1 and FS2. Assuming that FS1 is the current
"master", it forwards RTP and call state transitions from FS1 back to
the caller. If it detects that FS1 has gone away, then - as FS2 should
be in roughly the same state as FS1 - it flips to using FS2 as its
source.

The internal state of the B2BUA/RTP proxy should be relatively simple,
and therefore should be able to be duplicated to a hot standby.

I can see a collection of gotchas, such as registration (the B2BUA needs
access to the user database), and I haven't even begun to try to think
of how to deal with calls *from* the FS boxes. Actually, that's not
true: I have, and they clearly need to go through the same sort of
mechanism in reverse, which is fine until I start trying to work out how
to pair up calls from FS1 and FS2 reliably, and then my head hurts.

But I think that this idea has merit. Firstly, it abstracts the
failover mechanism away into one place; secondly, it is general - FS1
and FS2 could just as easily be Asterisk1 and Asterisk2.

And I'll do it for just $98,650..

--Dave

[rs at runsolutions.com]

Hi David,

On Aug 31, 2009, at 2:22 PM, David Knell wrote:

[jim at evolutiontel.net]

[jim at evolutiontel.net]

Actually Dave, our idea's are very similar.

The difference being is that you fork the calls into 2 separate legs
at a B2BUA and sending each to an FS box, while I would duplicate
messages to an FS box acting in Standby mode using extra SIP headers
to let the standby machine know the RTP port number and the UUID.
These 2 FS boxes would essentially become the core switching units in
Active/Standby configuration and be used to handle switching logic and
billing. Thus if FS2 became the Active box, it would have exactly the
same call information as FS1 had. Theoretically there would nothing
stopping FS1 and FS2 being master and standby for each other at the
same time and both handling traffic, although this has the potential
to cause over load if something did fail.

i.e FS1 receives INVITE, handles call and forwards INVITE to Gateway
and then sends a second INVITE (Duplication of Original message,
utilising extra SIP headers to pass on required information) to FS2.
FS1 fails FS2 takes over and handles call.

Then you would look at way's to distribute functionality across other
boxes to allow scalability. An example would be to use dedicated FS
boxes for TDM cards and Opensips to handle registrations, SIP proxy or
SBC controllers.

Of course this assumes you are looking to build a softswitch that can
handle large call numbers and have the $$$ to do so. Sadly, I have
niether the money or the requirement.




On Mon, Aug 31, 2009 at 10:22 PM, David Knell<dave@3c.co.uk> wrote: