Re: [rtcweb] Text communication in RTCWEB sessions

[Harald Alvestrand <[e-mail]>]

I would prefer this to be added as a separate specification, rather than 
done at this time.
The reason being that this should be relatively easy to add on top of 
the data channel functionality, but will definitely take some time to 
specify, so should not be on the critical path for this round of 
specifications.

             Harald

On 11/12/2012 10:06 AM, Gunnar Hellström wrote:
> Real time sessions with video and audio are often accompanied with 
> some form of text communication.
>
> It is mentioned in a couple of places in RTCWEB related 
> specifications, but I see a need to get the specifications of how text 
> should be handled up to the level of specification of the other media.
>
> The real-time requirements are slightly lower on text communication 
> than on video and audio, so I realize that it can be carried by 
> mechanisms already available in the web browser environment. But even 
> if that will be the case, it needs to be considered and described, 
> because text communication is part of the real-time communication 
> concepts that RTCWEB belongs to.
>
> I know three kinds of text communication:
>
> Real-time text:
>
> Real-time text is text transmitted while it is being typed or 
> created.*The recipient can read the sender's text as it is written, 
> without waiting.
>
> *Text messaging:
>
> Text messaging is text collected to complete messages and sent as a 
> whole when completed by specific user action.***The recipient can read 
> the sender's text *soon after it is transmitted.
>
> Timed text:
>
> Timed text is text sent together with with information about the 
> intended timing of the display, often related to another medium, such 
> as audio or video. The recipient can read the text presented timely to 
> events in the other media.
>
>
> Real-time text for conversational use has the timing requirement that 
> end-to-end latency shall not be more than 2 seconds for usable text, 
> and one second for good usability. This is clearly lower than the 
> requirements on audio and video that traditionally is 400 ms for 
> usable end-to-end latency.
>
> Real-time text is briefly mentioned in a requirement in 
> draft-ietf-rtcweb-data-channel
> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-02
>
> All three text communication forms are mentioned in 
> http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt
>
> I am most eager to see the use of real-time text specified in relation 
> to RTCWEB, but it might be good to touch all three types.
>
>
> I suggest that it starts with requirements and use cases in
> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-use-cases-and-requirements/
>
>
> I propose to add real-time text to use case 4.2.1 so that it reads:
>
>
>         4.2.1. Simple Video Communication Service
>
>   with audio and real-time text
>
>
>           4.2.1.1. Description
>
>
>
>     Two or more users have loaded a video communication web application
>     into their browsers, provided by the same service provider, and
>     logged into the service it provides.  The web service publishes
>     information about user login status by pushing updates to the web
>     application in the browsers.  When one online user selects a peer
>     online user, a 1-1 video communication session between the browsers
>     of the two peers is initiated.  The invited user might accept or
>     reject the session.Audio and real-time text is also available
>     during the session.
>
>     During session establishment a self-view is displayed, and once the
>     session has been established the video sent from the remote peer is
>     displayed in addition to the self-view.  During the session, each
>     user can select to remove and re-insert the self-view as often as
>     desired.  Each user can also change the sizes of his/her two video
>     displays during the session.Audio from each user is presented to
>     the other user. While one user types in the real-time text area, it
>     is nearly immediately presented to the other user.  Each user can
>     also pause sending of media (audio, video, or both) and mute incoming
>     media
>
>
> An alternative is to add a small additional section in 4.2
> "
>
>
>         4.2.x. Simple Video Communication Service with real-time text
>
>
>
>           4.2.x.1. Description
>
>
>
>     This use-case has the audio and video communication of the Simple
>     Video Communication Service use-case (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).
>
>     But in addition to this, the users can send and receive real-time text.
>     While one user types in the real-time text area, it
>     is nearly immediately presented to the other user.
> "
> A couple of requirements then need to be added in the A and F ranges 
> in 5.2 and 5.3, but I want to start with this initial proposal.
>
> Gunnar Hellstrom
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb