[asterisk-users] Detecting voicemail from CO on FXO port

[Rich Adamson]

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.