Where does digital phone service hand off toll-free calls?

There is no guessing at all. By FCC order, every 800 etc. call has to be routed over the carrier that provides the 800 service to the destination phone. Yes, this requires a data dip on every call. There is a database which shows the carrier for every 800 number. The database used to be located in Kansas City. I do not know where it is located now or who administers it.

Wes Leatherock snipped-for-privacy@yahoo.com snipped-for-privacy@aol.com

For the service provided by cable companies, the cableco is a CLEC with its own switch, and the calls are handed off from the CLEC switch. In Illinois, for example, Comcast's CLEC is "Comcast Phone of Illinois LLC" which has a bunch of switches. Given that the cableco's internal bandwidth cost is close to zero, the switches don't have to be anywhere near the customers. I think the one that serves customers in Chicago is in Joliet.

For parasitic Vonage-style VoIP, I've never been able to figure it out. Vonage et al. get phone numbers from a variety of different CLECs, and from the packet traces I've done, it's pretty clear that for incoming calls, they have an IP gateway on the CLEC's switch which is somewhere in the LATA to which the phone number is assigned. (Around here, the CLEC switches are all in Syracuse, even for rate centers 150 miles north.)

But for outgoing calls, I can't tell whether each customer's terminal adapter is programmed to route traffic to the switch that handles its incoming traffic, or they just send all the traffic to the VoIP carrier's switch and it sorts it out.

Sure. They probably had lines to an IXC for the toll calls and POTS lines for local, and the PBX wasn't sophisticated enough to analyze the digits and route calls on its own.

R's, John

As I recall from some experiments with Asterisk and completely providerless VoIP, both Asterisk and some of the under-$100 VoIP phones I was experimenting with could be set up to use E.164 lookups to route calls. E.164 essentially uses DNS queries to find a gateway for a phone number. I could actually find gateways for some of my employer's 800 numbers, and use them. The phone would go down a list of possibilities and give an error if it got to the end without succeeding. Just plug it into any Internet jack (or a WiFi client) anywhere.

Since this is providerless VoIP, this phone didn't have an incoming number. I had to provide a semi-reasonable caller-ID number or it didn't work (123-456-7890 caused the call to be unceremoniously dropped). Since the call was to an 800 number, there was no billing. If an actual provider set up their terminals this way (using E.164, and using it before going to the provider's own gateway) before shipping them to customers, they would have no records of 1-800 calls made (unless they are also on the receiving end). I wonder what the CALEA folks would think of this? (Well, they could track it by IP address and time like other Internet stuff.)

My employer did not have a PBX with a Internet/VoIP gateway, but at the time it was being considered. If they registered it, or privately gave out the gateway information to employees or programmed it into employee/customer phones, it would then be possible to go direct to it without involving any telco *phone* lines at all (except to the extent that the Internet runs on telco lines).

It's run by Neustar and it's geographically distributed, but it's still a reasonable question to ask where the local non-ILEC hands the call to the IXC.

They [Neustar -- ed] also run most if not all of the LNP databases, since all POTS calls require a database dip now, too.

R's, John

All calls? There must be a exchange code somewhere that doesn't have any numbers ported out: doesn't that still mean that the calls to that exchange don't have to be dipped?

** Moderator Note: the 'dip' is done at the originating end. They "don't know" that the exchange doesn't have any ported numbers.

Consider the stiuation where a number from LEC 'A' is ported to LEC 'B'. Now, another customer of LEC 'B" calls that number. If they presented the call to 'A', who did the dip, ound the call needed to go to B, and 'forwarded' it there, there's be two inter-LEC trunks tied up for a call that was entirely local to a single LEC.

Similarly, if somebody from LEC 'C' calls, you end up with two trunks tied up at 'A', one in (C->A), one out(A->B). The 'direct' route (C->B) is much preferable.

Well, OK. A call within the same switch doesn't have to be dipped if the switch knows the number hasn't been ported. Other than that, if there are still exchanges that don't support LNP, they must be very far out in the boondocks.

Our RLEC has supported it for several years, and Time-Warner even has a prefix assigned so they can assign and port numbers to digital cable.

R's, John

In the original LNP implementation, an originating exchange keeps a list of all _other_ exchanges in the NANP, and they're marked as "lookup needed" or "no lookup needed". The originating exchange only dips the national LNP DB if an exchange code is marked "lookup needed", i.e., if at least one phone number has been ported out of that exchange code.

Ergo, my question, which stands.

** Moderator note: *Very* early LNP was done via the 'call forwarding' mechanism, and did result in 2 trunks busy, per above (except in the case of a call originating in the 'home' exchange). This was an incentive for the telcos to get the data-base up, running, and in use. A friend had ported a number very early on, and had some issues with multiple simultaneous calls, due to that mechanism. :)

