We of course have an ever increasing amount of this on the commercial side.
The wiki, like the sipXecs software, is a community project. If you have suggestions or contributions you think would make things better, then don't just sit back and wait for somebody else to do it. More input and more contributors are always better! Thanks, Mike Mike On Feb 17, 2012 11:39 AM, "Nate" <[email protected]> wrote: > > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: 8bit > Organization: SipXecs Forum > In-Reply-To: < > caceoiqfhqokk2s3df2hme4v6xmo8bawmf7r4q--q6uipids...@mail.gmail.com> > X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <66151> > Message-ID: <[email protected]> > > > > I've been thinking of posting something similar to this for > a couple weeks. Not about problems with stability, but > about the need for a consolidated "best practices" guide. I > know there is a ton of information on the wiki, but for > someone new to sipXecs it's tough to sort through the wiki > and forum and figure out which recommendations are most > popular, which are most current, etc. Some people replied > that Tim should "read the book," although he clearly said > "I've followed the instructions from the book, the wiki, and > this forum." If someone spent a year testing sipXecs and > couldn't get it running well, I think it's reasonable that > he get frustrated and move on. If there was a best > practices guide that was kept current with the > recommendations of those who are successfully running > sipXecs installations, at least he could reference that and > see where his installation differs. > > In my relatively short time following this project and the > mailing list, I see a lot of the same questions coming up > repeatedly. It seems like a lot of time could be saved on > both ends (new users and developers/support) if people could > easily see a list of what works and what doesn't in the > current release. For example, here's a list of things I'm > unsure about after reading the wiki and following the > mailing list for a while: > > -Should sipXecs run behind NAT? What are you losing by > doing that? > -When is a SBC required? Which ones are known to work? > -How many people are using SRTP/TLS? > -How are remote users connecting if on a private network? > -Which is recommended for enterprises: using enterprise > domain (DNS), seperate domain, or a subdomain (very common > question/problem) > -Which ITSP(s) are least problematic? Which support E911? > -Best method for 911 for remote users or remote offices. How > to point phone to local gateway for 911 calls. > > I hope to get some of these answers at the sipX-CoLab, > although it seems like more advanced topics and 4.6 will > mostly be covered. I admit that I have not read the book > yet (though I plan to), but although it is probably still > relevant, it is for an older release. > > Just as a reference/idea, I have followed and used Zenoss > since before they went commercial. They have a fairly large > administration guide in PDF and HTML, and for each new > version that is released the changes get applied and the new > guide is released. It would probably be fine to do that on > a wiki page, but it would need to stay current and keep > different versions, so you know you can always look at the > guide for the release you are using. > > Just thought I'd chime in and give a few suggestions, but I > really like this project/community and see that it has a ton > of potential. I hope to be able to move all of our legacy > hybrix PBXs to sipXecs in the (hopefully near) future. > > -Nate Baker > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
