Company Forums » Companies beginning with C » Callcentric > Multiple lines, separate accounts needed? E911?

Multiple lines, separate accounts needed? E911?

No, not for each number unless you want them to route to different phone ports for an ATA or separate ip phone and so forth. I had to do this after I ported a number in. It's kind of a pain. Personally, I would prefer subaccounts that draw from ONE account balance.

quote:

---

For your scenario, using a Polycom IP phone directly, you would need multiple accounts, one for each number. Each account would have an incoming service and an outgoing service to receive an place calls as needed. You may fund each account from a main account, using our agent program (»www.callcentric.com/agent/).

---

Let us know what you discover.

reply to nltech
That's the main drawback of CC but they are not alone in this. Voip.ms is by the far the easiest to set sub accounts with that I have seen. Set up a sub account, assign a DID to it and go.

reply to nltech
I was thinking maybe one account Callcentric and the others on voip.ms. I notice voip.ms has a list of servers on their site. Anyone know if Callcentric distributes servers throughout the country also?

I could not find anything on their site about it. The ip looks like it is in NY somewhere. I plan on doing some traveling with an ATA so was wondering where Callcentric has their servers?

The whole thing of regional servers is fairly unique to Voip.MS.

(If I use the word "gimmick" it would cause a fight).

CallCentric, based in NY, has happy customers all through the USA and Canada, and beyond.

It's truly not like Starbucks coffee, where you need a shop on every block.

Except perhaps for long ocean distances, this amount of latency just is not a significant issue.

reply to nltech
I have three DIDs on one account. I have two other Fredom IP accounts. I use call treatments to direct calls to the appropriate free accounts. I place all calls from the main account and keep it funded.

Unless you want unique caller ID on the outbound calls, this allows me to set up separate VM greetings and more precise call treatments per line. Fredom IP accounts do not get 911 service.

reply to PX Eliezer

reply to Davesworld

Dave,

You may want to re-read my latency related article posted here:

»Re: I'm tired of experimenting. Need solid VoIP recommendation.

I'd really like to find out more about the kind of Internet connection you use because a latency of 200ms (a round trip time of 400 ms) you refer to - Callcentric does NOT have to ANYWHERE on Earth. The largest latency measured on MONITORED and fully controlled Callcentric network is to Canberra in Australia - 240 ms. On the North American continent - the _longest_ latency - to Vancouver is 41 ms.

Speaking of a "common" practice - it's quite UNCOMMON to have multiple sites (unless built for disaster/backup recovery purposes which Callcentric also has plans for). Most largest providers have 1 or 2 sites only. As PX had admitted it above - the concept of having multiple sites had so far been introduced, to my [quite informed] knowledge, by 2 providers only. One of them had quickly understood that it brings no noticeable improvements (not talking about a cheap PR targeting not trained/educated customers) while involves a lot of inconveniences for customers and support personnel when there is a need to "move" a customer from one site to another or when there is an overload/over-subscription of a site... Another provider is still doing so while even expanding the number of sites - I'm sure, only because of either that PR factor or known poor scalability/maintainability related to Asterisk based installations; because, as a telecommunications engineer with 30 years of working experience, I don't see any other advantages, but only problems or potential problems of such a setup. If anyone interested - that may become a material for another thread, but some [rather clear] manifests of those problems have already been discussed on these boards.

At least, one must understand that a [whatever] latency (or RTT) to some "close-by" provider's site means NOTHING because the call itself and its voice (media) MUST travel all the way to the central site which may be 1000s miles away and then, from that central site - to the terminating provider who may be on a different coast (continent) and from that provider it may further travel to another provider who actually terminates the call... Please, don't tell me about the media going directly from one's phone to the terminating provider - that's a BS. I'm sorry if it sounds offensive when I'm naming the things by their names, but this is HOW it actually works.

