Apex Code Development You need to sign in to do that
Don't have an account?
jars CTI Toolkit 3.01 - DTMF
Hello all,
I am in the process of upgrading our Salesforce Connector product to Salesforce CTI Toolkit 3.01.
I've seen in the release notes that there's a new message that's supposed to allow supporting DTMF ("New ADD_DIALPAD_NUMBER message to support DTMF").
The problem is that I see no example showing how to make this work. Dial pads, as far as I could see, are always associated with a given operation (DIAL, TRANSFER or CONFERENCE). I find it strange to send DTMF from a TRANSFER or CONFERENCE related dialpad.
Could somebody please redirect me to an example or explain how this new feature should be used?
Thanks!
--
jars
First of all when the call gets connected I must forcefully show the dial pad, this has the effect of hiding all the call command buttons. Not pretty.
That's true, although note that most touch-screen cellphones like the iPhone do the same thing. You don't have to forcefully show the dial pad on call connect, you can make a button that launches the dial pad. That would be much more fluid.
Just to clarify something - in our CTI solution we have no way to send digits without a connected call.
I assumed as much, but when you get these events you can choose how to send the digits (whether it's to init a new call or to send DTMF tones). Still, it's nice to have the option to type in a number and then dial it as DTMF.
I am looking into the CTIAdapterLib project code.
You shouldn't need to modify anything in CTIAdapterLib though, the parameters on these objects are exposed as key-value pairs that you can set from your class extensions.
All Answers
Well you're right, it has to be from the dialpad, although you can choose to bring up the dialpad at any time (it would probably be a DIAL-typed dialpad).
Hello werewolf,
First of all thank you for your answer.
This doesn't feel right; using a dial pad with a button saying "Dial" or "Transfer" to send DTMFs is awkward if not plain wrong.
Sending DTMF should be a separated message, sent from a specific dialpad type. Since this isn't the case it is very difficult to understand the context in which the ADD_DIALPAD_NUMBER message is coming and therefore the easiest is to just send dialtones even if you are about to transfer an existing call (at least in our case this will only happen if and when a call does exist...).
I think that it would be cleaner if we had a new dial pad type just for sending DTMFs and add a parameter to the ADD_DIALPAD_NUMBER message identifying the type of dial pad in use.
For example:
<?xml version="1.0" encoding="UTF-8"?><MESSAGE ID="ADD_DIALPAD_NUMBER"><PARAMETER NAME="DIALPAD_EDIT_ID" VALUE="DN1"/><PARAMETER NAME="NUMBER" VALUE="5"/><PARAMETER NAME="DIALPAD_TYPE" VALUE="DIALPAD_DTMF"/></MESSAGE>
Also there should be a new command button to allow showing this new dialpad. It would work as the other call commands and would show a dial pad just to be used for DTMF implementation.
IMHO this would enable a cleaner implementation.
Thanks,
--
jars
Using a dial pad with a button saying "Dial" or "Transfer" to send DTMFs is awkward if not plain wrong.
Obviously true for transfer, but I disagree with you on the "Dial" one. Why not have the capacity for a user to type in some digits and then press Dial to submit the DTMF tones? I think users generally equate the term "Dial" to emitting DTMF tones.
Since this isn't the case it is very difficult to understand the context in which the ADD_DIALPAD_NUMBER message is coming
...except that by definition you must know what dialpad it is that you just rendered. So yes, it's a tad awkward, but it's not impossible for you to preserve that context.
Also, if you want you can probably add an additional parameter to the dialpad object for that purpose. It will be ignored for the sake of rendering but you can use it to preserve context.
First of all when the call gets connected I must forcefully show the dial pad, this has the effect of hiding all the call command buttons. Not pretty.
That's true, although note that most touch-screen cellphones like the iPhone do the same thing. You don't have to forcefully show the dial pad on call connect, you can make a button that launches the dial pad. That would be much more fluid.
Just to clarify something - in our CTI solution we have no way to send digits without a connected call.
I assumed as much, but when you get these events you can choose how to send the digits (whether it's to init a new call or to send DTMF tones). Still, it's nice to have the option to type in a number and then dial it as DTMF.
I am looking into the CTIAdapterLib project code.
You shouldn't need to modify anything in CTIAdapterLib though, the parameters on these objects are exposed as key-value pairs that you can set from your class extensions.
Hi werewolf,
I accepted your last post as the answer.
I created a button that opens the dial pad for Dial and add it to the buttons shown on call connected. This button then shows the dial pad and when Dial button is pressed the string is passed along as DTMF.
The "new" ADD_DIALPAD_NUMBER message is thus ignored.
Tanks a lot for your input on this issue!
--
jars
Thanks for the solution werewolf. Much appreciated!
@jars - To expand on the intention of the ADD_DIALPAD_NUMBER message, it is fired whenever a number is clicked on a dialpad or entered into the dialpad textbox. A dialpad identifier is sent along with the event, to identify which particular dialpad this number was added to.
For example, if there are multiple lines, and a "5" on the dialpad of line 1 is clicked, a ADD_DIALPAD_NUMBER(NUMBER=5, DIALPAD_EDIT_ID=DN1)
"Since this isn't the case it is very difficult to understand the context in which the ADD_DIALPAD_NUMBER message is coming and therefore the easiest is to just send dialtones even if you are about to transfer an existing call"
Agreed. However, as werewolf mentioned, you know the dialpad you rendered to a great extent.
"I agree with you, but I have two issues. First of all when the call gets connected I must forcefully show the dial pad, this has the effect of hiding all the call command buttons. Not pretty. Further, if we choose to hide the dialpad there's no way to get it back. Perhaps there's a way to change this but I have found no way to do this. The second problem is that the message stated by the release notes to be used for DTMF is ADD_DIALPAD_NUMBER not DIAL - I can ofcourse ignore the former and use the latter but then why inventing ADD_DIALPAD_NUMBER in the first place?"
ADD_DIALPAD_NUMBER allows you to capture a dialpad click event without havintg to click DIAL. As an example, in the case of navigating an IVR on an outbound call, the agent can select an option directly with just 1 dialpad click. There is no need to click DIAL again.
Before CTI-3.01, the only way to get the entered dialpad data was to click the "Dial" button. In addition, you would get the entire dialpad number, the number just clicked as well as the numbers before it.
In your case -
"I created a button that opens the dial pad for Dial and add it to the buttons shown on call connected. This button then shows the dial pad and when Dial button is pressed the string is passed along as DTMF."
The need to click the Dial button can be avoided.
@gvasudev - The need to click the Dial button can be avoided.
In your case -
"I created a button that opens the dial pad for Dial and add it to the buttons shown on call connected. This button then shows the dial pad and when Dial button is pressed the string is passed along as DTMF."
My point is: If you present a dialpad with a Dial button it is strange to think it doesn't need to be there. Another related objection would be, if you want to send a string (by pressing Dial) you shouldn't be sending individual tones when pressing each button - how can we avoid that in the present solution?
I can live with this (I really have no choice, do I? ;) ) but I still think that with a little extra effort by Salesforce the solution would be both simpler and cleaner.
Thanks for your post gvasudev!
--
jars
Another related objection would be, if you want to send a string (by pressing Dial) you shouldn't be sending individual tones when pressing each button - how can we avoid that in the present solution?
Ignoring the ADD_DIALPAD_NUMBER message should allow this.
Many thanks for the feedback. Always useful. We've made a note of it in our backlog.
No I think you may misunderstand the question Gautam.
if you want to send a string (by pressing Dial) you shouldn't be sending individual tones when pressing each button - how can we avoid that in the present solution?
My suggestion is that, if you type into the dialpad and press dial, it should send all the DTMF tones en masse. If you click a button (and you're already on the call) then it should send the DTMF immediately and not add any digit to the text box.
So my suggestion is that you handle ADD_DIALPAD_NUMBER when a button is clicked but then set whatever's in the text box of the dialpad back to its state before the number was added. As it's presently written I think the CTI Toolkit puts that number in the text box using Javascript so you can't just intercept it. So if there's a feature request here it should be a boolean setting on the dialpad that says "don't do anything to the text box when a button is clicked because I intend to handle those button clicks myself." In fact, that should be the actual variable name:
m_bDontDoAnythingToTheTextBoxWhenAButtonIsClickedBecauseIIntendToHandleThoseButtonClicksMyself
and the corresponding method
SetDontDoAnythingToTheTextBoxWhenAButtonIsClickedBecauseIIntendToHandleThoseButtonClicksMyself()
:)
lol @ the method names!
Thanks for the clarification. Will update request.