[Home]

Summary:ASTERISK-08993: [Patch] SMDI features
Reporter:Patrick Cole (ltd)Labels:
Date Opened:2007-03-12 18:37:29Date Closed:2008-02-25 18:28:02.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) trunk_smdi_features.patch
Description:I found that using the built in SMDI code in production, there were a few problems:

1) When two calls come in at roughly the same time, the SMDI messages generally come in the right order but the calls don't necessarily hit the zap channels in that same order, resulting in incorrect SMDI messages being popped off the queue for both calls. In my setup I coordinated with my telco so that the zap channels I plugged my lines into corresponded to the message desk terminal number field of incoming SMDI MD messages. As such I've included code that matches the Zap channel to the terminal number when you choose to enable it using smdimatchterm=yes in zapata.conf. This solved the issue for me.

2) My voicemail extensions were four digits but the telco switch requires that SMDI messages are in FNN format. I added an mwiprefix option to the smdi config so that when I send MWI operate and RMV messages, the prefix is prepended to the mailbox extension and everything works nicely.


****** ADDITIONAL INFORMATION ******

Reposted with features only as per request by serge-v
Comments:By: Patrick Cole (ltd) 2007-03-14 19:05:13

I'm not confident there is anyone else out there that would be able to test this other than me.  SMDI interfaces are not very common.
By: Serge Vecher (serge-v) 2007-03-15 08:18:18

jaroth: would you be able to test these SMDI features?
By: James Rothenberger (jaroth) 2007-03-15 08:35:46

We will be testing them more in the next few weeks at University of Pennsylvania.
By: Serge Vecher (serge-v) 2007-03-15 08:54:47

jaroth: thanks!
ltd: you are welcome to help jaroth with testing in 9055 ;)
By: Patrick Cole (ltd) 2007-03-15 19:29:42

Nice one jaroth.  Interesting, didn't see 9055.  I'll see if I can help!
By: Patrick Cole (ltd) 2007-03-15 19:33:07

Looking at 9055 it looks like maybe we should try and integrate these two patches into one as there is some overlap for the message queue popping/waiting functions.
Want me to go give it a go or do you want to do it jaroth?
By: James Rothenberger (jaroth) 2007-03-16 12:59:35

ltd - go for it, I'll try to test the change with my SIP integration.
By: Jason Parker (jparker) 2007-11-13 17:27:19.000-0600

Has there been any update here?  I'd like to see this get committed.
By: Patrick Cole (ltd) 2007-11-13 19:44:52.000-0600

Have been running it in production since march and no issues thus far.  I probably won't have time to intregate it with the SIP functionality as indicated previously.   I still think this should be merged, however... I can't imagine anyone running SMDI in production without it...
By: James Rothenberger (jaroth) 2007-11-14 08:37:12.000-0600

We are trying to get a test environment (with SMDI) set up so we can test the patch with the latest SVN trunk.   The test environment should be finished this week.
By: Russell Bryant (russell) 2008-02-25 18:17:29.000-0600

I actually have a set of significant changes to SMDI support that I am about to merge in that addresses these issues.  I did all of my work before I even saw that this issue existed.  However, thank you very much for your patch!
By: Digium Subversion (svnbot) 2008-02-25 18:21:51.000-0600

Repository: asterisk
Revision: 104119

U   branches/1.4/apps/app_voicemail.c
U   branches/1.4/channels/chan_zap.c
U   branches/1.4/configs/smdi.conf.sample
U   branches/1.4/include/asterisk/smdi.h
U   branches/1.4/res/res_smdi.c

------------------------------------------------------------------------
r104119 | russell | 2008-02-25 18:21:50 -0600 (Mon, 25 Feb 2008) | 33 lines

Merge changes from team/russell/smdi-1.4

This commit brings in a significant set of changes to the SMDI support in Asterisk.
There were a number of bugs in the current implementation, most notably being that
it was very likely on busy systems to pop off the wrong message from the SMDI message
queue.  So, this set of changes fixes the issues discovered as well as introducing
some new ways to use the SMDI support which are required to avoid the bugs with
grabbing the wrong message off of the queue.

This code introduces a new interface to SMDI, with two dialplan functions.  First,
you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access
details in the message using the SMDI_MSG() function.  A side benefit of this is that
it now supports more than just chan_zap.

For example, with this implementation, you can have some FXO lines being terminated
on a SIP gateway, but the SMDI link in Asterisk.

Another issue with the current implementation is that it is quite common that the
station ID that comes in on the SMDI link is not necessarily the same as the Asterisk
voicemail box.  There are now additional directives in the smdi.conf configuration
file which let you map SMDI station IDs to Asterisk voicemail boxes.

Yet another issue with the current SMDI support was related to MWI reporting over
the SMDI link.  The current code could only report a MWI change when the change
was made by someone calling into voicemail.  If the change was made by some other
entity (such as with IMAP storage, or with a web interface of some kind), then the
MWI change would never be sent.  The SMDI module can now poll for MWI changes if
configured to do so.

This work was inspired by and primarily done for the University of Pennsylvania.

(also related to issue ASTERISK-8993)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=104119
By: Digium Subversion (svnbot) 2008-02-25 18:28:02.000-0600

Repository: asterisk
Revision: 104120

_U  trunk/
U   trunk/apps/app_voicemail.c
U   trunk/channels/chan_zap.c
U   trunk/configs/smdi.conf.sample
U   trunk/include/asterisk/smdi.h
U   trunk/res/res_smdi.c

------------------------------------------------------------------------
r104120 | russell | 2008-02-25 18:28:01 -0600 (Mon, 25 Feb 2008) | 41 lines

Merged revisions 104119 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r104119 | russell | 2008-02-25 18:25:29 -0600 (Mon, 25 Feb 2008) | 33 lines

Merge changes from team/russell/smdi-1.4

This commit brings in a significant set of changes to the SMDI support in Asterisk.
There were a number of bugs in the current implementation, most notably being that
it was very likely on busy systems to pop off the wrong message from the SMDI message
queue.  So, this set of changes fixes the issues discovered as well as introducing
some new ways to use the SMDI support which are required to avoid the bugs with
grabbing the wrong message off of the queue.

This code introduces a new interface to SMDI, with two dialplan functions.  First,
you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access
details in the message using the SMDI_MSG() function.  A side benefit of this is that
it now supports more than just chan_zap.

For example, with this implementation, you can have some FXO lines being terminated
on a SIP gateway, but the SMDI link in Asterisk.

Another issue with the current implementation is that it is quite common that the
station ID that comes in on the SMDI link is not necessarily the same as the Asterisk
voicemail box.  There are now additional directives in the smdi.conf configuration
file which let you map SMDI station IDs to Asterisk voicemail boxes.

Yet another issue with the current SMDI support was related to MWI reporting over
the SMDI link.  The current code could only report a MWI change when the change
was made by someone calling into voicemail.  If the change was made by some other
entity (such as with IMAP storage, or with a web interface of some kind), then the
MWI change would never be sent.  The SMDI module can now poll for MWI changes if
configured to do so.

This work was inspired by and primarily done for the University of Pennsylvania.

(also related to issue ASTERISK-8993)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=104120