jack

Can you explain this in a bit more detail?

You may be able to achieve this via Nars/Bars, but before I can say need to understand what you are trying to do better.

Jack

Twisted

MR. Jack....How R U. I would bet they are trying to insert a PIC Code and that can be done in BARS (You knew that).

tim_abney

That description is all I got.


I don't think its as simple as inserting digits via NARS?????

Maybe though, I'll have to see if I can get more detailed info from the customer.

Maybe

Del 0
Inst 800xxx-yyyy is there a pause charachter? I don't remember.

jack

T,

All good my friend, they are keeping me a wee bit busy lately though

Tim,

This may or may not be possible, get the details and we can go from there.

Jack

tim_abney

OK here's the call flow from the customer. It looks really ugly and cumbersome, I wonder how much the saving will be after offsetting the equipment and labor to set this up.

Definitely not a NARS fix

here is a call flow of the automated
> debit card spoofing application we talked about on the phone.
> The calls to receive this service will be routed to a dedicated trunk
> group on the hardware platform (yet to be determined) which will deliver
> via FG-D a domestic or international Called Number and the ANI of the
> caller. The application will then connect the Calling Party to a
> recording/music ("Please hold while your call is processed" etc.) while
> the application processes the call with something like the following
> scenario.
> * Seize an outbound trunk (SS-7 to minimize already long post-dial
> delay).
> * Send the pre-programmed Debit Card Access Number in DTMF.
> * Wait for Answer from the platform, or a voice prompt (Press 1 for
> English......).
> * Send a "1" in DTMF.
> * Wait for a voice prompt (Enter PIN......).
> * Send the pre-programmed Debit Card PIN Number in DTMF.
> * Wait for a voice prompt (If you wish to make a call, dial ......).
> * Send the Called Number received with the incoming call in DTMF.
> * Send a "#" in DTMF (to cancel final branding)
> * Wait for ringback.
> * Connect Calling Party.
> * Listen for "#" from the Calling Party, passing one, but not a second
> "#" received within three seconds.
> * Wait for release from either end.
> * Disconnect call.
> In this script, the application waits for a voice prompt before continuing
> to the next step, but in manual testing, we were able to add a simple
> pause in between the outpulsing steps, so that may be a simpler option.
> The debit card platform also uses call re-origination which needs to be
> managed so as to disable it transparently. Once a stable call is in
> progress through the debit card platform, a subscriber pressing the
> octothorpe "#" twice within ~ two seconds triggers a prompt to make an
> additional call. A single "#" is allowed to pass to the far end, so this
> application would need to do basically the same thing. During a stable
> call, monitor the Calling Party for a "#" and allow it to pass to the far
> end. If another "#" is received within, say, three seconds, do not allow
> it to pass to the far end. We would like to have a quote and timeline for
> this application (in addition to the other ACD call distributor
> application previously requested) and of course a multiple application
> discount.
> We will need to have a list, which we will manage, of PIN's with
> associated Access Number from which the application will draw based on
> some simple algorithm, i.e. circular, random, etc.
> Also, for billing purposes, the application will need to monitor and
> detect ringback from the far end after processing through the debit card
> platform to supply soft-answer supervision for the IVR call records.