Offline Message Storage Application¶

Approach 1¶

• Add failure route to OpenSIPS for chat sessions
• SylkServer answers the session in behalf of the called user
• SylkServer sends an automatic answer with 'I am offline but you can type a message'
• Session is kept open for 90 seconds so that remote party has the chance to write something if he did not already before connect
• Session is closed and saved to local history database
• SylkServer detects when targeted user comes online
• Establish a new session to the user that came online and fake the original caller, deliver the stored messages, hangup and wipe delivered messages

Approach 2: VoiceMail style¶

• Add failure route to OpenSIPS for chat sessions
• SylkServer answers the session in behalf of the called user
• SylkServer sends an automatic answer with 'I am offline but you can type a message'
• Every time a chat message is received SylkServer sends a MWI (RFC 3842) PUBLISH on behalf of the caller to the proxy.
  The payload contains Text-Messages instead of Voice-Messages (RFC 3458, sec 6.2).
• When the user comes back online she will subscribe to MWI and learn that she has offline text messages waiting. She can get them by starting a chat session to the URI in the Message-Account field of the MWI payload.
• When the user fetches all messages SylkServer will terminate the session and send one last PUBLISH indicating that there are no new offline messages.
• SylkServer will provide a single URI for all users to fetch messages, the From header URI will be used to select the appropriate user. This assumes SylkServer is deployed behind a SIP proxy, which a by-design feature of SylkServer.

Things to be clarified:

• What happens if the user has both voice and text messages waiting? Does OpenSIPS aggregate payloads? Do we care? SylkServer can keep publising until the user fetches the offline messages, but Asterisk won't.

Refinement¶

• The SIP client will send a second MWI subscription to himself but with a Sylk-App: textmail header to the proxy.
• Proxy will route that SUBSCRIBE to SylkServer, which will act as the endpoint, this avoids the problems caused by multiple entities publishing on behalf of the same user.