The email discussion regarding Real-time Text (RTT) in December last year
showed a real interest in the need to support it in WebRTC/rtcweb.

In addition, there are draft regulations in the USA and in Europe REQUIRING
RTT be supported wherever there is voice communication.

We need to find a way to include RTT in the Use cases and Gunnar's proposal
is a very good start. It does not change any of the existing Use cases as
it is an Additional feature.

I strongly support the inclusion of RTT in the Use cases and Requirements.

Cheers,
/Barry Dingle




On Thu, Jan 31, 2013 at 8:15 AM, Gunnar Hellstrom <
gunnar.hellstrom@omnitor.se> wrote:

>  On 2013-01-26 09:53, Harald Alvestrand wrote:
>
> On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote:
>
> On 2013-01-18 17:06, Magnus Westerlund wrote:
>
> WG,
>
> I would here by like to announce a two week WG last call that ends on
> the 1st of February.
>
> Document is available here:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/
>
>
> We had a good discussion in December on inclusion of the real-time text
> medium.
>
> It was decided to document three alternative implementations with pros and
> cons and after that decide which one to standardize together with the two
> already mentioned media in rtcweb.
>
> The three alternatives were:
> 1.) An RTP medium similar to audio and video, using RFC 4103 transport.
>
> 2.) A semi-reliable data channel with a standardized label.
>
> 3.) A web service based protocol, such as BOSH and XEP-0301 for real-time
> text in XMPP with a well specified integration with rtcweb in a common
> application.
>
> For all three cases, there is a need to have a specification for how calls
> with audio, video and real-time text are exchanged with SIP based
> environments, e.g. for interaction with RFC 6443 based emergency services.
>
> Text is a natural part of today's video and audio applications, so all use
> cases look quite meager without it.
>
>  I suggest that we make a rapid mini-investigation on the real-time text
> alternatives and decide which variant to include in a use case.
>
>
> I disagree with this summary on two points:
>
> - I think it's broken to choose between implementation strategies in an
> use case. The use case needs to specify the function that we want to
> achieve.
>
> Yes, I totally agree, I did not mean to have the discussion on solution in
> the use case document.
>
>
>
> - I don't recall a declaration by the chairs that text would be included
> in the use cases for RTCWEB.
>
> I repeat my proposal to do so. This time with a shortened, generally
> expressed use case that is intended to allows any one of the three
> implementation alternatives to be selected.
>
>
>
> My memory is flaky, so if you can find the declaration by the chairs, I'm
> happy to let the last point pass.
>
>  Yes, I am on my way to do the last point as well. But timing requires the
> addition to the use cases to be handled now.
>
>
> Thus: Proposal for adding real-time text to the use cases, adjusted to be
> general and minimal:
>
> --------------------------Add real-time text in a general way in use case
> draft-------------------------------------------
>
> 4.2.15.  Simple Total Conversation service****
>
> 4.2.15.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>).****
>
> ** **
>
>    In addition to this, the users can send and receive real-time text
>    in the same call.**** While one user types in the real-time text area, it****
>
>    is nearly immediately presented to the other user.
>
>    By providing these three media together, the Total Conversation
>    service is provided.
>
>    Interworking with SIP calls with the same media set, and with SIP
>    based emergency services is also in scope of this use case. ****
>
> ** **
>
> 4.2.15.2 <#13c8d510f5a08297_section-4.3.1.2>.  Derived Requirements****
>
> ** **
>
>    F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,****
>
> ** **
>
>    F39,F40, F41****
>
> ** **
>
>    A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27****
>
> ** **
>
> ..............
>
>    F39             The browser MUST be able to handle text entry****
>
>                    via applications to generate real-time                    text streams to be included in Total Conversation
>                    calls. Real-time text and Total Conversation
>                    Services are defined in ITU-T F.700 and F.703. ****
>
>    ----------------------------------------------------------------****
>
>    F40              The browser MUST be able to send real-time text ****
>
>                    streams to a peer.****
>
> ** **
>
>    ----------------------------------------------------------------****
>
>    F41              The browser MUST be able to receive, process and****
>
>                     convey real-time text streams from peers to
>                     applications.****
>
>    ----------------------------------------------------------------****
>
>    ****
>
> **
>
> .....
> **   A27             The Web API MUST provide a mechanisms for ****
>                    handling real-time text among the streams.****
>  ----------------------------------------------------------------****
>
>
>
> /Gunnar
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>