To give you an example - imagine one's making a call from LA's home to NYC number residing on XO network - that call is received by PacWest (for example) sent via PSTN to XO's CO in NYC then from NYC's CO - to either NYC or Dallas or DC or Chicago or whatever else XO's Sonus NBS (SBC) sending that call to a VoIP provider in question (who currently "owns" that phone number) whose office is [just for explanation sake] in Vancouver. Add to the equation the possible fact that provider's actual customer may be located in Washington (state of). And, on top of the above - add the shared (oversubscribed and thus unstable) IP bandwidth within an average WEB-colo center. Get the idea? What was a factoring role of a provider's having their server located somewhere "closer" to the customer? - I believe one may figure out that the "improvement" factor was zero at best, while becoming rather negative at a closer look. Please note that a carrier like XO will NEVER send a call toward multiple provider's sites, especially when it doesn't even know what site the call should go to. The Tier-1 carrier like XO will deliver a call only to a primary and/or secondary _earlier_ pre-provisioned provider's IP address.

Speaking about calls' termination - at the very best, if the terminating carrier might agree to - a SIP call from a VOIP user in Washington would be received by that "close-by" server and then sent straight to a terminating carrier - let's say XO in NYC (bypassing the Vancouver central site of the VOIP provider) who would send that call to another coast, to a number in LA... well - that would save some milliseconds from necessity to travel all the way up to Vancouver and then back to NYC, but normally - Tier-1 carriers do not agree to such arrangements, at best - they may allow two/three different originating IP addresses... Yes, small, no-tier, wholesale aggregators usually allow multiple IP addresses, but this is another talk about "value" routing and issues related to this one...

So, may anyone show me, where exactly the latency could be so dramatically saved that it would [ap]prove the "geographically distributed servers" concept as a right one? Also, such "savings" would work until the very first moment when a call signaling or recording (for whatever 911 or legal call intercept) might be required (when a central site was bypassed)... then - "caput", the costs associated with potential legal issues/liabilities related to such a "bypass" may be fatal to a provider...

This is why - most, if not all, established providers have only one site for all customers without any geographical arrangements... I was not comparing or analyzing any reliability or construction related factors of keeping and maintaining a geographically distributed network vs. owned, single (or dual) homed, fully controlled and managed network.

Ok, fair enough. It was 200ms (not 400ms) VOICE round trip as read by the ATA so I think I believe I was mistaken by thinking it was the round trip to your servers. Sorry about setting off a firestorm here! Doing a raw ping I get this as of now. It's quite short actually. Vancouver BC is two hours north of me.

dave@binford2000:~> ping -c4 ping.callcentric.com
PING ping.callcentric.com (204.11.192.10) 56(84) bytes of data.
64 bytes from www.callcentric.com (204.11.192.10): icmp_seq=1 ttl=246 time=89.3 ms
64 bytes from www.callcentric.com (204.11.192.10): icmp_seq=2 ttl=246 time=89.7 ms
64 bytes from www.callcentric.com (204.11.192.10): icmp_seq=3 ttl=246 time=88.0 ms
64 bytes from www.callcentric.com (204.11.192.10): icmp_seq=4 ttl=246 time=88.8 ms

--- ping.callcentric.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 88.062/88.989/89.723/0.651 ms

Traceroute:

