atcomsystems.ca/forum Forums Wiring - Telecom Carriers - Trunks & Services T1's, CSU's and DSU's Question re: plain T1 and caller ID

Have a customer with a plain voice T1 (not PRI). When they make an outgoing call the receiving end gets an "unknown caller" ID. Verizon says this is the way it works. Is this true? Also, can my customer receive caller ID on this T1??
Thanks

The provider at your customers place sends out the number on outgoing calls. The provider at the called location looks up that number in their database and provides it to the called location. That's how it works.

If the called location provider has "Unknown Caller" as the name for that number---then that's what is going to be displayed. Some providers don't make any changes in their database for years. Also, some providers want extra $$ to provide a name. If that called location has refused to pay that fee---then that's what they're going to get for all of the incoming calls---"Unknown Caller".

Somewhat educated guess: A plain old T1 contains 24 channels each at 64kbps availible for data or voice. There is no extra bandwidth availible for extra services like caller ID presentation. A PRI has 23 channels for voice or data and 1 signalling channel to handle signalling functions and extra things possible like caller ID for the 23 channels.

PS: I haven't seen too any PBX's using anything but PRI's.

In cases where trunks are T1E&M, loop or ground start, the LEC can assign an ANI to the trunk group in the Central Office switch and forward it along on originating calls. The terminating switch would check the database for the name associated with the ANI and pass it along to the called party.

Thanks for the input. The service is Verizon, customer's PBX is a Panasonic KX-T1232 rev 4. Looks like it is time for an upgrade to PRI, or maybe SIP trunks

Contrary to popular belief, each channel of a T1 has room for the CID. Remember, it's only presented between the 1st and 2nd ring (and again between 2 other rings 7 & 8?). It requires no overhead data space, it's sent as a modem signal @ 1200 (?) baud. You can hear it with a buttset in monitor mode. HOWEVER, most LECs don't want to mess with it! When we run a PRI to an old Mitel D, we convert it to a T1 with an Asterisk machine at the customer site. And then feed it to the Mitel T1 card. No not a trunk card, a T1 card. And yes, the Mitel 15/16 will display CID on the console. CID works just fine if you provision everything correctly. You must, however, disable trunk 24 on the T1, because there are only 23 on the PRI.
However, sending the CID out will have to be done by the Asterisk, if the Provider won't attach it. In addition, I have been told that there are 2 different CID transmission schemes and not all LECs are willing to deal with both. True, beats me? Maybe someone else knows for sure!

"Back in the day" There was no CID on T-1 UNLESS you had MCI. They had a standard and you could have ANI which is similar to CID. So, Lightninghorse is correct in that there is plenty of bandwidth for the CID data, however, the way Telcos tariff their products, they will never provision CID or ANI on T-1 when they have it on PRI.

Rcaman

With that Panasonic key system you have POTS trunks so there has to be a channel bank owned by probably Verizon someplace. You could just leave the system as is and upgrade to PRI. But I don't believe the 1232 is CID capable (or is there an add on module for it, been a long time).

-Hal

The provider is Verizon, but I think its a part of Verizon that was the old MCI. They have not installed any equipment at the customer's site, other than a smart jack. In fact, the facilities are so old here that the building is served by a lead covered underground cable.
The Panasonic Rev 4 does not support PRI, only plain vanilla T1. For PRI I would have to upgrade it to at least a Rev6, and PRI cards seem scarce and expensive.

Yes, the TD-1232 has optional modules that support CID on a per four-line basis. I agree that there must be a channel bank providing the delivery to the system from MCI (now Verizon Business).

In Verizon New England Telephone territory "xx/HCGS/xxxxxx" as well as "xx/HCGL/xxxxxx" are both used by Verizon Core.

I have a customer who has had a Verizon T1 and channel bank for many years. About a year ago Verizon on their own changed everything out with a new circuit and a new Adtran channel bank.

-Hal

I think that we have the same scenario with circuit IDs. If an order is placed by the end user, Verizon uses HCGL. If an alternate provider placed the order, HCGS is used.

The circuit in question starts with 88HNNC. There is no Verizon equipment on the premises other than the smart jack.
The Panasonic owned by the customer is a Rev. 4 which can handle T1 but not PRI.

Call the telco and have them add a pseudo ANI for outbound calls, typically this is the client's BTN, but can be any number they want (as long as it's available), including toll free 8xx's. Also, make sure the ANI is registered in CNAM's database, otherwise it will show up on receiver's CID as unknown, not available, etc. Either way, this can still happen when calling into rural areas served by a small mom&pop ILEC.

On a somewhat related note, there are telcos that can provide DIDs for most any city in the US -- as a specialized call center type product. And the way it works is that for every outbound call, the CID shows up on recipient's phone as a local number. With the idea being they will be more likely to answer the call.

Both standard 24ch voice T1s and 23ch PRIs can both transmit CID, but it's my understanding that PRIs are somewhat more reliable at it.

Not sure I understand your second question: are you asking if your customer can receive CID on inbound calls?

Isn't it by law providers have to send name, number or both on outbound calls?

Well, yes and no. Yes, each 64K channel of a T1 circuit is designed for 56K of bandwidth for voice communications and 8K for signalling. What happens in the 8K is up to the service provider and the terminal equipment's ability to work with it.

No, you can't monitor an individual T1 channel by connecting to the circuilt with a butt set to monitor for caller ID, or FSK data. If the T1 circuit lands on a channel bank or an IAD that converts the T1 into POTS circuits, and those channels (DS0s) are provisioned for such, then yes, a butt set will work on an individual FXS channel during the initial ring cycle through the monitored burst of data being sent.

One thing that is important here: Most true T1 circuits are meant for long-distance calling only. These circuits originate in toll offices, not end offices. Toll offices are at a layer above the end offices (end offices provide all of the end-user demands), while toll offices just boot high-volume traffic up a level to reduce bottlenecks.

For example (Cities are for figurative purposes only): A customer in Hackensack, NJ mass-calls numbers in Waukeegan, IL for a mass marketing campaign. Using a PRI or POTS services, these calls will originate in the Hackensack end office, bump up to the Newark, NJ toll office, then to the long distance service provider's office, across the LD network that hops through Dallas and Denver, then back down to the local toll office in Chicago that drops it down to the end office in Waukeegan.

A T1 circuit cuts out several steps of this otherwise complicated process. Much like bulk mailing, where the customer does a lot of the pre-sorting before the mail leaves their office, T1 customers are in essence doing the same thing.


Yes and no again. AT&T always had this service as well, in fact their 4ESS toll switches have had it since they were first brought into production.

The key is where the T1 circuit originates. If it originates in an end office, common sense would be to deliver nearly identical capacities with more features as a PRI.

Name delivery has been the issue. T1 circuits via toll offices have always been able to deliver number-only data, but not name data which is considered to be end-office information.

If the T1 is there for the true need for a T1 (direct connection to the long distance network for bulk savings), then the T1 originates in a toll (typically 4ESS) office. Toll switches don't hand down end-user features since mass calling customers really don't care about individual call information. They receive this data in bulk format from their provider anyway.