slagburn

I believe the RLS ID is only used in environments where you are sending application messages between the switches, i.e. network ring again, NACD, MWI and so on. Since this looks like an interface to the public network I don't see why any application messaging would be required. All of my public network PRIs interface to a 5E switch and have nothing programmed in the RLS ID field however all of my SL100 PRIs have an entry since we use MWI across the network.

The RCAP (remote capabilities) is something you would have to take up with your provider. Most of my public network PRIs have little to nothing for RCAP but my SL100 PRIs have things like ND (name display) TAT (trunk anti tromboning) and so on to match what is programmed at the SL100. Your provider should be able to provide you with a D-channel 'cut sheet' that shows how they have things configured on their end, most are difficult to read at best and some of the terms don't match up but with the NTP one can usually figure it out.

I don't see anything in your programming that would be causing a problem, as stated above I interface mostly with SL100s and 5E systems so I can't say for sure that it's not causing a problem for you. Are you getting any weird error codes related to PRIs, trunks, force disconnects or timeslots? Sometimes we get conditioned to seeing a certain code and ignore it when it really is causing a problem. Any customer complaints?

Rachelle

No unusual codes have shown up since the start of this new application. I am simply working with data from MAX showing an unusually high amount of Abandoned calls for this local queue. The Delay Before Abandoning report shows calls holding in queue for as much as 128 seconds. This should not be happening at all. The calls are set to IFDN off-site as soon as all agents are busy. I am looking for a technological fix before I dig in to the more esoteric social engineering solutions.

rlc

slagburn

I'm just a simple phone guy so I have no idea what that means.

To recap... is the programing of the queue that is showing the high call abandon?

(Grabbed it from the other thread) If not could you post it please?


Site A programming

TYPE ACD
CUST 0
ACDN 2523
MWC NO
DSAC NO
MAXP 100
SDNB NO
BSCW NO
ISAP NO
AACQ NO
RGAI NO
ACAA NO
FRRT 12
FRT 8
SRRT
NRRT
FROA NO
NCFW 4444
FNCF NO
FORC NO
RTQT 0
SPCP NO
OBTN NO
RAO NO
CWTH 1
NCWL NO
BYTH 0
OVTH 0
TOFT NONE
HPQ NO
OCN NO
OVDN
IFDN 82404206038
BUSY BSY BSY SRC BSY
AENI YES
OVBU LNK LNK LNK LNK
EMRT
MURT
RTPC NO
HOML NO
RDNA NO
ACNT 2523
NRAC NO
DAL NO
RPRT YES
RAGT 4
DURT 30
RSND 4
FCTH 20
CRQS 100
IVR NO

Rachelle

That is the queue YES. Calls are leaving our switch via a 24 line phone bank application called PhoneTree. If the call reaches an actual person and they want to zero out to an agent the calls are Transfered to this ACD Queue. If all agents are busy the calls should immediately go to the IFDN, which is off-site. This works most of the time according to our MTE/MAX reports. We are experiencing a really high Abandon rate and the call length is very short. 2-6 seconds, not even long enough for a ring cycle to be generated. That is why I was looking for a strange disconnect situation or a drop of the call. I am floundering for a reasonable answer.

rlc

Rachelle

Back to an RCAP question:

MAT is showing all of these IFDN calls not only here but it is keeping the trunk open between here and the off-site location. When these calls IFDN the PBX is dialing the AC2+area code+the number. When we connect to the PSTN we are connecting to a DMS250. MCI says that if we have Answer Supervision allowed they will take the call back and hold it up to the new site. Since MAT in our location still keeps a time stamp of the entire call then obviously this call never drops from my site and that is why I get traffic messages about long duration trunk to trunk calls. How do I allow Answer Supervision on an ISDN/PRI route? Would TAT in the RCAP of the DCH clear any of this up?

I know that I keep coming back to this but all roads seem to point this way.

rlc

freddog

Let's see if I've got this straight... PhoneTree places an outbound call to a "customer" and plays a recording- something like "Your prescription for Extra Strength Annusol is ready to be picked up. Press 0 if you want to speak to a customer service rep". If the customer presses 0, PhoneTree transfers them to an ACDN. If all agents are busy, the call interflows to an off-switch DN via the PSTN. In such a scenario, it makes sense that the trunk between your PBX and the customer, as well as the trunk that is used to interflow the call to the off-switch DN, would be held up while the call was in progress. In that case, the PBX is essencially a "bridge" between the customer and the person at the IFDN end. MCI is feeding you crap regarding answer supervision. You would need SS7 service for MCI to take back the call and transfer the customer to someone at the IFDN end. Have you looked at the PhoneTree system as a suspect in the abandons you're experiencing?

Rachelle

Fred:

What is SS7 and is that something that is available? You have the jist of what we are doing. I have thought that it was PhoneTree from day one but, there were obstacles in the PBX too. We needed to allow FTT per set and we needed to make a few other trunking changes. For accurate billing purposes what would you recommend we do about this trunking issue? What other things could be causing the short calls?


rlc

freddog

Tracking the source of those abandoned calls will be difficult unless you're able to duplicate the problem yourself in testing. My guess would be that some customers are pressing 0, to speak to a live person, and just hanging up. The PhoneTree system transfers the call, to the ACDN, before realizing that the customer is gone. What is being queued, then, is a call from the PhoneTree system. From the PBX's perspective, the "caller" is the PhoneTree system, so when the PhoneTree system drops off, so does the queue entry and your system logs an abandoned call of short duration. Again, this is just a guess.

A discussion of Signalling System 7 is rather involved. It's a service that major carriers offer, at considerable cost, and requires an adjunct server at each switch location. With SS7, you provide your carrier a set of rules for routing and re-directing calls to several of your company's office locations. Here's an example scenario...

Customer dials an 800# that goes to an ACDN on your Pittsburgh 11C. Your carrier's switch sees the call, destined for your Pittsburgh 11C, and looks to see if there are idle inbound trunks to your Pittsburgh 11C. Upon seeing idle trunks, your carrier's switch sends the call through. The call arrives at your Pittsburgh 11C, however, all agents, at that ACDN, are busy. Your Pittsburgh 11C then interflows the call, to the IFDN, via an outbound trunk to your carrier. Your carrier's switch recognizes the IFDN number as a DID that goes to your Atlanta 61C. Your carrier's switch then dials the IFDN, using one if its own outbound trunks, and transfers the customer to that trunk- establishing a call path directly from the customer to your Atlanta 61C. Your carrier's switch then releases the trunks to your Pittsburgh 11C.