Aspect/CTI dial DTMF digit problem

[spourdas]

I am trying to provide soft phone capability. Rep calls customer. Rep puts the customer on-hold. Rep dials and plays a VRU message. Rep conferences the customer in. Now, we need to send a DTMF digit to VRU. This works when The VRU is dialed first without using the Aspect phone and the customer (Uniphi Connect). The problem seems to be that once we conference in the VRU line it's trunk does not accept any more CTI commands possibly because the call is now with the Aspect phone. But, the CTI processKey command does not work with the DTMF dial digits?

 

[arznrchrd]

Use the DialDTMFDigits(subtype,callid,trunk,digits) method. Comes with the abcon32 control.

~CIAO~

 

[spourdas]

Thanks. But, DialDTMFDigits(subtype,callid,trunk,digits) is not working for me once I conference in the Aspect call from customer. I pass in the original trunk and the response is that it is not in the right state. (invalid state).

 

[arznrchrd]

What state is the teleset in? Trunk? Do your trunks support this? You sure you are on the right trunk?

 

[spourdas]

1. I dial the customer's number manually on the Aspect phone (Uniphi Connect)
2. I call ProcessKey to put the aspect phone on hold.
3. I call PlaceCall to dial the VRU.
4. I call ProcessKey to conference in the aspect phone.
5. I use noticeCallTrackingInformation to get the dest trunk for the VRU call.
6. I try to call DialDTMFDigits to send a digit to the VRU call. But, it says the call is in invalid state. It does work if the call to VRU is the original call and not conferenced in to aspect phone.

 

[spourdas]

the tele set status is "EQUIPMENT_STATUS_BUSY_OTHER" which makes sense since it is on call with VRU and the customer.

 

[spourdas]

The trunk status is also "EQUIPMENT_STATUS_BUSY_OTHER". With only one call to VRU the status of both the set and trunk are "EQUIPMENT_STATUS_BUSY_OUT" which then accetpts the DialDTMFDigits call.

 

[IndianaSkinny]

The dial dtmf digits is a 517 message on the application bridge. The trunk must be in a "two-way" connected state for this message to be valid.

In a conference call the trunk is in a three-way connected state and thus is in an invalid state for the request. This results in a 117 response message with a response of 'S'.