AMI's shortcomings on MTE and possible solutions

Use camrivox for polycom or snom it runs off the phones local network so your server remain secure without the need to add any server

I have been using it for a while now and it works great

It works with outlook, salesforce not sure about act since it runs on tapi but you could ask em

Thanks Moshe, that is interesting.

The thirdlane dialer supports connecting to:
* a standard asterisk manger interface, which would be insufficiently secure in a multi-tenant environment
* a thirdlane proxy interface, which is potentially sufficiently secure although I don't know anything about the inner workings of this proxy or what it is vulnerable to.

"Thirdlane Dialer can communicate with Asterisk using Thirdlane PBX as a proxy or directly via Asterisk Manager Interface (AMI)."

OutCall is free open source Asterisk/Outlook Integration software that requires access to an Asterisk Manager Interface.

There is a discussion to be had about the trade-offs between integrating at the phone level vs. the pbx level. There are calls that don't even hit phones etc... that indicates integration at the pbx level isn't going anywhere. For the consumer there is a clear advantage to owning phones and software that are compatible and can work with any voip provider, Asterisk or other.

From Thirdlane's Dialer web page:

Advantages of Thirdlane Dialer

When used with Thirdlane PBX, Thirdlane Dialer is the only Asterisk dialer with no need for access to the Asterisk Manager Interface. This makes Thirdlane Dialer easier to configure, and (most importantly) more secure - no more Asterisk Manager credentials on users' desktops!

Alex or Eric, can you confirm some details about how Thirdlane's built in crm screenpops handles this?

The applet which runs in the client's browser connects to the Asterisk Manager Interface.

com.thirdlane.applet.PopManagerApplet.class archive=pop.jar, astjava.jar

Does this use the md5 challenge authentication mechanism or just transfer the password in clear text?

Thirdlane dialer isn't using AMI however on mte it have one major fault that you don't get incoming calls screen pops for calls behind nat except if you do port forward (don't remember port number) and only to one computer where the port is forwarded. Which in return causes crm screen pop integration very tough at best or completely impossible. Since the local dialer is the one initiating the url screen pop not the AMI (not supporting outlook screen pops or tapi)

On the other hand using phone side software like flexor from camrivox eliminates using AMI or a proxy and it integrates with any type of CRM

I have implemented it the last couple of months and so far the feedback is great

I did a packet capture, I found that the CRM screen-pop uses the challenge and the Conference manager interface uses clear text. Can we update the conference manager to use the challenge as well?

Thanks Remi. So to recap thirdlane's features:

* dialer - secure when used in conjunction with Thirdlane's Proxy and not the AMI
* conference manager - TL sends the AMI administrator credentials to the client over http/https and then the client sends the administrator credentials to the AMI as clear text
* crm links - TL sends the AMI administrator credentials to the client over http/https and then the client uses md5 challenge authentication to authenticate with the AMI

So the dialer is secure in that it has... well as thirdlane advertised:

"no more Asterisk Manager credentials on users' desktops!"

However both the conference manager and the crm links both put Asterisk Manager credentials on users desktops.

Alex, are you planning on fixing thes security holes by pointing both the conference manager and the crm links page to the Thirdlane Proxy like the dialer, instead of the AMI?

not the case.. neither the conf manager or the crm link actually communicate over http/https. They communicate over the TCP/5038 port. The thirdlane 'proxy' is nothing of the sort. The TL dialer simply sends outbound commands to https://your.ip.com/asterisk/util.cgi .. its by no means an AMI proxy for listening to incoming AMI message events.

eeman, you mis-read.. here it is spelled out clearer:

The client's browser downloads web pages, conference manager/crm link applets from webmin/thirdlane over http/https.
Once the applet is loaded in the browser, the applet connects to the AMI on TCP/5038 and supplies credentials, thus those credentials must be present on the desktop computer and accessible by the applet, and, more insecure-ly, accessible by a malicious user.

As far as the dialer, the main point is that it supports authenticating with Thirdlane with an extension username and password instead of authenticating with AMI using AMI credentials.

Straight from the dialer page:
"Thirdlane Dialer can communicate with Asterisk using Thirdlane PBX as a proxy... This makes Thirdlane Dialer easier to configure, and (most importantly) more secure - no more Asterisk Manager credentials on users' desktops!"

its not the same thing.. the dialer does not require access to the AMI in order to achieve its goal. for the crm screenpop or the conf manager tool, it must receive a constant stream of ami events. Im not saying the design of a proxy isnt desirable, Ive been asking for that forever; I'm just saying dont misread what the dialer does as some ready-to-go proxy that the other applications can use, they just arent related at all.

I've asked for something similar to what isymphony uses for their client. Until something like that is created I really cant roll out those ami-based features in MTE. Think of the AMI port as the bare exposed dragon scale of Smaug in the hobbit. Left untended it can result in a lot of calamity.

I have also had a few people ask me if Salesforce will work with our hosted pbx which is MTE

Regards,
Andrew