Personally, I would say that it is not in the interest of the project to scatter focus away from itself, while further confusing newbies and in general making the "marketing message" less coherent.
That effort would be better spent on making Kamailio more user-friendly and/or easily deployable for trivial scenarios and small-scale, narrow purposes--if that's a priority for the project. Whether it even should be a priority deserves some rational discussion, since that may not be where Kamailio is strongest, just by design. The goal of a project should be to try to succeed in the game most appropriate for its character, and one which best aligns with the vision behind it.
-- Alex
-- Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/Daniel-Constantin Mierla miconda@gmail.com wrote:Personally I haven't used repro, so I cannot give relevant comments on it.
Cheers, Daniel
On 8/5/12 11:25 PM, Daniel Pocock wrote:
I've recently been doing some improvements to reSIProcate and it's SIP proxy, `repro'
http://www.resiprocate.org/About_Repro
It may appear to be a competitor for Kamailio - but a closer look at it reveals some interesting possibilities:
a) the config file is less flexible than Kamailio - but this makes it extremely easy to set up. This makes it an ideal stepping stone for people who are not ready for Kamailio
b) for Kamailio to really become widespread depends on a wide community of sites running SIP proxies - repro appears to be a solution that can be used to activate many public SIP servers very quickly, creating a world where everyone speaks Kamailio's language
I'm curious to get some feedback about
- have other people involved with Kamailio (and related proxies) had any
exposure to reSIProcate already?
- making repro and Kamailio work well together (ideally using DNS SRV
and TLS with domain certificates/federated VoIP) - test cases? public test servers?
- promoting the two proxies together, repro as the beginner solution,
Kamailio as a strategic option for people who need more flexibility - does anyone feel comfortable with this concept?
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 07/08/12 05:46, Alex Balashov wrote:
Personally, I would say that it is not in the interest of the project to scatter focus away from itself, while further confusing newbies and in general making the "marketing message" less coherent.
This is not a universal truth
Promoting a conflicting technology (e.g. Viber or Skype) would not help Kamailio very much
However, competitors can work together constructively. The closest person to Mr Bolt in the 100m and 200m this week was his training partner, Yohan Blake. Is there anyone on this mailing list who would NOT like to whitewash the world with open source, open standards based SIP proxies in the way Jamaica whitewashed the gold, silver and bronze for 200m last night?
That effort would be better spent on making Kamailio more user-friendly and/or easily deployable for trivial scenarios and small-scale, narrow purposes--if that's a priority for the project. Whether it even should be a priority deserves some rational discussion, since that may not be where Kamailio is strongest, just by design. The goal of a project should be to try to succeed in the game most appropriate for its character, and one which best aligns with the vision behind it.
Not necessarily, should Kamailio developers really spend time on things like:
- making an MSI package for Windows users?
- making a built-in admin web server?
In fact, with built in web server and Berkeley DB support, repro is fully self-contained and could even run on a router.
These are just some of the unique features of repro that are maybe very low on the priority list for Kamailio, but they are important for a world of federated SIP servers
I've put up a guide here with some config samples and screenshots, I'd actually like to adapt this to have a Kamailio equivalent of the same guide
http://www.opentelecoms.org/federated-voip-quick-start-howto
and any feedback would be really welcome
Hi,
On 08/10/2012 06:13 PM, Daniel Pocock wrote:
Not necessarily, should Kamailio developers really spend time on things like:
making an MSI package for Windows users?
making a built-in admin web server?
In fact, with built in web server and Berkeley DB support, repro is fully self-contained and could even run on a router.
These are just some of the unique features of repro that are maybe very low on the priority list for Kamailio, but they are important for a world of federated SIP servers
These things already exist for a long time on top of Kamailio, e.g. http://www.sipwise.com/products/spce/
It's of no real interest for the Kamailio project itself, because Kamailio focuses on providing a highly flexible and performant SIP routing engine. The "real" applications are provided at a higher level. Pretty much the same as with Apache or Nginx providing the web server, which don't do anything useful by themselves, but shine when people write their own applications on top of it, served by these components.
I've put up a guide here with some config samples and screenshots, I'd actually like to adapt this to have a Kamailio equivalent of the same guide
http://www.opentelecoms.org/federated-voip-quick-start-howto
and any feedback would be really welcome
That's nice and important for the SIP landscape and everything, but how is this of relevance for the Kamailio project? There are quite a couple of open source SIP proxies or soft switches out there, and if they speak proper SIP and adhere to the SIP related standards, they should be able to play together nicely. So I don't get the idea of "advertising" repro and kamailio together, as they are different and unrelated projects, and the users can choose whatever suits them better.
Andreas
10 aug 2012 kl. 18:13 skrev Daniel Pocock:
On 07/08/12 05:46, Alex Balashov wrote:
Personally, I would say that it is not in the interest of the project to scatter focus away from itself, while further confusing newbies and in general making the "marketing message" less coherent.
This is not a universal truth
Promoting a conflicting technology (e.g. Viber or Skype) would not help Kamailio very much
However, competitors can work together constructively.
We're not saying that we can not work together. But there's limited time to spend on the project and so far no one here has seen any benefit in spending that time on joint marketing of our projects. Exchanging ideas, recommending each other's products in different situations is something we've been doing for a long time and won't stop doing now.
We look forward to continue the discussion with you and possible cooperation in how to support various issues. Please keep us informed about the progress of the Resiprocate/Repro projects!
/O
PS. Kamailio also has a built-in web server. We have a configuration web in Siremis. As we don't support Windows, there's no need for a MSI package.
-
Alex Balashov -
Andreas Granig -
Daniel Pocock -
Olle E. Johansson