[Home]

Summary:ASTERISK-14355: [patch] VMWI not sent after every OnHook, only when messages changes from None to Some, or Some to None
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-06-22 05:06:25Date Closed:2009-11-04 15:54:07.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) fix15374-2.diff
Description:In sig_analog.c
Function: analog_handle_event
EVENT_ONHOOK doesn't force VMWI updates any more.

case ANALOG_EVENT_ONHOOK
     switch (p->sig) {
               case ANALOG_SIG_FXOLS:
               case ANALOG_SIG_FXOGS:
               case ANALOG_SIG_FXOKS:
needs                 p->msgstate = -1;  /* force VMWI update */  

As yet 'msgstate' hasn't been handled in the conversion to sig_analog
Comments:By: Doug Bailey (dbailey) 2009-06-24 16:55:58

Access to chan_dahdi's msgstate variable requires a sig_analog callback when it handles an ONHOOK event.  I will probably generate a generic hook event callback that chan_dahdi will use to stim the generation of the MWI spill.
By: Doug Bailey (dbailey) 2009-06-24 17:49:11

Has the introduction of sig_analog.c reintroduced the problem where fsk spills are dumped onto the fxs ports that was corrected in issue ASTERISK-13277?  (If the issue of the msgtate being reset when an ONHOOK event is processed is corrected.)


By: Alec Davis (alecdavis) 2009-06-24 19:14:52

Doug, I now have TDM800P and TDM400P so can test both.

I'm hearing the MWI FSK SPILL on a TDM800P with SVN-branch-1.6.1-r202185M which sig_analog isn't in.

I'd need to verify the MWI FSK SPILL on the TDM400P, I'm sure it doesn't, but will confirm.

------------------------------------------------------
edit: 1.6.2 only has the code to avoid MWI FSK spill.
------------------------------------------------------

Tested 1.6.1 tonight. Heard it on both
The TDM800P does have the spill, with SVN-branch-1.6.1-r202185M.
The TDM400P also has the spill with Asterisk SVN-branch-1.6.1-r203057.

So still need confirm 1.6.2 and Trunk.


By: Doug Bailey (dbailey) 2009-06-25 11:25:17

fix15374.diff adds a callback from the analog signal module to stim the generation of a mwi spill within chan_dahdi.
By: Doug Bailey (dbailey) 2009-06-25 14:10:05

fix15374-2.diff places an additional mwi callback in the init_event handler.  I did this to insure I got an MWI sent to the phone when the other party ended the call.
By: Alec Davis (alecdavis) 2009-06-26 04:15:47

Files have gone! oops perhaps.

Tested SVN-trunk-r203569 on TDM400P tonight, no MWI FSK SPILL heard when going off hook, but as the Spill doesn't happen very often it's too hard to trigger.

With mwisendtype=rpas,lrev it assists with knowing when FSK is about to be sent... The Line reversal is correct.

After patches reappear, will be able to retest.
By: Alec Davis (alecdavis) 2009-06-27 18:01:49

Tested fix15374-2.diff today on TDM400P with Asterisk SVN-trunk-r203569M
Is now sending MWI FSK spill after every OnHook as it should.

If messages are cleared from another extension, the only time the VMWI FSK is sent, is still from the transistion from 1->0 or 0->1 messages. If a CallerID unit has the ability to advise number of messages, then that will only get updated when going OffHook->OnHook at the extension with the CallerId unit.
By: Alec Davis (alecdavis) 2009-06-27 18:08:16

Regarding FSK spills being heard at ringing extension as soon extension is picked up, but.... only when a SIP phone rings it. I could not get an Caller ID FSK spill when another FXS port rang.
By: Doug Bailey (dbailey) 2009-06-29 20:37:30

I don't know why it would not be generating the MWI on the addition of another message.  I need to look at what is happening on the return of has_voicemail as I would expect the number to increment.  

I will need to look at what is going on in the code but will not be back in the office until next week.  At that time I will find out why that is occurring as well as look at the issue with SIP phones.
By: Doug Bailey (dbailey) 2009-07-07 14:12:12

I looked through the issue with the MWI only being sent when the number of messages transitions from 0 to 1 and 1 to 0  (i.e. not sent when the number of voicemails changes to/from non-zero numbers.)  

The has_voicemail function within chan_dahdi eventually calls into the has_voicemail function in app_voicemail.c.  This function returns 1 if there are 1 or more voicemails in the users mailbox which explains the phenomena.  This behavior present in 1.4 so I am assuming that this is the manner that it has always behaved.  (or has done so since commit 134223.)
By: Alec Davis (alecdavis) 2009-07-07 16:08:51

The issue is that a callerid unit clears the MSG indicator when the handset goes offhook to make a call. If you had messages, you now don't know about it, unless you use the 'VWMI line reversal' method.

Also the work we did in https://issues.asterisk.org/view.php?id=14104 to support an ioctl which supported 'number of messages' is now meaningless.

Tzafrir: If your reading this, your comments?
By: Doug Bailey (dbailey) 2009-07-07 16:08:55

If you wanted to send an MWI call for any change in the number of new messages to a mailbox, we could add a call to ast_app_inboxcount in chan_dahdi's has_voicemail function so that it returns the number of new messages.

I'm not sure what the overhead is for making such a call or whether we would want to make a parameter that distinguishes between an explicit message count mode vs an any or none mode.
By: Alec Davis (alecdavis) 2009-07-07 16:16:20

Afterthought:
I don't have test equipment right now (damaged in flood), but I think actually the patch fix15374-2.diff resolved the Off-Hook clearing of the MSG waiting indicator on the CallerID unit, as it's updated after you go back On-Hook.
By: Alec Davis (alecdavis) 2009-07-07 20:44:48

Referring to ETSI EN 300 659-3 V1.3.1 (2001-01)

5.4.14 Number of Messages parameter

<pre><b>Octet   Binary          Hexadecimal     Contents
<u>number  coding          coding                  </u></b>
1       0001 0011       13              Number of Messages
2       0000 0001       01              Parameter length (1)
3       0000 0000       00              No messages
       0000 0001       01              1 message or unspecified number of messages waiting
       0000 0010       02
       to                              Number of messages waiting in the message system
       1111 1111       FF</pre>
The concept of, No messages or some is OK, but shouldn't it support up to 255 messages.

Sorry if formatting doesn't stay in tact.


By: Doug Bailey (dbailey) 2009-07-08 10:18:30

At present we are not using that parameter in the FSK spill that is generated.  Instead we are sending the Visual Indicator Parameter (5.4.7) which indicates a boolean condition.  It's looking more like this needs to be its a selection parameter between sending the number of messages or the visual indicator.
By: Alec Davis (alecdavis) 2009-07-08 15:40:15

After I'd posted the previous note I saw the Visual Indiactor Parameter (5.4.7) and thought, that is what is currently being used.
By: Jeff Peeler (jpeeler) 2009-07-14 15:04:29

Just a heads up, since 206566 I believe the msgstate should be updated properly now.
By: Doug Bailey (dbailey) 2009-08-03 09:35:36

Using trunk with jpeeler's changes, I have noticed that I am getting MWI sent on all my ON-Hook events.
By: Alec Davis (alecdavis) 2009-08-03 14:08:41

Doug:
Trunk isn't ready yet, the sig_analog changes have broken ringtimeout.
refer to https://issues.asterisk.org/view.php?id=15288
By: Jeff Peeler (jpeeler) 2009-10-06 17:51:39

This issue has been resolved and can be closed, right?
By: Alec Davis (alecdavis) 2009-10-07 14:56:20

The MWI FSK needs to be resent after a caller has rung an extension, but aborted the call before the rung extension has answered. The caller ID units I've tested with, the MSG indicator goes out.

The tenant then returns, looks at MSG indicator to find it's out, so assumes no messages.

If you feel this is not related I'll open another bug. Otherwise this can be closed.
By: Alec Davis (alecdavis) 2009-10-26 13:40:56

Checked over the weekend.

This can now be closed.
By: Joshua C. Colp (jcolp) 2009-11-04 15:54:07.000-0600

Closed per reporter.