I see how that could present a problem ... followed by the next obvious question of why aren't you sleeping at 4:00AM?
Seriously though, you might find a group locally that you could meet face-to-face because of the magnitude of your questions. That said, let me take a stab at some of the easier ones. Hosting providers come in several flavours. - people who let you put your server in their datacentre and you manage it remotely (expensive); - people who install your application on their server and manage it for you (very expensive); - people who install packages from a menu and you and they use varying technologies to limit your view on the server and you are actually sharing the server with many other customers but you can't see/interact with them. (Inexpensive) Obviously in this model you have no control over the machine itself - you simply call their support desk and open a ticket. The third option can be viable but you need to find a provider that offers Asterisk as part of their service because you are not at liberty to install new applications that aren't on their supported list. In the third model it also means you wouldn't need to provide them with software and teach them how to install it because they do everything and instruct you how to interact with them. In the first model, it's your box and if you need to get on a plane ... then you need to get on a plane ;-) In the second model they take care of everything for you but it is expensive because they need to come up to speed on your application, learn how it works, learn how to integrate it into their Managed Operations environment, etc. So for your purposes I'm assuming you are probably looking at options 1 or 3 depending on volumes and remote access abilities. OK, remote access. Unix (meaning Unix, Linix, AIX, DG/UX, HPUX, etc. -- all the *ix's) come with significantly more "stuff" in the box than DOS/Windows ever did. You can do a lot of functional work without having to buy additional software. Remote access is one of those. Unix servers support a protocol called Secure Shell (SSH) which encrypts the entire communication stream. A managed provider should offer you SSH access to a shell prompt or "shell account" (Unix terminology for command line). From there you can manage most of the box as Unix's have standardized on using plain text files for configuration meaning that a simple text editor (which comes with Unix) can be used to change all your configs. (AIX excepted as they use something called ODM which is akin to Windows registry - blah). OK, command lines good, but what about a gui? Your in luck. Contrary to Microsoft Windows, the windowing system for Unix - Xwindows - separates the actual pictures on your screen, keyboard and mouse from the application doing the work by a TCP/IP connection. This means the GUI can be drawn on one machine while the application runs on another far away. SSH from your shell account can be used for this so you can start the graphical environment remotely to manage the box. One of your other questions was relating to the box' ability to keep up with demand. Now there is no free lunch here. VoIP is great or we all wouldn't be here, but from a quality consistency standpoint it is always a compromise. The key is at what point on the curve do you place yourself. Generally speaking a VoIP box needs to be over provisioned to handle it's task and shouldn't be bogged down with additional applications because of they way time slices are allocated. Lets look at old-style telephony. Time Division Multiplexing (TDM) takes a stream (lets call it one channel - 64K) and reserves that space by sending constant traffic between both end-points. When the channel is not used it sends filler, when the channel is used, it replaces the filler with the content of the audio call. Not real efficient because it means you transport full bandwidth ALL THE TIME. The up side, is that because that bandwidth is both physically and logically reserved, you can never get "bumped" because there were not available time cycles for the cpu (cause it was already generating filler) or in the pipe (because it was already consumed). But ... the voice quality is stellar. Economies being what they are people want to move from TDM to packet-switched (VoIP). This means just like every other application on your PC, packets get sent only when necessary. The upside is obvious on communication costs. The downside is that at the time you need to send something, the CPU may be too busy to fulfill your need and/or the pipe may be too full to transport the data. This works fine for data. Your web browsing can be "slow" but it still works. Voice packets however, have a "time" dimension that must be adhered to. If the packets don't arrive within the alloted time to be reconstructed into voice they may as well have not been delivered at all because they become useless. Hence, VoIP servers need to be working well below their capacity to ensure they have the muscle to deal with the call at the time it happens. That said, there is a little latitude - remember the "place on the curve part"? There are technologies used to ease the timing problem in the likes of jitter control and echo cancellation. And they work well, but remember that they are both means of correcting errors when they have occurred. It is much better to have excess capacity in the servers so the problems don't occur and need to be corrected in the first place. OK. I think I'm done for now. Somebody else can take over (or refute my comments as there is never a shortage of differing opinions). dbc. -- David Cook Quoting Chriswlan2 <[EMAIL PROTECTED]>: > ... > Only trouble: I'm just outside Calgary... > Sigh... > :-)
