I am using the JavaMail package. It creates a thread for each IMAP connection. In terms of code packaging it would be another class added to the new Java voicemail package. In terms of configuration files, I don't have an opinion.
Peter -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Krzeminski, Damian (BL60:9D30) Sent: Monday, June 22, 2009 5:43 AM To: [email protected] Subject: Re: [sipX-dev] Unified Messaging Peter Fowler wrote: > > Over the past couple of months I have been working on tighter > integration between SipX and Exchange (or any other e-mail server that > supports IMAP). > > The Java prototype code (may change in important ways prior to > integration into a release) I have written is a component of the new > voicemail implementation and behaves as follows: > > 1) for each SipX voicemail it creates an IMAP connection to the > corresponding Exchange mailbox and a listener thread that "listens" > for changes to the Exchange mailbox > > 2) new voicemail messages left on SipX are forwarded to Exchange via > SMTP (as per existing functionality). An additional > > MIME header is included that indicates the SipX voice message id. > 3) upon message arrival in Exchange the listener thread is informed > of the new message > 4) if the message is read via Outlook, listener thread is poked and > corresponding SipX voice message is marked as read (and MWI goes off > if last unread message) > > 5) if message is deleted via Outlook (or moved to another folder) > then corresponding SipX voice message is marked as deleted (and MWI > goes off if last unread message) > > 6) if message is listened to or deleted via SipX TUI, corresponding > message is marked as read or deleted in Exchange > 7) in the event of a message or message status mismatch (eg. Msg > exists in Exchange but not on SipX) then Exchange status wins. In this > way one can think of > > the SipX mailbox as a cache of the Exchange mailbox. If the > message doesn't exist on SipX then the corresponding voice will be > downloaded from Exchange when > > the user plays the message via the TUI. > 8) if Exchange server is unreachable then user can still manage > messages via SipX TUI. When Exchange is back up, its view of the > messages wins > > 9) mailbox greetings and spoken name are also stored in Exchange in > a folder called "VoiceMail Greetings". Since Exchange is the primary > store for > > messages and greetings, voicemail becomes "stateless". > > The above behaviors imply the following: > > a) To establish an IMAP connection, the Exchange username and* > password* must be stored securely within SipX. If the user changes the > password and thus > > SipX cannot establish an IMAP connection, the code sends a plain > text e-mail to the user telling him/her to login to the user portal to > change the e-mail password > There is no way of storing passwords "securely" - but we can try to keep them out of plain view in DB and in a new service configuration file. > b) Thousands of users means thousands of threads (I had to modify > /etc/security/limits.conf during my scalability testing) Do you think it can be improved with thread pools at some point? It's not like there is a need for a separate thread for every user right? > > > The following config parms are required: > Administrator (system wide) > - Exchange IP address or domain name > - IMAP port number (default 143) > - use TLS or not > - on a per user basis indicate if messages are to be stored on > Exchange > End user > - email user name > - email password > > The code I have written to date uses the Sun JavaMail library which in > turn has been tested with a number of IMAP servers. I have tested my > code only > > against MS Exchange at this point. JavaMail does not require/use any > proprietary IMAP extensions but it does rely on the IMAP Idle command > (RFC 2177) > > to get asynchronous message notifications. To date, Lotus Notes and > Groupwise do not support the IDLE command. The workaround to this > (which I have not > > yet implemented) is to periodically send a NOOP command to the server > , it will then respond with message status change messages. > > Future Extension > - download various (eg urgent) plain text e-mails, convert to wav > via FreeSwitch TTS module and create a SipX voice message > > The overall solution may not be for every customer, the > scalability/security issues may outweigh the administrator/user benefits. > How do you plan to package this functionality: I am thinking a new service in voicemail bundle would be a way to go. It can have it's own configuration file and parameters. sipXconfig could hanle getting IMAP account info from the users. But I am open to other proposals. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
