Subject: Re: [rtcweb] Text communication in RTCWEB sessions

From: "Kevin Dempsey" <[email-masked]>
Date: Thu, 6 Dec 2012 09:17:54 -0000

Using data channels would mean that the format of text becomes
application specific, 

so people using facewidget can talk with other facewidget users but,
unlike audio, 

gatewaying would be necessary to talk to Gibble+ users.

Also, adding data channel support to media gateways would require
implementation of 

SCTP, the data channel protocol and the various text encodings. 

The technical benefits of RFC4103 include:

1) RFC4103 is based on RTP and can be sent using secure RTP.

2) Text presentation can be paced using the RTP timestamp (runs at
1000Hz).

3) It can be included in a 'BUNDLE', so reducing the number of ports
that need to be opened.

4) DTLS/SRTP to RTP gateways would treat the text stream the same as
audio and video streams.

It is also being pushed by various organizations as the real-time text
medium of choice 

for emergency service access in the USA and Europe. Please refer to the
following:

http://trace.wisc.edu/docs/2008-RTT-Proposal/Proposal-R1-Dec10-2008.pdf

http://www.fcc.gov/document/fcc-adopts-next-generation-911-nprm

http://www.reach112.eu/ressource/static/files/reach112_d3.2_final_specif
ication_d3.2_v2.1-.pdf

Some discussion has been about real-time verses message-based text
communication. There 

is nothing to prevent the user agent presenting whole messages to the
underlying stream 

rather than each character as it is typed. So provided a real-time text
stream is available 

an application layer could implement a message-based system over the
top.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 06 Dec 2012 15:09:10 -0500

> gatewaying would be necessary to talk to Gibble+ users.

This was the purpose of the proposal I made at IETF Atlanta; we will add 
a 'protocol' text field similar to the one in WebSockets.  It has little 
actual use there, but here it can serve the purpose you care about - 
identifying the protocol for a stream in a cross-application way.  So 
facewidget and Gibble+ would happily be able to talk to each other.

Gibble+ would offer a DataChannel in the SDP (m=application; see the SDP 
draft for SCTP) and would specify it wanted a DataChannel with protocol 
(say) of T140.  facewidget would answer accepting it and you'd have a 
bidirectional T140-over-DataChannel connection both sides know how to use.

> SCTP, the data channel protocol and the various text encodings.

Correct.

> 1) RFC4103 is based on RTP and can be sent using secure RTP.

DataChannels run over SCTP-over-DTLS, and so is fully secure as well.

> 3) It can be included in a 'BUNDLE', so reducing the number of ports 

The DataChannel SCTP connection will also be BUNDLEd; it's another m= line

> for emergency service access in the USA and Europe. Please refer to 
> the following:
>
> http://www.reach112.eu/ressource/static/files/reach112_d3.2_final_specification_d3.2_v2.1-.pdf
>

Not disagreeing, but do see the earlier discussions; I don't think this 
is a blocking issue.

-- 
Randell Jesup
[email-masked]