<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I put such a request for enhancement in sometime, and as is seeming to
be frustratingly common for CounterPath, it was completely ignored.<br>
<br>
Were it not for the Plantronics CS-50 headsets that we bought that have
support in a <i>very</i> limited number of softphones, I'd be dumping
EyeBeam <i>and</i> X-Lite like the sack of crap that it's proving to
be.<br>
<br>
<br>
Steve Davies wrote:
<blockquote
 cite="mid:5caa9b870704201026x6d4c1e20u1186db4e821b0590@mail.gmail.com"
 type="cite">On 4/20/07, James FitzGibbon
<a class="moz-txt-link-rfc2396E" href="mailto:james.fitzgibbon@gmail.com">&lt;james.fitzgibbon@gmail.com&gt;</a> wrote:
  <br>
  <br>
I went around this loop with CounterPath a couple of months back. It
  <br>
seems that their idea of provisioning revolves around customising the
  <br>
software before selling it, so that it is locking the end-user into
  <br>
using "your" (the seller's) SIP server.
  <br>
  <br>
They had trouble understanding that the user just paid money for this
  <br>
software, which they want to be provisioned by a server on their own
  <br>
network, and they do not support this. I gave up at this stage, but
  <br>
perhaps if more people apply pressure, it will become possible to
  <br>
extend their current (quite useable) provisioning interface, but have
  <br>
a user-configurable setting to determine where the configuration is
  <br>
fetched from. At present the configuration server setting is fixed at
  <br>
compile-time by CounterPath.
  <br>
  <br>
</blockquote>
</body>
</html>