atcomsystems.ca/forum Forums VOIP Phones & IP PBX VoIP & Cloud Phones, Hosted PBX, General IP Phones What's so good about VoIP phone systems?

Thanks for the input. I can't tell you how nice it is to have level-headed advice in this regard. This forum is excellent in that regard.

Ed, you're correct with respect to our phone system being solid as a rock. We really don't have an issue with it other than the technology is dated. I suspect that any system we install would be a step up in that regard.

As for the management of the system, I am still grapling with how a company of our size handles that. I do plan on doing the MAC work myself, to the extent that I can. I would imagine that most systems can be managed over the network for that work. I would leave the configuration to the experts. Right now we have several different companies providing support for our various phone systems and locations (roughly from New York city to Richmond, geographically speaking).

I suppose it depends on the type of system and whether there's a national company that can handle the support. Of course, I could find local folks in each area to handle the specific pieces, but someone has to know the overall setup.

As far as redundancy is concernered, once we expand the system to cover multiple locations I would like to see a secondary site that could be the failover if the main site's system failed. That's certainly down the road a ways but whatever system I choose now must be able to handle such contingencies.

Phonesol, we do have some small offices with 2-3 people that might well be suited to IP phones tied to the main office. Of course I'd want a backup plan if the network fails.

Thanks again for the information.

By the way Ed, we still haven't signed a lease on a new building yet. I'll send you an email once that happens. We're still looking at space in the Arundel Mills area.

I specialized in Very Large Voice Networks for years when I was with GTE. We had T-1s between sites and used them for intra office dialing, for a common VMS, for TEHO (Tail End Hop Offs)to eliminate or reduce LD charges etc. We also switched data through our voice networks as well as a host of other things.

Sure, you had to pay for the intra-site T's, but you had guaranteed connections that you knew were going to get through.

If you're putting in Data T's between locations and sharing them - what's the difference? As long as you leave enough channels for Voice.

If you're depending on the Internet to route your voice calls and data traffic from location to location - good luck. Sometimes it'll work fine and sometimes it won't work at all.

If that's OK for your business, then go for it.


Sam

Sam, we've got a Qwest PRN (private routed network) for our data connections. The Qwest folks have suggested that we can put QOS on these circuits to accomodate voice. Since we're a Citrix shop, we really only have Citrix and Printing traffic between locations currently, so the QOS should be pretty straight-forward. It makes sense to me to use these lines since we'll be paying for them for data anyway. We'd certainly need to increase the bandwidth, but that cost is incrementally less at higher bandwidths, especially since we're paying loop charges no matter the bandwidth.

I am interested in using the WAN to route calls for the reasons you specified. As far as TEHO is concerned I suppose a system with fairly robust LCR is in order.

Regardless of how you go to the desktop or link remote offices, never use SIP for your trunks. The one exception is if your pulling sip directly from the provider (I.E. Fiber/Copper directly to your provider's gateway, with no internet/etc). A caller getting someone's voicemail usually wont think twice, but a caller getting a fast busy or disconnection message will wonder.

As far as everything else I'd just go hybrid. Get the best of both worlds like others have said. Use TDM where it makes sense and VoIP where it does.

Steve -

Is Qwest's Private Routed Network a "real" network or a virtual one?

Sam

I'm guessing that's what marketing calls MPLS.

Not MPLS to our network, though I believe it is at Qwest's core. It's like an Internet VPN except that the traffic remains entirely on Qwest's internal network. As such, all of our sites are 2 hops from hub to spoke.

We can (and do) have our remote sites configured to use a local Internet hopoff in the event that the hub end of the link goes down - the spoke ends would connect out through the public Internet then to the hub site through a dedicated Internet T1 there. That is just for emergencies though.

I guess that's a long way of saying yes, it's a "real" network, though not in the same light as MPLS or PPP links per se.

Interesting... I'll have to call qwest and have them give me some info then.

Great discussion, and thank you Steve for posting this topic.

I have a question whereby I hope someone can dispel one of my personal doubts about VoIP (and please bare with me, in that I presently work in a strictly TDM environment):

Can someone provide some current info regarding the "truth or myth" about misrouted VoIP emergency 911 calls to the wrong PSAP (Public Safety Answering Point); to include inaccurate delivery of the calling number and location information?

Other than the November 28, 2005 FCC ruling requiring that 911 service be a mandatory VoIP feature, and that interconnecting VoIP providers disclose their full 911 dialing capabilities to their customers, has the potential for these so-called VoIP misrouted 911 call issues been resolved?

Here's what I could find from the FCC website's VoIP/911 Consumer Advisory:

Because VoIP service works differently from traditional phone service, consumers who use it should be aware that VoIP 911 service may also work differently from traditional 911 service. The FCC and VoIP service providers are striving to eliminate these differences, but some of them are:

VoIP 911 call may not connect to the PSAP;
VoIP 911 service may ring to the administrative line of the PSAP, which may not be staffed after hours, or by trained 911 operators;
VoIP 911 service correctly connects to the PSAP, but does not automatically transmit the user’s phone number and/or location information;
VoIP customers may need to provide location or other information to their VoIP providers, and update this information if they change locations, for their VoIP 911 service to function properly;
VoIP service may not work during a power outage, or when the Internet connection fails or becomes overloaded.

Here\'s a link to the entire Consumer Advisory. I'm just curious as to where we currently are with these issues with VoIP's 911 dialing.

I highly value this enormous group's input!

Mike -

This can be a real problem especially if you have users who travel between multiple branches and take there physical phone with them. The problem is the partition the users are in points them to a gateway (route pattern, route list, route group) that is local to where the phone was originally configured. Until recently there was no way to route a call to a PSAP that was local to the gateway they were at. In the Cisco world the solution is Cisco Emergency responder. There are a couple of ways you can do this but the bottom line all of your MAC addresses are automatically routed to the correct PSAP usually by the switch you are on.

https://www.cisco.com/en/US/products/sw/voicesw/ps842/index.html

HTH