Please login or register to access secure site features.

Note: By continuing to use DevConnect Program Services you agree to our latest Registered Member Terms.

Sign in using DevConnect ID

Forgot password?

Trouble logging in?

Submit a ticket for Registration Support.

I have an SSO ID

?
sign in

Don't have a DevConnect or SSO ID ?

Create a DevConnect account or join the program.

register now
^
Forum Index » DMCC APIs » send dtmf tones to a terminating extension group call   XML
 
Author Message
SteVio



Joined: 04/12/2013 04:40:27
Messages: 22
Offline

Hello all,

I have a problem with sending DTMF tones via Java DMCC SDK 7.0.0.0.0.288.

Following situation:

The CM has a Terminating Extension Group with 4 members. The members of this group control their phone on a tablet. It is important that every function of the phone is available on the tablet.

The phones are SIP extensions.

Now the problem:

If someone calls the Terminating Extension Group and this call is answered by a group member, I am unable to send DMTF tones.


I get an InvalidObjectStateException.

According to documentation, this message means that the call is not established.

I then checked in what status the call is:

Connected [9669503: QVL :: 0] 2828: 9669503 (caller)

Connected [9669501: QVL :: 0] 2828: 9669501 (answering device, DTMF sender)

Connected [9669505: QVL :: 0] 2828: 9669505 (recording port)

Using the buttons on the phone to send dtmf-tones is possible. It is also possible to send a DTMF tone from the caller. Unfortunately this is only possible in my test environment because I can not control the caller in the productive environment.

The DTMF tone to be sent opens the entrance door of the building.

I know the situation is very special, but maybe someone has an idea how to solve the problem via TSAPI.

Regards

Stefan
MartinFlynn



Joined: 30/11/2009 05:00:18
Messages: 1769
Offline

How are you sending the DTMF? Are you using a Call Control function or a First Party function (e.g. pressing a button)?

Martin
SteVio



Joined: 04/12/2013 04:40:27
Messages: 22
Offline

Hi Martin,

i use the callControllServices:

LocalDeviceID sendingDeviceId = new LocalDeviceID();
sendingDeviceId.setStaticID(getDeviceIdByExtension(sendingDevice));

ConnectionID dtmfConnectionId = new ConnectionID();
dtmfConnectionId.setCallID(callId);
dtmfConnectionId.setDeviceID(sendingDeviceId);

GenerateDigits generateDigits = new GenerateDigits();
generateDigits.setConnectionToSendDigits(dtmfConnectionId);

generateDigits.setCharactersToSend(tone);
features.getCallControlServices().generateDigits(generateDigits);


In normal cases like this works very well (for example external callcenter with collect digits). Just with a call over the terminating extension group this does not work.

As far as I know pressing a button does not work on SIP - Phones.

Regards

Stefan
JohnBiggs



Joined: 20/06/2005 14:06:52
Messages: 863
Location: Thornton, CO
Offline

Enable TSAPI tracing on AE Services. There are instructions in the DevConnect Product FAQ "What is the procedure for enabling and accessing the AE Services logs for TSAPI (trace, tracing, g3trace, csta_trace)?". It is in the "FAQ: AE Services TSAPI -> General" section.

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?).

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).

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.

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)?
[WWW]
SteVio



Joined: 04/12/2013 04:40:27
Messages: 22
Offline

