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
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.
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.
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)?
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?
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.
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.
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.
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.
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?
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.
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?
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.
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?
Yes. The script is together with others of mine at http://pbevila.fastmail.fm/public/number2name-anidnis.tcl
I do not charge for it as-is since some saint contributed already to it but if you need further work contact me privately.
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.
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.
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?
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?
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
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.