T1-CAS and Ghost Calls

Unanswered Question
Feb 7th, 2008


we just implemented a CCME 4.2 (c3825-ipvoicek9-mz.124-11.XW3) solution that for the most part works great. i have however, encountered an issue that ive not seen before. we have a T1-CAS configured and did a connection plar to a hunt group.

now calls in and our are fine however, when phones are idle, they receive rings from the PSTN but its not actually a call. more of a ghost call. this is happening every half hour or so but not too sure where to start.

attached are the debug voice ccapi inout logs i asked the customer to collect. im not a guru in reading the debugs, but it seems to me that the router thinks its an actual call, thus leading me to beleive the issue is signaling. below are the times and extensions that are ringing with the ghost calls. any assistance with this would be greatly appreciated.

7:04pm 22018, 22019

7:24pm 22018, 22019

7:28pm 22018, 22019

7:31pm 22018, 22019

7:38pm 22018, 22019

7:41pm 22018, 22019

7:43pm 22018, 22019

7:45pm 22018, 22019

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (4 ratings)
Paolo Bevilacqua Fri, 02/08/2008 - 01:30

Hi, these traces don't do much to help finding the problem. Check with "debug vpm signal" if there is some trunk activity at the time of the ghost call, and if there is send it here.

a.gooding Thu, 02/14/2008 - 20:29

Got through,

went down to the customer site to see what was going on. I configured the T1 for the full 24 channels, but carrier only had the first 12 channels. channels 13-24 were in a siezed state and this caused the phones to continously ring. reconfigured timeslots to only 12 channels and working fine.

thanks again

ryan_oconnell Tue, 01/13/2009 - 09:41


I'm about to do a T1-CAS to CCME install, and had a few questions. The service the provider is giving us what they call a T1-DEA service from what I found this is the same as T1-CAS but it seems as though there are a few types of configurations for T1-CAS. Can you recommend one that gives us the most functionality (ex: caller ID)?

Thanks Ryan

ryan_oconnell Tue, 01/13/2009 - 09:55

Yeah PRI is not an option, it's a remote area and the services is not provided there. So T1 CAS is all I got

ryan_oconnell Tue, 01/13/2009 - 10:19

Wow, you must have had better experiences with service providers than I had in the past. My experiences have really been trial and error, and asking the service provider for help is like talking to a wall. The reason I'm posting for advice on Net Pro's is to give me something to work with when I do have to bring this circuit up next week.

So has anyone had any experiences with T1-CAS.

What can I expect?

Thanks Ryan

Paolo Bevilacqua Tue, 01/13/2009 - 11:07

Usually, there is no CLID/ANI on T1 CAS, sometime they provide it in the DNIS via * delimited format. Or they could provide it in-band as true CLID for FXO connections.

Not all SPs are like you say. Now if the one you're dealing with is so bad, good luck bringing up the circuit in first place, hopefully during the bring-up phase you will locate an competent individual to talk to.

These individuals are usually well shielded from the general public until when absolutely necessary.

The good news is that the router can support anything they can possibly come up with.

safety2008 Tue, 01/13/2009 - 11:51

Pb Is right, cas usually does not support caller ID. I am in fact in the process with Verizon of changing or cas t's over to pri's to support clid.

ryan_oconnell Tue, 01/13/2009 - 11:55

Caller ID in both directions I assume. So what does the users see? "Unknown"? And when you say CAS "usually" doesn't support caller ID, does this mean if you can not get Wink-Start feature group d?

So the only other alternative to this service is analog. But the density of lines required is too large. So I guess T1 CAS is the best we can do.

Paolo Bevilacqua Tue, 01/13/2009 - 12:25

Caller-id properly named, is the inband modulation that you have on analog lines. In theory nothing prevents it to be T1 CAS FXO.

In digital telephony, CLID is replaced by ANI, and the called number that you need for DID, is called DNIS. In T1 CAS, these are sent as MF digits with a delimiter like a star. I had to develop a script for that because IOS support for this format was supposed to exist but is broken.

These are ALL sent network to user. User to network, you have full bidirectional with PRI only.

Hope this clarifies.

ryan_oconnell Tue, 01/13/2009 - 12:42

I think follow. I found a reference to a bug where the IOS written for the ISR's do not allow for ANI/DNIS info to be passed in Delimeted format example ani/dnis would look like 5556661234*4447771234.

So did you write a TCL script to make this work?


Nicholas Matthews Tue, 01/13/2009 - 12:23

Hi Arvind,

