Take a look at the g3trace information and verify that an Established event is being sent to the JTAPI client when the member of the TEG answers the call (what are you monitoring the originator of the call or the TEG members? - who are you sending the SendDTMF request on behalf of - the originator or the TEG member?).
The established event is sent. The client can not send a dtmf tone before it gets an established event from our server. I monitor the TEG members and the answering member send the dtmf tone. We have a server application which is connected to the aes. This application monitors the endpoints. And only if we get an established event the clients can do stuff with the call (hold, park, transfer, hangup)
You indicate this works fine when the TEG is not in the call path. I want to double check that it works fine with a SIP endpoint as the destination party, and that you are sending DTMF on behalf of the destination party (TEG or stand alone station).
All my endpoints are SIP endpoints.
There were a lot of issues in Communication Manager 7.0 with SIP and TSAPI. What release of CM are you working with? If at all possible I would recommend testing with CM 7.1 or CM 6.3.3.
We use CM with version: R016x.03.0.124.0
TEGs are a fairly esoteric feature; can you try with a coverage answer group, with a unregistered principal extension that has cover ALL enabled (admittedly that isn't quite the same functionality as a TEG)?
I try this with same result. Sending dtmf tone from the answering endpoint (member of the coverage answer group) failed with
. I have tested this in 2 different ways.
Caller is member of this group, too
Caller is not member of this group
In both cases the caller can always send dtmf without problems, with the same function the answering device used.
I also try other call-actions from the answering endpoint (member of the cov a) just to test if there are problems with other functions
all without problems.