Summary:	ASTERISK-04136: [patch] [post 1.2] Remote MWI over IAX2 (proposal)
Reporter:	gkloepfer (gkloepfer)	Labels:
Date Opened:	2005-05-10 23:48:59	Date Closed:	2011-06-07 14:04:58
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) mwipatch-head ( 1) rmwipatch.20051023
Description:	This is a proposal for a remote message waiting indication (MWI) using IAX2 and an attempt to bolt-down meaning for a request/reply mechanism for remote MWI over IAX2. As discussed on asterisk-dev, my proposed enhancement works as follows: 1. The "mailbox=" configuration option in the .conf files is extended to allow the following syntax (in addition to the normal extension@context):       IAX2/{iax2-conn-spec}/extension@context As with the original usage, the @context is optional, and the {iax2-conn-spec} is either a user:pass@host or a reference to a peer in iax.conf. So, for example, in zapata.conf, you could have:      mailbox=IAX2/voicemail-server/199   would track the mailbox status for box ASTERISK-196  on [voicemail-server]. 2. the IAX command frame subtype IAX_COMMAND_MWI (that is defined but currently has no formal definition) would be used as follows:         Voicemail server:  serverA         "other" server:    serverB  (where a phone is)     serverB sends to serverA an IAX command frame of type     IAX_COMMAND_MWI with an IE of type IAX_IE_CALLED_NUMBER     containing the extension@context that serverB wishes to query.     serverA receives the frame and uses the IAX_IE_CALLED_NUMBER     data and calls its local ast_app_messagecount to get the count     of new and old messages for the mailbox being queried.     serverA responds to serverB with an IAX command frame of     type IAX_COMMAND_MWI with an IE of type IAX_IE_MSGCOUNT     containing the message count. 3.  The voicemail messagecount/has_voicemail routines in app.c are extended to allow chan_iax2 to register two additional functions to handle the proposed mailbox= syntax enhancement. Limitations/caveats: 1.  I am not sure whether or not I am actually coding the IAX2 protocol commands correctly and there is probably room for improvement over my included implementation. 2.  There is no security, so any device with IAX access can query any mailbox status.  Ideally, part of the peer definition in iax.conf would indicate whether a specific server would be allowed to do remote MWI queries. 3.  I have no idea whether or not there was some other intended use for IAX_COMMAND_MWI that hasn't been made public. 4.  There are scalability issues since the solution is a poll-based solution rather than a push-based solution.  To solve this would require a more in-depth revamp of how MWI is handled within Asterisk in general. 5.  On Zap channels, and maybe others, since the service routine that does MWI polling also provides off-hook indication, a failed voicemail server can cause temporary delays getting dialtone on Zap channels until the local server realizes the remote server has gone away. ****** ADDITIONAL INFORMATION ****** Disclaimer on file. Note again that this patch, while functional, will require additional review and some work before it can be considered ready for integration into a release version of Asterisk.  I am submitting this proposal and patch in the hopes that I could get some assistance with some of the more intricate implementation details and to assure that what I was proposing wasn't entirely wrong. Affects files: asterisk/channels/chan_iax2.c asterisk/apps/app_voicemail.c asterisk/include/asterisk/app.h asterisk/app.c Moves parsing of the comma-separated fields in mailbox= to app.c from app_voicemail.c.
Comments:	By: gkloepfer (gkloepfer) 2005-05-11 01:08:54 Argh, this wasn't supposed to be under project MGCP, but it is...needs to be changed to "feature requests" By: Clod Patry (junky) 2005-05-11 03:21:54 why feature requested if you already made a patch? By: gkloepfer (gkloepfer) 2005-05-12 23:33:03 The reason I made it a feature request rather than just suggesting it as a patch is because I am not confident that the quality of the coding I did is sufficient for inclusion in a public version of Asterisk yet.  Since I am somewhat of a novice at hacking on the Asterisk code, I was hoping for a little peer review of the patch before it was officially included. As I said above, I am confident that the concept is as sound as it can be under the circumstances.  I'm concerned about adding or omitting something that will end up creating a bug later on, particularly in the way I handle the IAX2 protocol. By: Chris A. Icide (cicide) 2005-06-02 13:47:17 Take a look at patch 0004371.  Does it do the same thing?  Any better or worse in it's implementation? By: Michael Jerris (mikej) 2005-06-26 18:29:47 Suspended due to no response.  If you wish to presue this bug, please re-open with responses. By: gkloepfer (gkloepfer) 2005-10-23 22:55:09 Would like to re-open this feature request as it still is a desired feature. Response to comments re: bug 0004371: While this work was similar to what I was doing in my proposed feature request, the method in 4371 was overly complex to configure as shown by the discussion in the responses. While my proposed method for handling remote message waiting (RMWI) has some issues (discussed in the issue details) it is consistent with the way that MWI is implemented in Asterisk.  The biggest concern that was raised in discussion on the mailing list was scalability (many channels from one PBX polling another PBX's voicemail system for MWI).  Unfortunately, the scalability issue is in the fundamental implementation of MWI in Asterisk. Note also that while bug 004369 is similar in principle to what I am proposing, I feel that the syntax I am proposing is more flexible and implements the remote queries over IAX2 rather than SIP (more efficient for use in a "master/slave" PBX deployment). As soon as the issue is reopened, I will attach my patch for the current CVS HEAD (I have it, just need to attach it to this report). Thanks. By: Donny Kavanagh (donnyk) 2005-12-23 03:12:46.000-0600 Whats going on here?   Remote VM is a necessairy feature, can we keep this one going? By: Matthew Fredrickson (mattf) 2006-02-10 16:24:13.000-0600 This should be kept on the -dev list until something more ready for submission.  We're trying to use the -dev list more for architecture planning rather than the bug tracker since it gets more exposure.