We see a lot of customers, when forced to use CAS instead of PRI, will use a mix of wink/immediate start and FGD trunks.

Check out this doc:


FGD will allow you to receive the inbound caller ID.

Thus, it's common to see a trunk of half FGD half wink start. They use wink start for outgoing calls, and FGD for incoming calls for caller ID.

As far as the different signaling methods go, wink-start is far more common than anything else.



ryan_oconnell Tue, 01/13/2009 - 12:39

Hi Nick,

The url you provided is for AS58XX hardware, we will be using ISR 2800. So can what you mentioned be done on an ISR as well?

Also when you say mix of wink/immediate start FGD trunks are we saying half for inbound and half for outbound meaning the ones configured for inbound can "not" be used for outbound and same for the other direction?

Paolo Bevilacqua Tue, 01/13/2009 - 12:50

As I mentioned before, FDG for the ISR routers is currently broken (not configurable), for this reason I developed a custom script.

The requisite is that telco can configure it, they may call it something like "delimited format" rather than FGD.

ryan_oconnell Tue, 01/13/2009 - 12:58

Sorry I posted nick before posting my response to you. I think we are on the same page.

So with your script, and if the SP can give me delimiter support, can you get ANI/DNIS and do all the channels work in both directions or do you need to split them into inbound and outbound trunks?


Nicholas Matthews Tue, 01/13/2009 - 13:30

Hi Ryan,

If the provider would send the digits as *ANI*CLID* then you will have problems.

There's an open enhancement for non 5x00 platforms for support of this method.

For more details, you can check out this bug: CSCef51564

Otherwise, you should be able to run FGD on an ISR.



a.gooding Tue, 01/13/2009 - 13:44


the issue was related to the carrier and they had to reterminate thier lines.

Nicholas Matthews Tue, 01/13/2009 - 13:52

Just to follow up on this:

I was a bit unnerved that FGD would be that broken in ISRs, so I went closer to the source. Basically - the *ANI*CLID* format of DTMF caller id more or less a workaround the caller id limitation of cas circuits. This is commonly a premium service that you can get on non FGD/EANA circuits to have caller ID.

For FGD circuits, we should see winks between the ANI and Caller ID so it should be a non issue.

So the script that you've written is designed for CAS circuits that utilize this 'supplementary' feature that some providers use that not covered under normal telephony standards. On the 5x00 series, this native however.

Hope this clarifies a bit.


ryan_oconnell Wed, 01/14/2009 - 07:27

Ok so the long and short of T1-CAS on and ISR here is what I can expect.

ANI will not work unless the SP offers the service and we write a custom script to support the delimeter format

So lets say we don't get DNIS will DID's fail to function?

Again we have to go T1-CAS or analog we do not have a choice of other services int he area. We were thinking of going to T1-CAS for two reasons. To get Analog DID you have lines that are used for inbound only and you need to get more lines for outbound. So to put that much analog in you either need a very big gateway or multiple gateways with a bunch of analog. Very expensive. Second reason is that we were hoping that DID would still work at but is this not the case?


Nicholas Matthews Wed, 01/14/2009 - 07:55

Hi Ryan,

Maybe you missed this part of the discussion - the script is for providers that offer supplementary (non standard) *ANI*CLID* DTMF on CAS links.

You can still receive caller-id with normal CAS FGD circuits. These circuits use a wink system that does not require the DTMF method, and you will be fine running this on an ISR.

You can set up a T1 that is half EANA/wink-start, half FGD. Have the provider route incoming calls to your FGD interface for incoming caller id. Use your EANA or wink-start circuit for outbound calls so that you may send caller ID. You can create both of these on the same T1 controller interface, without additional resources.

Is this more or less what you're looking to do?



ryan_oconnell Wed, 01/14/2009 - 08:07

Yes this is what I'm looking to.

Question, the half that I allocate to be inbound or FGD. Can they also be used as outbound? I was thinking using the EANA for all the outbound but during peak hours have them overflow to the FGD ones if it's possible. I understand Caller-id will be lost for those calls that overflow but at least it gets through

Nicholas Matthews Wed, 01/14/2009 - 08:08

Hi Ryan,

Yes, they are both bi-directional protocols and you shouldn't have problems doing that.



ryan_oconnell Wed, 01/14/2009 - 08:16

Nick and PB

Thanks for your feedback very helpful. I rated your earlier posts.

My next challenge is going to be communicating what I need to provision these circuits to the SP. If I want half FGD and half EANA/wink-start, I hope this will be a none issue.

Thanks Ryan


This Discussion