Some more background information. On Sat, Jun 30, 2012 at 2:31 PM, Mark Rejhon <[email protected]> wrote:
> Right now, the current XEP-0301 specification permits the scenario to be > possible, *at the implementor's option* > > *EXAMPLE SCENARIO of an "RTT session"* > *** Normal instant messaging conversation is occuring. No real-time text. > *** Real-time text is *activated *as follows: > - A sender clicks a button or menu to activate RTT. (privacy > confirmation may be used first) > - Sender client begins to transmit <rtt/> > - Recipient client detects incoming <rtt/> > - Recipient client asks user for confirmation such as "*Sender is sending > Real-Time Text. -Accept- or -Reject-?*" (or other/more descriptive > message) > - (Recipient client can continue to display incoming real-time text while > waiting for -Accept- or -Reject- to be clicked. This is a convenient way > to educate the recipient what real-time text really is.) > - Recipient decides to clicks -Accept- > - Thereafter, recipient client is now also sending <rtt/> > *** Instant messaging conversation continues with real-time text enabled > from both ends. > *** When either party wants to stop real-time text, they *deactivate *as > follows: > - A sender clicks a button or menu to deactivate > - Sender client transmits <rtt event='cancel'/> (This is also used if > recipient clicks -Reject- instead too) > - Recipient client stops transmitting <rtt/>. (notification message to > say RTT has ended) > *** Instant message conversation continues normally. > This is only what happens "behind the scenes". It sounds complex, but it really isn't. To the end-user, it is much simpler -- behaves like accepting/rejecting a video session. 1. Sender initiates real-time text via button. Sender continues typing. (Sender client now sending RTT) 2. Recipient client confirms. (Much like for confirming audio/video) 3. Conversation continues. Real-time text enabled from both ends. Simple! Cheers, Mark Rejhon