Hi John,

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
InvalidObjectStateException
. 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

  • Call Park

  • Call unpark

  • Call Transfer

  • Call Conference


  • all without problems.


    Regards

    Stefan

    MartinFlynn



    Joined: 30/11/2009 05:00:18
    Messages: 1769
    Offline

    I ran a quick test in my lab using the DMCC Dashbaord and I was able to send DTMF using what I think is the same setup as you.

    The only way that I was able to reproduce your error was if I sent DTMF using an incorrect CallID.

    The only difference AFAICS is that I am using a 7.x system.

    Martin
    SteVio



    Joined: 04/12/2013 04:40:27
    Messages: 22
    Offline

    I've tested it again with the DMCC dashboard. Unfortunately with same result.

    Here the output from the call over Cov A Group:

    
    ---------------------
    Outgoing XML 48
    <?xml version="1.0" encoding="utf-8"?>
    <MakeCall xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
        <callingDevice typeOfNumber="other" mediaClass="notKnown">9669503:QVL::0</callingDevice>
        <calledDirectoryNumber typeOfNumber="other" mediaClass="notKnown">9669400:QVL::0</calledDirectoryNumber>
        <callCharacteristics>
            <priorityCall>false</priorityCall>
        </callCharacteristics>
    </MakeCall>
    -----------------------
    Incoming XML 48 
    <?xml version="1.0" encoding="UTF-8"?>
    <MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
      <callingDevice>
        <callID>2981</callID>
        <deviceID typeOfNumber="other" mediaClass="notKnown" bitRate="constant">9669503:QVL::0</deviceID>
      </callingDevice>
      <extensions>
        <privateData>
          <private>
            <MakeCallResponsePrivateData xmlns:ns1="http://www.avaya.com/csta" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="MakeCallResponsePrivateData">
              <callLinkageData>
                <globalCallData>
                  <globalCallLinkageID>
                    <globallyUniqueCallLinkageID>00002029811497441865</globallyUniqueCallLinkageID>
                  </globalCallLinkageID>
                </globalCallData>
              </callLinkageData>
            </MakeCallResponsePrivateData>
          </private>
        </privateData>
      </extensions>
    </MakeCallResponse>
    ---------------------
    Outgoing XML 49
    <?xml version="1.0" encoding="utf-8"?>
    <GenerateDigits xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
        <connectionToSendDigits>
            <deviceID typeOfNumber="other" mediaClass="notKnown">9669502:QVL::0</deviceID>
            <callID>2981</callID>
        </connectionToSendDigits>
        <charactersToSend>1</charactersToSend>
    </GenerateDigits>
    -----------------------
    Incoming XML 49 
    <?xml version="1.0" encoding="UTF-8"?>
    <CSTAErrorCode xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
      <stateIncompatibility>invalidObjectState</stateIncompatibility>
    </CSTAErrorCode>
    


    Direkt call to the member of the group:

    ---------------------
    Outgoing XML 56
    <?xml version="1.0" encoding="utf-8"?>
    <MakeCall xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
        <callingDevice typeOfNumber="other" mediaClass="notKnown">9669503:QVL::0</callingDevice>
        <calledDirectoryNumber typeOfNumber="other" mediaClass="notKnown">9669502:QVL::0</calledDirectoryNumber>
        <callCharacteristics>
            <priorityCall>false</priorityCall>
        </callCharacteristics>
    </MakeCall>
    -----------------------
    Incoming XML 56 
    <?xml version="1.0" encoding="UTF-8"?>
    <MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
      <callingDevice>
        <callID>2987</callID>
        <deviceID typeOfNumber="other" mediaClass="notKnown" bitRate="constant">9669503:QVL::0</deviceID>
      </callingDevice>
      <extensions>
        <privateData>
          <private>
            <MakeCallResponsePrivateData xmlns:ns1="http://www.avaya.com/csta" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="MakeCallResponsePrivateData">
              <callLinkageData>
                <globalCallData>
                  <globalCallLinkageID>
                    <globallyUniqueCallLinkageID>00002029871497442034</globallyUniqueCallLinkageID>
                  </globalCallLinkageID>
                </globalCallData>
              </callLinkageData>
            </MakeCallResponsePrivateData>
          </private>
        </privateData>
      </extensions>
    </MakeCallResponse>
    ---------------------
    Outgoing XML 57
    <?xml version="1.0" encoding="utf-8"?>
    <GenerateDigits xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
        <connectionToSendDigits>
            <deviceID typeOfNumber="other" mediaClass="notKnown">9669502:QVL::0</deviceID>
            <callID>2987</callID>
        </connectionToSendDigits>
        <charactersToSend>1</charactersToSend>
    </GenerateDigits>
    -----------------------
    Incoming XML 57 
    <?xml version="1.0" encoding="UTF-8"?>
    <GenerateDigitsResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3" />
    


    The only difference AFAICS is that I am using a 7.x system.

    I think this may the Problem. On our CM 7.0 it works with h323 endpoints, but with sip it failed.


    Stefan

    This message was edited 2 times. Last update was at 14/06/2017 07:36:49

     
     
    Go to: