[Solved] 3cx phone CTI

[manfer]

I'm trying to use 3cx phone for window in CTI mode connected to a Grandstream GXP2140 IP phone with no luck.

The GXP2140 is connected through SBC to a remote 3CX PBX.

The 3CX phone for windows is installed on a computer on same network, same office where the phone is located. It is besides the same computer that holds the SBC.

I edited cti_template.xml and I have custom template for GXP2140 phone on remote 3CX PBX.

The GXP2140 phone have been properly provisioned from the PBX and the 3CX phone for windows has been properly provisioned sending the configuration file by email from the PBX.

From the computer I have opened a browser and tried the CTI directly:

http://203.0.113.1/cgi-bin/api-send_key?passcode=passcode&keys=SPEAKER:1:1:1:1:1:1:SEND

And works perfectly. The phone number 111111 is dialed on the phone

But when I try to dial something from 3CX phone for windows it does nothing.

I have made a capture from the phone and I can see that the difference from the GET request I send directly from the browser and the GET request that is sended by 3CX phone for windows is that 3CX phone for windows is adding BASIC authentication with the phone credentials in an authorization header. The passcode is on the GET request parameter already.

The phone replies to 3CX phone for windows GET request with an unauthorized REPLY. I suppose it is because of that authorization header in the GET request.

The same GET request directly from the browser doesn't send authorization header and receives a sucess REPLY.

Now I have no way to try if 3CX PBX, IP phone and 3CX phone for windows in same local network would work the same.

 

[manfer]

Another bug in CTI with grandstream phones which is present long long long ago (since v15 release probably) and seems to be never solved is that the variable

%%dialled_number%%

in cti_template.xml which is replaced by the dialed number contains a trailing colon ( : ) so the http request generated for calls and transfers in CTI mode contains two colons before SEND.

http://203.0.113.1/cgi-bin/api-send_key?passcode=passcode&keys=SPEAKER:1:1:1:1:1:1::SEND

but that's something I solve editing cti_template.xml file. But I can't prevent the inclusion of the authorization header on the http request.

Going to test today v.15.5 SP2 just in case something has changed in that new version.

 

[jem1]

Are you able to provision these phones with 15.5 SP1 or SP2? I know in SP1 the %%value%% seems to have gone missing and causes the provisioning to fail as that variable is used to setup the key types on the GS phones.

Also for CTI, if you sign up to be a reseller, they provide phone templates (though they only seem to work V15 and V14) which include the modified CTI template.

 

[manfer]

Hi @jem1,

Yes I provision the phones with custom templates and the phone is properly provisioned. After the provision the CTI mode on the 3cx phone for windows works as a real CTI instead of just MAKECALL functionality.

And when I capture the CTI http requests that the 3cx phone for windows sends to the phone I can see this last bug I mention of a double colon before SEND -something that is easy to solve just by removing the colon before SEND from cti_template.xml-, and I see that the http request contains an authorization header that -in my opinion- is what makes CTI fail. The authorization header is not needed as the authorization is done with the http query string part of the request URI.

http://203.0.113.1/cgi-bin/api-send_key?passcode=passcode&keys=SPEAKER:1:1:1:1:1:1::SEND

CTI was working properly on v14, was working properly on v15 just taking care of removing a colon from cti_template.xml to avoid the double colon problem. Don't know when it stopped working or if it still works locally.

Not sure if CTI still works for local phones because I'm trying with a phone connected through SBC. I could try to install a free 3cx phone system on premise in a virtual machine to test it locally. Now I have none for testing.

But, as the phone gets the http request in my SBC connected phone -request reaches the phone with the unneeded authorization header that makes it fail-, nothing makes me think it will work differently locally.

 

[jem1]

Yeah we have ran into CTI problems with 15.5 and 15.5 SP1, we have one customer who's CTI isn't working at all. I haven't been able to figure out why, it just sends the CTI request to his mobile app from the desktop app all the time, they have 2160's.

I'll have to take our spare 2130 home and try it as I put SP2 on there. I'm curious that your 2140 has no provisioning problems, maybe because it has no BLF keys without the sidecar.

 

[manfer]

I'll have to take our spare 2130 home and try it as I put SP2 on there. I'm curious that your 2140 has no provisioning problems, maybe because it has no BLF keys without the sidecar.

I provision 2130 phones on a client with BLFs without problem since v14. My problem is CTI but the templates works correctly.

I upload the template directly to the templates folder just in case.

\ProgramData\3CX\Instance1\Data\Http\Templates\phones\

After uploading to this folder I restart 3CX services and the template is ready to be used (or restart the server if the template is not available just restarting the services). The only problem is that this way the template is not included on backups if I'm not wrong.

I have not been able to make it work on the CustomTemplates folder inside provision folder.

\ProgramData\3CX\Instance1\Data\Http\Interface\provisioning\xxxxxxxxxx\

On the other hand firmware files work correctly from the provision folder

