Re: [rtcweb] Text communication in RTCWEB sessions

[Igor Faynberg <[e-mail]>]

+1

Igor

On 11/12/2012 7:15 AM, Harald Alvestrand wrote:
> 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
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb