OfflineMessaging
Version 14 (Saúl Ibarra Corretgé, 06/21/2012 11:02 am) → Version 15/18 (Saúl Ibarra Corretgé, 06/21/2012 11:10 am)
h1. Offline Message Storage Application
h2. 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
h2. 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.
h2. Approach 3: VoiceMail style (refined) h3. Refinement
* 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'
* 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.
* The SIP client will send this a second MWI subscription to himself but with a Sylk-App: offline-messages textmail header to the proxy, which proxy.
* Proxy will route that SUBSCRIBE to SylkServer, acting as an endpoint.
* SylkServer sends a MWI (RFC 3842) NOTIFY which payload contains Text-Messages instead of Voice-Messages (RFC 3458, sec 6.2).
* When the user fetches all messages SylkServer will terminate act as the session and send a NOTIFY indicating that there are no new offline messages.
* SylkServer will provide a single URI for all users to fetch messages, endpoint, this avoids the From header URI will be used to select problems caused by multiple entities publishing on behalf of the appropriate same user. This assumes SylkServer is deployed behind a SIP proxy, which is a by-design feature of SylkServer.
h2. 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
h2. 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.
h2. Approach 3: VoiceMail style (refined) h3. Refinement
* 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'
* 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.
* The SIP client will send this a second MWI subscription to himself but with a Sylk-App: offline-messages textmail header to the proxy, which proxy.
* Proxy will route that SUBSCRIBE to SylkServer, acting as an endpoint.
* SylkServer sends a MWI (RFC 3842) NOTIFY which payload contains Text-Messages instead of Voice-Messages (RFC 3458, sec 6.2).
* When the user fetches all messages SylkServer will terminate act as the session and send a NOTIFY indicating that there are no new offline messages.
* SylkServer will provide a single URI for all users to fetch messages, endpoint, this avoids the From header URI will be used to select problems caused by multiple entities publishing on behalf of the appropriate same user. This assumes SylkServer is deployed behind a SIP proxy, which is a by-design feature of SylkServer.