>>>>>>> On 6/18/2009 at 2:16 PM, in 
> message
<[email protected]>, "Tony 
> Graziano"
<[email protected]> wrote:
 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/ 
> 
Answering my own question sort of. Gmail does support IMAP IDLE. So is it 
conceivable this will work with Google Apps?

_______________________________________________
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