Re: Fwd: open-source IP-PBX

[Alistair Munro <>]

Hi Ben,

Please don't get me wrong - I don't want to be a wet blanket and 
suppress innovation. Nor would I insist on this group aiming slavishly 
at a level of telephony GoS that is inappropriate to the WG's ambitions. 
However, we must set some level of expectation.

> Even if IP telephony evolves into a service with all the legacy
> requirements you mention (and, btw, there is no reason why it must
> evolve this way),
I do not believe that IP telephony *must* evolve this way of its own 
accord, (so I agree with you), yet a significant amount of effort is 
being put towards retaining compatibility with the legacy for very good 
reasons. It would be nice to see innovations come out of the work of 
this WG that take the advantage of our unique opportunity to move away 
from the legacy (implementing it where it's useful of course).

> there is no reason why core server and middleware
> software can't be open source. 
Agreed as well. I will be delighted to use it.

> Note that there are innumerable
> commercial web services built on Apache, Perl, PHP, FreeBSD, etc.
> Since SIP service creation is quite similar to writing Web CGIs and
> large numbers of institutions more or less need exactly the same
> functionality, I could imagine open source succeeding quite nicely in
> this space.
I can't disagree on the principle but I don't believe the similarity 
holds up.  We are told that telephony service platforms are large pieces 
of software executed on large pieces of hardware and I suspect that this 
will still apply to a very large extent, even though the savings in some 
areas of switching through using IP platforms are well documented. The 
legacy model is probably entirely  the wrong place to start - are there 
any tangible counterexamples that you could refer me to?

> Also, you are dead wrong on serviceability.  One of the key advantages
> of open source software is that it *is* serviceable by anyone
> motivated to enough to fix the bugs.  Various empirical studies
> confirm this (for example, see
> ftp://grilled.cs.wisc.edu/technical_papers/fuzz-revisited.ps.Z).
I'm sorry - I used "serviceability" to mean "the ability to deliver a 
service", not the community will to correct, enhance and maintain open 
source code, from which we have all benefitted. I'm happy to be 
corrected on the general issues and specific cases but I think this is a 
task that is several orders of magnitude bigger. It may be possible to 
accrete a critical mass of resource to do this work.

> However, I agree with you 100% about the importance of numbering,
> naming, and peering.  It might be useful for this group to coordinate
> with the Internet2 middleware groups that are looking at
> inter-institutional directories and video middleware.
Yes, we should benefit from current practice if it is appropriate. It is 
one of the reasons I am concerned about serviceability (by my definition 
:-))

Regards,

Alistair

--
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: 

Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) 
+44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.degree2.com, http://www.u4eagroup.com



---------------------------------------------------------------wg-voip-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

---------------------------------------------------------------wg-voip--