[asterisk-bugs] [Asterisk 0008587]: [patch] Caller Id and Message Waiting Indicator problems

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=8587 
====================================================================== 
Reported By:                meneault
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   8587
Category:                   Channels/chan_zap
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 48462 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             12-14-2006 08:47 CST
Last Modified:              12-06-2007 16:11 CST
====================================================================== 
Summary:                    [patch] Caller Id and Message Waiting Indicator
problems
Description: 
I've got two issues but i didn't open two bugs because they are quite
related.

Issue 1) In France callerid signalling is V23 and callerid start is RING.
Current callerid works well except when callerid is associated to a
"message waiting indicator"(mwi) message. In this case callerid spill is
just ignored by chan_zap.
It is due to the fact that callerid's mdmf type is 0x80 and callerid with
mwi is 0x82 (mdmf fields are the same). So the patch to callerid_feed is
straight forward.

But well when a message waiting indication arrives it should'nt be treated
as normal call so my patch makes the fxo channel start at 'mwi' extension
if it exist.

Issue 2) Current code try to generate mwi signal to fxs channel when their
mailbox state change. It is using ONHOOKTRANSFER to do so and it doesn't
work for french phones (based on ETSI standard, so it mail fail for others
aswell).
To work, we should ring once to wake up the phone and then transmit mwi
data, no rings should follow the transmission.


I added an option to the native format request so as to ring and stop when
cidspill has been sent, that's 'm' option.
ex:
Dial(Zap/1m), to ring using default cadence and stop after first ring (ie
cidspill is sent).

Dial(Zap/1m1), to ring using custom cadence and stop after cidspill sent
(depending on the cadence)

Message waiting indicator will be set if channel's ${HASVOICEMAIL} is set
to 1.
Message waiting indicator will be cleared otherwise.


In France : 
defining  cadence=250,1500,1500,3000
and then doing Dial(Zap/1m1) works well.

So when mailbox state changed instead of doing an onhooktransfer, we
should Dial (Zap/1m1).

The best way I found to do this and keep backward compatibility is to
launch the pbx in a specific extension.

I added an option to zapata.conf so as to decide what to do when mailbox
state changed for a FXS channel (option called 'onmboxchange').
 - Either 'sendmwi', default mode (for backward compatibility), to send
data using onhooktransfer.
- Or 'jumptomboxchanged', to start the pbx on 'mboxchanged' extension in
the channel's default context. The variable {HASVOICEMAIL} will be set to 1
if mailbox is not empty and set to 0 otherwise. Then the user is free to
decide what to do when it's mailbox state changed.

Ok to sum up:
here's is my config:

zapata.conf

cadence=250,1500,1500,3000
onmboxchange=jumptomboxchanged

extensions.conf

[fxschannel] ;=> that's the extension for my Zap/1 FXS channel
; our mailbox state changed, we will send the mwi to our phones Zap/1
exten => mboxchanged,1,NoOp(Status of mailbox changed ${HASVOICEMAIL})
; timeout is 3 seconds, enough time to send the cidspill
exten => mboxchanged,2,Dial(Zap/1m1,3)
exten => mboxchanged,3,Hangup()
exten => mboxchanged,103,Hangup()

[fxochannel]
; we received mwi from telco provider
exten => mwi,1,NoOp(Got Messages Indication from telco ${HASVOICEMAIL})
; here we decide to send it to our phones
; CALLERID should be valid also if we want to check calling number
exten => mwi,2,Dial(Zap/1m1,3)
exten => mwi,3,Hangup()
exten => mwi,103,Hangup()

====================================================================== 

---------------------------------------------------------------------- 
 meneault - 12-06-07 16:11  
---------------------------------------------------------------------- 
> I couldn't find anything in your code that modified the detection in the
way >you specified, but I believe I did get enough of the generation to
make it >testable.
>
>Basically, it always monitors for new mwi messages

When reading the patch added in trunk, what I see is that mwi is only
checked when the channel has no owner. So I fear it won't work for the case
of ringing. Because when a ring arrives, do_monitor calls handle_init_event
which creates a new asterisk channel owning the FXO channel. Then
do_monitor won't listen again for mwi on this channel because it is owned.

To correct this I think we should only check for mwi when usual callerid
is expected (as my patch did). And then take the appropriate action when
callerid appears to be a mwi message.
See 8587-mwidetect.diff
You'll see what I mean, this is only an example but it should work.
Please note that this patch would be less flexible than my orginal patch.
My original patch let the pbx run into 'mwi' extension, this one does not
run the pbx when callerid appears to be a mwi message.

>In the simplest case, the script could drop a call file which just dialed
>Zap/1m. It would see the m, realize that it needs to only send mwi for
that >call, then hang up afterwards.
Yes this is what I need but I still have the need of having distinctive
ring on 'm' option too. e.g. Zap/1m2
See 8587-mwicall-2.diff

>Did I get anywhere near the requirement?
We are close but... still two issues that my patch handled also.

- The patch added in trunk does not handle the FXS issue only the FXO
one.
When do_monitor notices that a FXS channel has got voicemail it does an
on-hook transfer, something that would only work for US phones... (Because
no ring is generated).
So the other part of my patch is still needed, an option is needed in
zaptel to specify either we want an on-hook transfer or do a custom
handling (my original patch launched the pbx on mboxchanged extension but
we may change this by a call to a script if it is preferred).

- and adding the proper generation of wmi data of course (callerid
information). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-06-07 16:11  meneault       Note Added: 0074968                          
======================================================================