TAKE BACK AND TRANSFER ON A NORTEL

[Guest_imported]

I am trying to inplement a feature in a call center with an opt 81c called take back and transfer.
A toll free call comes in from the MCI cloud and it terminates on on the opt 81c. via a dnis dn. The ACD Q is being monotored by a server that will dermine if the call stays to be processed or tha call gets taken back to the MCI cloud and transfered to another call center in Texas.
If the call needs to be sent back, MCI needs to hear DTMF tones *8 800 789 xxxx 3*. I am using a MRAN card to generate these tones. I can't use the broadcast capability so multiple users can hit the MRAN channel at the same time.
I know the broadcast capability works because I am using it with regular voice messages.'
Does anyone know if this feature has been inplemented on a NORTEL product?
We got this feature to work on a AVAYA system.

I called NORTEL support but no luck.

 

[chaldhanno]

Hi,
I may sound stupid , but i belive miran card is used for recording mesages... right??And for your problem , if you are using symposium server in your call center , u can transfer the call to out side by using "route to" statement.
On my 61c , what i have done is that call lands on a PLDN thru dnis and then automatically gets routed to otheer external call no. hope it helps
Regards
Pankaj

 

[allaboutphones]

You are running into the exact same problem I had with an Opt 81c, MIRAN and Symposium Call Center Server. We were using a different carrier, but the take back and transfer tones were similar. We tried putting the tones and numbers on the MIRAN card, but for some reason, the MIRAN would not play recorded tones. We ended up using some ghost extensions and scripting within the SCCS to accomplish the same thing. If the conditions within the call center required the take back and transfer, we would forward the call to a DN (in the Symposium Script) DN that was set up on a phone with multiple call appearances programmed on it (I think we had 8). We then told the carrier to forward the call No-Answer to the call center in Texas that we were using. Also, in order to accomplish this, we had to have the calls coming in PRI. Basically we were using a No-Answer forward to accomplish the Take Back and Transfer. One of the things that we did not explore was to use some sort of Analog Recording Devices set up on analog stations to play the tones, but you might explore that.

 

[Guest_imported]

Thanks for your idea.
If you invoke the call forward no answer feature, it sounds as if you would re-route the call using a second trunk to call out to Texas. In effect using two trunks for a call.
The idea of the take back and transfer is to use one trunk for the call by letting MCI take the call back and re-route it.
We do have PRI service in this site.
I was able to have a recording of the tones by first recording them on a WAV. file to a flash card, then transfering them to the c drive in the MRAN card.
The feature does work ,but only one caller can use recording at a time. If five users called at the same time, one would hit the recording and the others would wait their turn. the tones are sent in a matter of five seconds. At this time I have three channels with the same tones so three callers be processed at the same time.
I would need about 30 MRAN channels to satisfy the needs of the customer.
The avaya system uses their recording announcement card and they are able to use their broadcast capability. One channel is programmed and multiple callers can use these tone at the same time.

 

[allaboutphones]

That is exactly what we were trying to avoid as well. The call-forward no answer feature that we implemented was a network based feature. If the carrier did not see an answer within 1-2 ring cycles, they forwarded the call to the other location, not our Opt 81c. Our trunks were freed up once the call was forwarded.

For some reason, I could never get an answer why, it would only work with PRI. I figured that it had something to do with answer supervision and the functions built into the switch and the Symposium Call Center Server. One thing to point out - in order to get this to work we had to forward to an actual DN (M2616 set with multiple call appearances). It could not be a ghost, or a command within the call center server scripting. If we did that, it seemed to give answer supervision, and the carrier would not pull the call back.

We used the RAN Broadcast Software in conjunction with the MIRAN. I can't remember exactly how many callers we could broadcast to at the same time, but you could split up that license, and assign, in increments of four, it to each channel on the MIRAN. We had a large volume of callers, so we split up the RAN broadcast and assigned them to multiple members within the same music route (first MIRAN port got 8, second MIRAN port got 8, third MIRAN port got 12, but all were delivering the same message. That way, up to 28 people or so could hear the same message delivered simultaneously through three ports. That way the delay in playing the message was minimizied.

Hope this helps.