<br><br>
<div><span class="gmail_quote">On 11/29/06, <b class="gmail_sendername">Brian Capouch</b> <<a href="mailto:brianc@palaver.net">brianc@palaver.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Complaints are always considered, but calling the developers childish<br>and repeating that complaint over and over in an email isn't likely to
<br>do much to advance the cause you've taken on.</blockquote>
<div> </div>
<div>Sorry about the rant. I apologize for making the childish remark and apologize to any who may have been offended by the remark.</div>
<div> </div>
<div>I apologize for saying Asterisk sucks, and I apologize to the developers for saying Asterisk sucks.</div>
<div> </div>
<div>I'm definitely not saying Asterisk sucks. I wish I had clients a little larger that could really see the same potential as I do. Do I think it sucks? No way. It's great, for me. I made the mistake of pushing Asterisk on a userbase that would have been better off with a system from Office Depot. However, their system integrates into a much larger system. Again, should have put in analog ports and hooked the Office Depot system up to it.
</div>
<div> </div>
<div>I guess my point is that there are a few, and really only a few, things with Asterisk that if we/the developers/whoever can come up with a better way of doings things, would make Asterisk perfect for small installations as well as medium installations.
</div>
<div> </div>
<div>It almost seems like we have a large enterprise pbx system for small businesses. I say that because a lot of people would say Asterisk is not designed or maybe can't handle an enterprise installation (I don't know, and have no experience, I'm assuming because enterprises want multiple redundancies builtin). But, the features that small businesses most often use, are not included.
</div>
<div> </div>
<div>But, for what it's worth, there was kind of a kludge of things put together over on the Asterisk forums that worked nicely with the Grandstream phones. I abandoned them because of audio distortion. It required only pressing Transfer, then the parking spot button that you want the call transfered to. To pick it up, press the button. You even had the status of the spot showing if it was available or not.
</div>
<div> </div>
<div>The question is what is the best interface? On our old system, we put the caller on hold, went to another phone, pressed pickup and then entered the extension where the call is on hold. I never liked that, especially if I was at an extension that wasn't mine. By the time, I got to where I needed to be, or someone called me and told me to pick that call, I would forget what extension. The same thing, I believe, will happen with the current park method. I don't know what would help with that, maybe better vitamins to prevent memory loss? :-) I don't know. Maybe a receptionist console that could tell who is on park, their phone number and caller id info along with who put them on park?
</div>
<div> </div>
<div>I'm wondering if maybe we are looking at having to have different ways of doing it. Being able to transfer the call to a line button, and being able to press that line button to pick up the call, and having the status shown, may be the better solution for small companies.
</div>
<div> </div>
<div>I'm going to show my ignorance here. Since the phone displays the number we dialed,or the incoming caller information on the screen (we're talking those with displays), is there anyway to have it so that when the call is parked, it also shows the parking spot the caller is parked on? Kind of like hold does now? I know nothing about the SIP protocol, so I don't know if this is possible or not.
</div><br> </div>