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.
_______________________________________________
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/
