[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-07-2007 15:32 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-07-07 15:32  
---------------------------------------------------------------------- 
>I've incorporated your 2 new patches.

This sounds great -- I will try to find time this week-end to test them to
be sure everything work as expected -- they look correct from a logical
point of view, it shouldn't prevent us to test them though :)
My last patch on revision 88490 work thus this should work as well.

>I also plan on adding callerid to the mwi packet (should I do that in all
cases? 
>will some phones see the callerid info and freak out?)

This is a good question, I will try to answer with all my knowledge. It
depends on international standards, unfortunately I don't know all of them
(however if you can point me to some US standards about this I would be
happy to study them :)). More than that it depends on telco providers which
add some restrictions on these standards and then at the end of the chain
are phone manufacturers which still have some freedom on the implementation
of these standards.
Another issue is that international standards emerged after telco
standards and thus some telco standards are not complying with later
standards.

What I know about is that we have two possibilities to send mwi message,
either using SDMF format (old Bellcore format) and MDMF format.
Current implementation in callerid.c propose the two, however only MDMF
format is apparently used (in chan_zap.c).
So we may forget about the SDMF format, moreover it cannot represent
caller identification along with mwi.

For MDMF we may choose which fields to generate for mwi, current
implementation   only generate 0x0B parameter which is the visual
indicator, ETSI standard says that this is the only mandatory parameter
others like Date/Time and Caller Number/Name are optional (0x01, 0x02,
0x07).
France Telecom standard states that Date and Time parameter is required,
and my Siemens DECT phone only accepts mwi if Caller Number is present and
equals to '3103' and Caller Name is present and equals to 'Top Message'.

Now to answer your question, normally adding caller number/name to each
message
would not cause any trouble according to ETSI.
However we cannot be sure that some old standard didn't state that MWI
MDMF format would only contain Visual Indicator parameter. I am quite
confident that it is not the case because MWI MDMF appeared after CLID MDMF
and thus every  phone compliant with the latter should accept MWI with CLID
added (even if it only ignores it).

Anyway when you look at my patch (callerid-c_patch...) I decided to let
both modes (MDMF FULL with Date/Time/Number/Name/Visual and MDMF with
Visual Indicator only).
- When calling with Zap/1m1 then MDMF FULL is chosen.
- When this mwi is generated from do_monitor MDMF is chosen (Moreover from
do_monitor thread caller id cannot be fetched and thus cannot be added).

It is up to you to decide what's the best solution, with mine you are sure
that we get backward compatibility.

>I didn't understand your last paragraph. What do you mean the FXS case?
What >purpose does the on-hook transfer serve?

I will try to better explain the issue.

First the FXO case, you will agree that it detects MWI message on a FXO
line and then executes a script -- that's what was added in trunk.
(It could for instance, as you said, light up a FXS phone using Zap/1m1).

But what about the FXS case? a mailbox is usually assigned to a FXS
channel, when there are messages in the mailbox and the channel is not used
then the phone should be warned of this.
In current implementation, chan_zap.c notices that some messages are in
the mailbox, if channel is free then it decides to light up the phone(s)
connected to this FXS channel sending mwi data. 
The method used is an on hook transfer (from chan_zap.c):
ioctl(p->subs[SUB_REAL].zfd, ZT_ONHOOKTRANSFER, &x);

An on-hook transfer is nothing more than a data communication when the
channel is on-hook, in this case mwi message is sent while the phone is
on-hook. In theory this is what is needed.

Unfortunately it won't work for me as this hook transfer is not preceded
by a ring (and caller id not present...). Thus instead of doing this
on-hook transfer I would need some custom generation of mwi (like
Zap/1m1).

In my patches I added an option onmboxchange which handles it:
- either sendmwi which is the default mode -- on-hook transfer-- 
- or jumptomboxchanged which launch the pbx in mboxchanged extension --
for custom generation --
(take a look at handle_mbox_changed in chan_zap-c_patch_trunk_rev88490)

Instead of launching the pbx we could do the same as what was done for FXO
and call a script.
In zapata.conf we should have something like

; option for a fxs channel
onmboxchange=sendmwi
(default mode only on-hook transfer)

or

; option for a fxs channel
onmboxchange=path/to/script
(calls this script when the states of its mailbox changed)

Hope this help... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-07-07 15:32  meneault       Note Added: 0075068                          
======================================================================