Bob Bosiljevac wrote:
> Basically, I want to be able to detect that there is voicemail
waiting
at the CO on an FXO port and somehow flash the message waiting light
on an H.323 phone (or any other type of phone)
Interesting concept- but outside the present design principles of
Asterisk. What that would imply is that Asterisk could be bridged (with
configuration, not code) to an external voice mail system- most of the
focus
here is using Asterisk as a voicemail system for other PBX's. While
Asterisk does have a way to indicate voicemail to a given phone (I
haven't
tried an h.323 phone, but it definitely works with SIP and IAX, and it
shouldn't be impossible to make the zaptel driver recognize the
stutter tone
(if it doesn't already, I haven't poked into that source), a whole new
configuration dialect or subdialect would have to be invented to
convey the
message between the two. Simple dialplan should be able to give you a
'one
click to pickup external voicemail' type setup- it's the indication which
Asterisk configs simply don't understand presently.
Nice little project for 1.6, if there's enough interest- I'd put it in
as a
feature request in Mantis.
Even detecting the stutter tone is too late for what I want.
Let me explain my motivation for the request....
We have a legacy POTS based PBX with FXO trunks and FXS station ports on
the unit. It is running a very old release of the software and to
upgrade to a version that will allow me to do VoIP will involve
telephony card, software and licencing upgrades. The existing system
itself works well and does pretty much everything we need it to do
except has no VoIP capabilities. The long and short of it is, that by
upgrading I would gain very little functionally other than VoIP for a
lot of $$$$.
So I thought of putting a Y jack on my station port and running it to an
FXO port on another box running Asterisk. This way when my phone rings
in the office, I can also ring whatever channels I want in Asterisk and
if I make a call from a VoIP channel bridged to by station port, I can
make calls as if I was sitting in my desk at the office. This, by far,
has given me the most bang for the buck and is the quickest, dirtiest
and least disruptive way to get VoIP terminals onto my system. The only
thing missing from my little setup here is the ability to flash my MWI
light on the VoIP phone in my home office when I have a message waiting
on the office PBX. The phone at my desk in the office somehow has the
flashing light; I figured there has got to be a way I can detect it and
pass it on.
The legacy pbx probably uses reverse tip-ring polarity with dc voltage
to cause the message waiting lamp to lite. (There were two or three
different standards for doing this several years ago.) Some systems had
programmable choices in terms of stutter tone verses reverse polarity.
If you're using a legacy key system (as opposed to a pbx), the phones
could be using some sort of proprietary mwi method. Some of the toshiba
key systems are examples of that, but there are many others.
If your phones are truly analog non-proprietary phones, you might be
able to use something like the sipura spa3000 to accomplish the Y jack
approach. I'm not certain whether the spa3k accepts mwi on the fxo port
or not, and their admin manual is not clear on this either. (Note also
that many key systems / pbx's don't provide answer supervision on their
analog lines, causing disconnect issues with ATA's, etc.)
If your pbx / key system can be configured to provide tip/ring reversal
for the mwi, writing driver code for the TDM card to recognize it is
possible. The chip set used on the fxo modules (eg, tdm04b) does have
the capability of recognizing polarity reversal and can be accessed via
code in the wctdm driver. That would likely take someone with experience
to write the driver code to handle it, and there aren't many experienced
driver programmers around.
I don't believe it would be possible/practical to write zaptel code to
recognize the stutter tone. The stutter tone is only present when the
analog phone is off hook. So, the logic would involve taking a line off
hook, listen for a second or so for the stutter tone, go back on hook,
and when detected some additional logic (and config statements) to
determine where to send the event (eg, which sip phone). Some rather
current analog electronic phones actually do that.
In the long run, its likely to be less expensive to replace the legacy
system with asterisk then it would be to implement the driver support
for stutter tone.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
