Any working SIP-phone on FreeBSD?

Polytropon freebsd at edvax.de
Mon Jun 20 17:44:07 UTC 2011


On Mon, 20 Jun 2011 11:04:28 -0600, Chad Perrin wrote:
> This email actually mentions Skype and SIP phones toward the end.

Much appreviated. :-)



> In general, the simplest possible format to achieve what is actually
> needed is the best option. 

True.



> This means that even LaTeX is usually the
> wrong choice.

LaTeX is for typesetting text (articles, books, technical documents,
maybe even letters) - nothing more, nothing less. I would _not_
claim that it is optimal for log files. :-)



> Does this programmer get to write a simple script to translate to CSV,
> then import CSV into Excel, when the boss turns his/her back?

It's not allowed, and on the "Windows" platform (that the
scrapped PCs run via network), there are no scripting means.
Furthermore, those workstations are monitored (due to
security considerations), surely just sampled, not permanently.
The easiest way would be the required output writer on the
mainframe that could output OpenOffice XML, and that could
then be even exported into some outdated "Excel" format,
if urgently needed.



> An Excel spreadsheet probably would have been easier to use, because of
> the ability to export as CSV.

No. "Excel" is to make rows and columns where you enter the values
you've just read from your desk calculator. :-)



> In this case, it was an HR professional (though what we were doing was
> well outside of that working environment).

Then HR _requires_ the use of a PC (as a tool), those who use it
should be _able_ to use it. In reality, it is hardly the case.



> I think the approach I need to take next time is to create a Web form
> that takes inputs for the values and does not allow the user to touch the
> key names. 

That's good. People like the web. Make sure the web page has some
images, so it is entertaining, and maybe plays some music so the
users feel comfortable. :-)



> When the form is submitted, it creates a plain text file for
> me, or just adds it to the database automatically.  Placing it in a
> browser would make things marginally more effort-intensive for the end
> user than editing a text file directly, but much *much* less
> effort-intensive than creating that four-column format. 

For some settings, I really _dislike_ the use of a web browser as
any interaction is limited to what the browser can actually do.
One example is how the keyboard can be used. Real professionals
prefer it over mouse interaction (as this means a break in the
natural work flow).

Security considerations may also be included when thinking about
migrating some functionality into a web browser.

You could make an icon for the "Windows" desktop that opens a
SSH session (e. g. using PuTTY) where users can enter the data
into a simple dialog program (e. g. using NCurses Forms), and
this program outputs a CSV data file which then gets incorporated
into the database. Just an idea.



> With luck, it
> would never occur to the end-user to copy and paste from the Webpage into
> a Microsoft Word document and send that to me.

Just expect they send you a "HTML" export file they made with
this "Powerpoint". :-)



> If the person in my case had decided to make changes in some image
> editing software, that at least would have been effective (for some
> definition of "effective").  Importing it into a Microsoft Word document,
> however, resulted in nothing getting done until someone else came along
> and asked "Where's the original document?"

It's hard even to understand what "original document" means. I
had a customer (real story again) who wanted to send me a fax,
but then phoned me to tell me that he can't, as the page always
comes out of the fax machine. Meanwhile, I had more than 20 faxes
on my system, all the same page. I needed to ask him: "Do you
assume that faxing works like a tube in a pneumatic delivery
system?" :-)



> As for making telephone calls with the help of a computer . . .
> 
> I do not have high hopes for Skype in the future.  As I think I mentioned
> in an earlier email, I expect Microsoft to "extend" Skype in ways
> intended to break compatibility with non-Microsoft platforms. 

And in the next step, the use of this functionality, integrated
into "Windows", will be a pay-per-use service.



> I also
> expect that, if Microsoft really support Skype rather than just letting
> it die, it will get some MS Office integration "features" added to it
> that will make it the voice chat equivalent of exactly the sort of
> stupidity we have been discussing.

Will be funny to see a worker "working" when we open an "Office"
document. :-)



> An open source equivalent that could be run just as easily from the
> command line as from a GUI and is not dependent upon any specific OS
> platform's facilities in particular would be great. 

General use would be possible, just "Skype" users would be on
a dead end soon, left alone in a proprietary network where
they can't reach anyone else.



> SIP phones and
> Asterisk PBXes are great for what they are, but they do not really
> address the needs of casual voice chatters who want telephone-like
> convenience without having to essentially set up their own telephone
> company offices.

SIP is good when you want to have telephone functionality in
a place where you have some kind (no matter which one) of
Internet access. Together with Asterisk for example, this
enables a multi-location company to create their own intranet
both for computer systems and telephones, so they all "dial
inside", and any location can be reached from the outside
by a systematic set of numbers. Also _changing_ things can
be managed that way easily.

For the end user, in many times a "real phone" (something
with a cradle, a receiver and some buttons) would be the
preferred solution. For a callcenter, on the other hand,
connecting a USB headset to a Thin client to access both
the telephone functionality _and_ the "normal" computer
programs would be better, as both functionalities can
be INTEGRATED in a nice manner.




> Of course, I don't think such a thing can really be entrusted to the
> Linux community these days. 

It should, as this will be part of the future.



> Portability is essentially the last thing on
> the minds of most Linux community developers lately, from what I've seen.

Yes, LATELY...



> So, too, is designing software without making it a monolithic GUI-only
> tool that has far too many useless features in a single application.

I would like to see an approach like gmencoder: A GUI frontend that
makes use of command line tools. As a user of the GUI, you don't
need to have any clue about the command line tools. But in worst
case, they are there, and you can perform the same tasks with
them. You can also do things the programmer of the "GUI abstractor"
didn't think about, so it gives you MORE POWER! :-)

Command line tools, unlike GUI, allow you to automate things,
and finally, this means more profit for a company employing such
a system.



> For portability in particular, consider the problems of XFCE portability,
> and the fact there are people in the GNOME developer community who are
> questioning whether they should bother continuing to consider portability
> in the future.

I exactly thought about that some lines above... Luckily, I
do not essentially DEPEND on one of them, so I should be safe.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...


More information about the freebsd-questions mailing list