Get OriginationNumber in Redirect

[WillBarnett]

Hi, I want our telephonists to be able to transfer an external call to a "dummy" ECR user which takes DTMF information then returns the caller to the original user. However, there does not seem to be a variable which holds the redirector's number so that the system knows where to return the call to. Please could you let me know how to get this information?

 

Alternatively, is there a way for swyx to capture a DTMF string and do something with the information while actually on a call and connected to somebody (for example a credit card number)? This would be the ideal solution but I couldn't see a way of doing that. Maybe I have missed something?

 

 

[Varmenni]

One way would be to us postdialingdigits. If for example:

100 - ECR user

101 -  telephonists 

 

Then you would transfer the call to 100101, and after reading the DTMF you can then transfer the call to PBXCall.PostDialingDigits

[WillBarnett]

Right but the purpose of this is for a telephonist to be able to transfer the caller to a Credit Card Capture User which would request the credit card number from the caller and, once thsi had been entered, the caller would automatically be rerouted back to the telephonist they were speaking to. Surely this must be possible without an elaborate workaround?

[Tom Wellige]

You can take a look into the PreviousScripts collection, to figure where the call came from.

The only problem is, that it provides only the name, not the number from that user.

 

You could use the PBXConfig.GetUserByAddress function to get the number resolved.

 

More tips & tricks can be found here:

 

 

 

 

 

 

[WillBarnett]

Thanks Tom. Before I look at that, it would be preferable to have the user be able to enter DTMF digits while on the live call to the telephonist and have them collected either by a script or via swyxit and delivered to an application such as MS Access. Is there a way we can implement that?

[Tom Wellige]

Just to understand what you want to do:

• you are in a call routing
• the user enters some dtmf digits
• you want those digits somehow passed into a 3rd party application running on the user's machine who finally get the call

Right?

 

That's not too much of a problem.

• gather the digits using the "Get DTMF string" block in the GSE
• use the "Connect To" block to connect the call to the wanted user
• as you can't pass data from a call routing script (which is server based) to the client directly you have to use a small trick: put the "data" into the caller name field and strip it out from there on the client again -> PBXCall.CallingPartyName
• on the client prepare a short Client SDK application (e.g. a few lines of VBscript code) which takes the caller name from the client, strips the provided data from it and calls your 3rd party application
• this script could be call by the "shurtcut" skin element, so you place a button on your skin to call the script

 

[WillBarnett]

Hi Tom,

 

OK that makes sense but it would be even better to be able to get the DTMF digits from the user while on a live call - i.e. without having to transfer them to ECR.

 

The idea is that, when we are taking credit card details, the telephonist can ask the caller to enter the details into their handset while speaking to them (i.e. no transfer) and these digits are then captured by swyxit and available for the telephonist to paste into the application. (The reason for this is to keep the audio recording of calls but preserve the security of card details).

 

It would have to work for incoming and outgoing calls so there would be no ECR to initiate the recording of the dtmf.

 

Does that make sense and, if so, is it possible? 

[Tom Wellige]

For security reasons I wouldn't allow an agent to listen to the DTMF being entered by the caller/customer. 

 

I would let the agent transfer the call to a special ECR script to receive the DTMF tones, and this comes back then as described above. To make it secure I wouldn't add the entered DTMF then to the caller name but just a randon GUID you have stored along with the DTMF code in a database from within the ECR script.

 

This is the most secure way and keeps the agent away from any data that might not be seen by him/her.

 

And this works for incoming and outgoing calls.

 

And this is also the only way I can think of solving this problem, as you don't have DTMF detection on the client.