>>> On 6/18/2009 at 1:48 PM, in message
<[email protected]>, "Peter
Fowler" <[email protected]> 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
>   b) Thousands of users means thousands of threads (I had to modify
> /etc/security/limits.conf during my scalability testing)
>   
> 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.
> 
> 
If I understand this correctly, this "should' mean that one could use a gmail 
account assuming gmail supports IMAP IDLE?
_______________________________________________
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/

Reply via email to