\ProgramData\3CX\Instance1\Data\Http\Interface\provisioning\xxxxxxxxxx\firmware\grandstream\

Just need to upload the new firmware file and reboot the phones and they are updated.

* The paths are for 3CX phone system for Windows. Don't know the paths for linux version.

 

[manfer]

By the way the two colons problem is probably there since v14. But grandstream older firmwares were able to deal with that problem and accepted two colons in a row dialing the correct phone number anyway. I recall testing this when it started happening. Not sure which grandstream firmware version started not allowing two colons in a row but it happened long long ago. Now when you try to send a request with two colons in a row the phone sends back an error reply.

The bug is on 3CX cti_template.xml file anyway (or on %%dialed_number%% variable implementation that has an unneeded trailing colon) and not on grandstream firmware.

 

[jem1]

I have the 1.0.9.25 firmware on my 2130. Do you know of a wildcard for the Web UI to allow any IP address for CTI? I keep getting unauthroized even typing in the IP address. I was messing around in the Web UI > Network > Remote Access and GS's documentation doesn't really make clear if a wildcard can be used.

 

[manfer]

By default any ip address can use CTI on the phone as far as I know unless you configure the phone otherwise.

By default Web UI > Network > Remote Access configuration is:

Action URI Support Enabled
Remote Control Pop up Window Support Enabled
Action URI Allowed IP List Blank field

I did some test now and I'm surprised. The CTI GET request from Chrome and Edge success. But from IE and Firefox it receives an UNAUTHORIZED reply. I'm capturing packages from phone to try to figure out what is going on.

 

[manfer]

Ok. I have found than when you log in the web ui of the phone it creates a cookie. That cookie is what is sended in CTI requests from same browser and make it work. Even if you log out the cookie is not deleted and CTI requests continue working.

I will try now to find out if there is any configuration on the phone that makes it work as otherwise it is imposible to make CTI work from 3cx phone for windows.

 

[manfer]

I was wrong. CTI is not enabled by default on newer firmwares. It is disabled by default. You have to set the IPs from which you want to allow CTI on Action URI Allowed IP List

Then when you try to use CTI from that IP a pop up appears on the phone that ask you if you want to allow it or not. If you answer yes CTI will work from there on from that IP.

You can disable that pop up confirmation and make CTI work from the configured IPs just from the first request without confirmation if you disable the option Remote Control Pop up Window Support

Still not able to make it work from 3cx phone for windows. I have to take a look to a capture with correct configuration on the phone.

 

[manfer]

Finally it works. So my only problem was this new behaviour of grandstream firmwares. Now you have to configure the IP from which you want to allow CTI.

And be sure to edit cti_template.xml and restart 3cx services so the edited cti_template.xml start working. The phone has to be provisioned from 3CX phone system so you will have to create a template for the gransdstream GXP phone too.