John Levine wrote: :>> They [Neustar -- ed] also run most if not all of the LNP databases, :>> since all POTS calls require a database dip now, too. :>

:>All calls? There must be a exchange code somewhere that doesn't have any :>numbers ported out: doesn't that still mean that the calls to that :>exchange don't have to be dipped?

:Well, OK. A call within the same switch doesn't have to be dipped if :the switch knows the number hasn't been ported. Other than that, if :there are still exchanges that don't support LNP, they must be very :far out in the boondocks.

It used to, when LNP was first being rolled out at the end of the 20th century, be possible to have a table that listed NPA-NXX pairs that had ported numbers (not just supported them, but which had at least one number ported). That's just a few thousand records, so examining that would save a look up for numbers that you could tell weren't going to have been ported. I doubt it's worth keeping such a table these days, because it would have so many records (save so few look-ups), but I no longer worry about such things, so maybe it is.

On another topic, what is the correct term for these servers that provide VoIP service? Packet routing is done Internet style and won't even hit the telephone network till it gets to the switch serving the dialed number. And if that number is also VoIP, a telephone call hasn't even been made.

There are two functions in VoIP, and they are usually separate and distributed.

The actual one you are asking for is a VoIP Gateway. Cisco has turned their general purpose router platforms into a huge range of them. Other vendors (Quintum, AudioCodes, Patton to name a few) have dedicated boxes. Usually ISDN PRI in/out and an ethernet port. The small user boxes that turn VoIP back to POTS can be called this too.

Then there are also the servers that function as a soft switch with additional services bundled in. Usually a VoIP provider's gateways all register back to the soft switch so it can determine the best routing plan. After the call setups, the VoIP gateways usually are the ones that talk directly to one another in a big mesh. The big players probably run their own code for this function. There are some open source variants such as Freeswitch. Cisco's CallManager software would do this function.

I'm not sure what you mean. Our PBX has a T-1 to the local telco, and it also has a T-1 to a long distance provider. We can hand it off to either one, as the PBX software sees fit. This is the miracle of the digital age.

Now the PBX is smart enough to figure out which of multiple routes is cheaper, all by itself. In fact, some folks might have multiple trunks to different LD providers and route based upon which provider is cheaper on a given call.

--scott

If the call to the toll-free number terminates on a foreign network, why would your long distance provider even accept the hand off in the first place? In your case, I've got to believe it's handed off locally.

I realize I didn't specify that the digital phone service I was thinking of was unswitched on the originating end, but I was thinking about VoIP.

Because telcos live by one precept: never pass down an opportunity to bill someone for something.

--scott

I had no idea this was even allowed. It shouldn't be.

** Moderator note:

It makes no difference to either the party makiing the call, or the callee (who is paying for the cll.

By law, an IXC is require to hand off a toll-free call to the network that services the delivery number, at the 'earliest possible' point.

Furthermore, the long-distance provider has no way of _knowing_ that their customer has other connectivity it could route the call over.

Therefore they 'accept' what was offered, and do the hand-off to provisioning crrier, as is leglly required. They get a petty-cash amount for this -- the same amount which would otherwise have gone to the LEC, *if* the outbound call had gone over that trunk.