David, That's probably one of the best explanations in simple terms I have read so far on tdm and voip.
Elliott > -----Original Message----- > From: David Cook [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 29, 2007 9:10 AM > To: Chriswlan2 > Cc: [email protected] > Subject: Re: [on-asterisk] Asterisk server strategies: > multiple newbie unknowns!... > > > 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... > > :-) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