Edited version of grandstream phones profile on cti_template.xml

  <profile>
    <name>ctiprofile3</name>
    <image>grandstream.png</image>
    <description>CTI template for Grandstream Executive Phones</description>
    <supportedfunctions>
        <supported>CTI</supported>
        <supported>MAKECALL</supported>
    </supportedfunctions>
    <models>
        <model>Grandstream</model>
        <model>GXP1100</model>
        <model>GXP1105</model>
        <model>GXP1160</model>
        <model>GXP1165</model>
        <model>GXP1400</model>
        <model>GXP1405</model>
        <model>GXP1450</model>
        <model>GXP2100</model>
        <model>GXP2110</model>
        <model>GXP2120</model>
        <model>GXP2124</model>
        <model>GXP2130</model>
        <model>GXP2135</model>
        <model>GXP2140</model>
        <model>GXP2160</model>
        <model>GXP2170</model>
        <model>GXP1610</model>
        <model>GXP1620</model>
        <model>GXP1625</model>
        <model>GXP1628</model>
        <model>GXP1630</model>
    </models>
 
    <supportedmodels>
      <ua>GXP1160</ua>
      <ua>GXP1165</ua>
      <ua>GXP1400</ua>
      <ua>GXP1405</ua>
      <ua>GXP1450</ua>
      <ua>GXP2100</ua>
      <ua>GXP2110</ua>
      <ua>GXP2120</ua>
      <ua>GXP2124</ua>
      <ua>GXP2130</ua>
      <ua>GXP2135</ua>
      <ua>GXP2140</ua>
      <ua>GXP2160</ua>
      <ua>GXP2170</ua>
      <ua>GXP1610</ua>
      <ua>GXP1620</ua>
      <ua>GXP1625</ua>
      <ua>GXP1628</ua>
      <ua>GXP1630</ua>
    </supportedmodels>
 
    <cticommands delim=":">
        <option value="make_call">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=SPEAKER:%%dialled_number%%SEND</option>
        <option value="answer_call">http://%%desktopphone_ipaddress%%/cgi-bin/api-phone_operation?passcode=%%deskphone_password%%&amp;cmd=acceptcall</option>
        <option value="speaker">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=SPEAKER</option>
        <option value="bxfer">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=XFER:%%dialled_number%%SEND</option>
        <option value="mute">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=MUTE</option>
        <option value="hold">http://%%desktopphone_ipaddress%%/cgi-bin/api-phone_operation?passcode=%%deskphone_password%%&amp;cmd=holdcall</option>
        <option value="reject">http://%%desktopphone_ipaddress%%/cgi-bin/api-phone_operation?passcode=%%deskphone_password%%&amp;cmd=endcall</option>
        <option value="send_dtmf_0">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=0</option>
        <option value="send_dtmf_1">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=1</option>
        <option value="send_dtmf_2">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=2</option>
        <option value="send_dtmf_3">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=3</option>
        <option value="send_dtmf_4">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=4</option>
        <option value="send_dtmf_5">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=5</option>
        <option value="send_dtmf_6">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=6</option>
        <option value="send_dtmf_7">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=7</option>
        <option value="send_dtmf_8">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=8</option>
        <option value="send_dtmf_9">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=9</option>
        <option value="send_dtmf_*">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=*</option>
        <option value="send_dtmf_#">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=%23</option>
        <option value="press_line_key1">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE1</option>
        <option value="press_line_key2">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE2</option>
        <option value="press_line_key3">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE3</option>
        <option value="press_line_key4">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE4</option>
        <option value="press_line_key5">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE5</option>
        <option value="press_line_key6">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE6</option>
        <option value="press_line_key7">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE7</option>
        <option value="press_line_key8">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE8</option>
        <option value="conference">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=CONF</option>
        <option value="message_key">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=VM</option>
        <option value="headset">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=HEADSET</option>
        <option value="redial">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=SEND</option>
        <option value="record">not yet present</option>
        <option value="DND">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=DND</option>
        <option value="attxfer">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=LINE2:%%dialled_number%%SEND</option>
        <option value="f_xfer">http://%%desktopphone_ipaddress%%/cgi-bin/api-send_key?passcode=%%deskphone_password%%&amp;keys=XFER:LINE1</option>
    </cticommands>
  </profile>

 

[manfer]

Unfortunately CTI works from 3CX phone for windows but not from web client for granstream phones.

I have tried with a Fanvil phone and CTI works on 3cx phone for windows and on web client too.

 

[manfer]

I have the 1.0.9.25 firmware on my 2130. Do you know of a wildcard for the Web UI to allow any IP address for CTI? I keep getting unauthroized even typing in the IP address. I was messing around in the Web UI > Network > Remote Access and GS's documentation doesn't really make clear if a wildcard can be used.

After trial and error I would say that Action URI Allowed IP List value has to be a comma separated list of IP addresses. Don't think it will understand any special notation. No wildcards, no CIDR format to specify a network, ...

 

[jem1]

Unfortunately CTI works from 3CX phone for windows but not from web client for granstream phones.

I have tried with a Fanvil phone and CTI works on 3cx phone for windows and on web client too.

Web client uses USCTA which Grandstream doesn't have on their radar: https://forums.grandstream.com/forums/index.php?topic=29933.0

It's the replacement for the CTI standard. Grandstream is more focused on their product line up than to make their phones work with other manufactures right now, which is why they are addding a lot to the firmware and bugs creeping up all over the place. Their forums kind of show this.

GS is poking their head into more and more product lines ups, it seems they are trying to be another Ubiquiti.

After trial and error I would say that Action URI Allowed IP List value has to be a comma separated list of IP addresses. Don't think it will understand any special notation. No wildcards, no CIDR format to specify a network, ...

There has to be a way for a wild card, that's a lot of manual work when you have deployments with a lot of phones and computers. Guess I'm going to ticket Grandstream and see what they say.

 

[manfer]

There has to be a way for a wild card, that's a lot of manual work when you have deployments with a lot of phones and computers. Guess I'm going to ticket Grandstream and see what they say.

Just in case you don't found it already. I have found a message on grandstream forums that explains you can use any as value on Action URL allowed IP list.

It would be a lot better if it had other aliases like localnets or even better CIDR notation allowed to specify whole networks.

 

[jem1]

Just in case you don't found it already. I have found a message on grandstream forums that explains you can use any as value on Action URL allowed IP list.

It would be a lot better if it had other aliases like localnets or even better CIDR notation allowed to specify whole networks.

Ah hah, thank you! I also disabled the pop up window as it wasn't showing up on the phone and CTI is working like a champ!

I will mention GS support was no help. I asked them if there was a wildcard value for this and they instead asked for captures, firmware version, had me update, blah blah blah, saying 3CX isn't supported with CTI but they are working on it. Bunch of bullocks really.

Also did you notice in 1.0.9.25 they FINALLY fixed the BLF issue? I might be able to update handset firmwares and deploy 15.5 SP1 to customers now that have these phones.