dave@binford2000:~> traceroute callcentric.com
traceroute to callcentric.com (204.11.192.31), 30 hops max, 40 byte packets using UDP
1 cobaltcop.local (192.168.5.1) 0.373 ms 0.276 ms 0.264 ms
2 10.36.5.1 (10.36.5.1) 157.592 ms 156.512 ms 155.380 ms
3 G4-1-2201.STTLWA-LCR-02.ncnetwork.net (184.19.242.186) 154.249 ms 153.122 ms 151.991 ms
4 so-6-0-0-0.SEA01-BB-RTR2.verizon-gni.net (108.57.128.196) 150.838 ms 149.719 ms 148.689 ms
5 0.so-7-1-0.XT2.SEA7.ALTER.NET (152.63.105.61) 147.570 ms 146.447 ms 145.311 ms
6 0.so-1-0-0.XL4.NYC4.ALTER.NET (152.63.64.126) 233.016 ms 231.919 ms 230.839 ms
7 GigabitEthernet7-0-0.GW18.NYC4.ALTER.NET (152.63.22.229) 217.754 ms 226.548 ms 233.473 ms
8 internap-gw.customer.alter.net (65.217.199.202) 157.601 ms 156.739 ms 155.607 ms
9 border2.po1-20g-bbnet1.nym008.pnap.net (216.52.95.3) 251.852 ms border2.po2-20g-bbnet2.nym008.pnap.net (216.52.95.67) 250.702 ms border2.po1-20g-bbnet1.nym008.pnap.net (216.52.95.3) 249.605 ms
10 core7.ge3-1.nyc-nym008.phi.pnap.net (216.52.93.222) 151.078 ms 155.306 ms 166.169 ms
11 border27.po1-2g-bbnet1.nyc.pnap.net (209.191.128.96) 173.010 ms 197.872 ms border27.po2-2g-bbnet2.nyc.pnap.net (209.191.128.160) 196.720 ms
12 thorn-4.border27.nyc.pnap.net (209.191.130.14) 191.587 ms 202.485 ms 205.384 ms
13 * * *
14 nyc1-ar3-xe-0-0-0-0.us.twtelecom.net (66.192.255.34) 131.304 ms 130.186 ms 129.066 ms
15 alpha3.callcentric.com (204.11.192.31) 127.940 ms 134.758 ms 141.576 ms

Okay - now we're talking about real values: 90ms RTT from your home to Callcentric or, actually - 45ms of latency (half of RTT) according to your "ping" utility.

A trace-route is kind of interesting/revealing too - it shows around 155 ms of RTT to just a first actual Internet hop (the first two appear to be "internal" (no public IPs) ends of a point-to-point link of either your provider or your organization). Then it hops onto Verizon's network and hops out to former UU.NET (now also part of Verizon's backbone - alter.net); then it hops out in NYC PNAP in our building and crosses routers of Thorn and Time Warner Telecom (TWTC)- those are the ones we peer directly via local GigE links while the packets travel from 12th floor down to our 10th. Even following the trace-route - the latency to one of our SBCs (alpha3) was between 63ms to 71ms... - not considering X-men whose existence was not clearly proved yet (), no human ear can "hear" that latency.

Off topic - a trace-route measures RTT in a slightly different way than the "ping" does - this is why [I believe] there was a difference in your measurements. Overall - you presented our average and standard, "perfect" picture. This is how it should be. The same timings we have to most places in Europe and South America.

And, from right that same data-center, we terminate (or originate) calls straight to most Tier-1 national and international TDM networks (11 Broadway where our own/TWTC/XO/Thorn/Starlan/Verizon' data-centers are located and 25 Broadway - a NYC Telehouse where most Tier-1 International telco's co-located are separated by a single wall with wires/fibers going straight to/from).

I sometimes mistakenly call rtt latency which confuses these discussions.

Interesting as far as perceptible lag. I was at work last night and one of my co-workers on a different aircraft was doing a radio check as part of our avionics preflight on one of our 777's. No one was in yesterday in the Boeing tower so he called me on my cell to ask me to go talk to him from the 777 that I was working on. We had our cells still connected and on one ear while talking on the radios from the two aircraft. The cell lag was only noticeable when we had our vhf radios operating 500 yards away from each other. We decided to hang up our cells at that point.

Since part of my job is to commission Satcom whenever we get a new aircraft rolled out from the factory, I know what really bad lag is. Especially with foreign customers whose provider uses Perth Australia as the ground station. I call Boeing Radio twenty miles away but it goes to the satellite, then down to the Perth ground station and then via line to Seattle. Both parties know how to talk with known lag but it was weird at first.

reply to PX Eliezer