Subject: Re: [rtcweb] Consensus call on Text Communication

From: Salvatore Loreto <[email-masked]>
Date: Sat, 1 Dec 2012 12:26:58 +0200

On 12/1/12 12:36 AM, Randell Jesup wrote:
> On 11/30/2012 4:58 PM, Gunnar Hellström wrote:
>> It has been said a number of times that the rtcweb data channel would 
>> be suitable for real-time text.
>>
>> I have also seen doubts about that expressed.
>>
>> One alerting doubt was that it did not seem to have well established 
>> implementations. And the protocol spec is very thick. It might take a 
>> long time before it is implemented with reliable function and good 
>> interoperability. Right?
>
> The protocol spec is tiny (draft-jesup-rtcweb-data-protocol).  If 
> you're thinking SCTP, yes it's large - so are UDP and TCP, and it does 
> a lot more.  It's used a lot in telephony; very little on the open web.
>
>> I would like to know more about the data channel.
>>
>> How much overhead is it per transmission?
>
> Not a lot.  The rtcweb DataChannel protocol adds nothing to a 
> datagram.  SCTP is slightly larger than TCP IIRC, not a lot.  Ask 
> Michael Tuexen or Randall Stewart; maintainers of SCTP and authors on 
> the spec who are working with us.
>
>> Is it possible to specify capability negotiation of features using 
>> the data channel?
>
> yes
>
>>  Does that require additions to the specs.
>
> No, you can specify them at channel open time (see the draft), or 
> (proposed) in negotiation (draft-mmusic-sdp-something).
here the link to the draft that propose SDP negotiation for datachannel
http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02

the authors are working on a new version that will include the result of 
the so far discussion on the issue.
If you are interested on it please contribute in the mmusic mailing list

cheers
Salvatore

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 01 Dec 2012 11:33:42 +0100

On 12/01/2012 11:26 AM, Salvatore Loreto wrote:
>>> It has been said a number of times that the rtcweb data channel 
>>> would be suitable for real-time text.
>>>
>>> implementations. And the protocol spec is very thick. It might take 
>>> a long time before it is implemented with reliable function and good 
>>> interoperability. Right?
>>
>> you're thinking SCTP, yes it's large - so are UDP and TCP, and it 
>> does a lot more.  It's used a lot in telephony; very little on the 
>> open web.
>>
> the authors are working on a new version that will include the result 
> of the so far discussion on the issue.
Salvatore,

I hope you answer my question there about multiplexing of SCTP/DTLS with 
another RTP stream on a single port. I haven't seen any response to that 
yet.

(Nov 2 question - it's almost 1 month old today)

>
> cheers
> Salvatore
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Dec 2012 11:10:27 -0800

Without taking a position on whether or not Real-Time Text is
important, I really don't understand the arguments for why Data Channel
isn't sufficient. It's not like the cost of gatewaying typed characters
is going to be excessive and there's no reason to think that data
over SCTP won't be plenty fast.

Given that, I don't really see that adding a use case adds much
value, since the data channel capabilities required to support
this are already baked into other use cases.

-Ekr

On Sat, Dec 1, 2012 at 2:26 AM, Salvatore Loreto <
[email-masked]> wrote:

>>> It has been said a number of times that the rtcweb data channel would be
>>> suitable for real-time text.
>>>
>>> implementations. And the protocol spec is very thick. It might take a long
>>> time before it is implemented with reliable function and good
>>> interoperability. Right?
>>>
>>
>> The protocol spec is tiny (draft-jesup-rtcweb-data-**protocol).  If
>> you're thinking SCTP, yes it's large - so are UDP and TCP, and it does a
>> lot more.  It's used a lot in telephony; very little on the open web.
>>
>> Not a lot.  The rtcweb DataChannel protocol adds nothing to a datagram.
>>  SCTP is slightly larger than TCP IIRC, not a lot.  Ask Michael Tuexen or
>> Randall Stewart; maintainers of SCTP and authors on the spec who are
>> working with us.
>>
>>  Is it possible to specify capability negotiation of features using the
>>> data channel?
>>>
>>
>> yes
>>
> http://tools.ietf.org/html/**draft-ietf-mmusic-sctp-sdp-02<http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 01 Dec 2012 23:09:48 +0100

> this are already baked into other use cases.
It was just that it was natural to think about RTP transport first 
because RFC 4103 already is an RTP packetization and has SDP defined. Al 
large number of aspects have already been considered when designing RFC 
4103, such as suitable reliability level, non-delivery out of order, 
marks if text might have been lost, robustness against packet loss 
bursts, multi-party aspects, action in congestion, negotiation, minimal 
need of feedback, so that it can be used in loosely coupled conferences, 
bandwidth and packet load economy, throtteling, etc.

Going through all these factors and specify it suitably for a new kind 
of transport is not tempting.

The data channel spec also says that it is for non-media transport. 
Thinking of real-time text as media causes a need to make exceptions. Of 
course I understand that it is doable.

If the data channel is to be used it seems that a label to be used for 
real-time text needs to be standardized, and the parameters to be used 
to achieve suitable characteristics. The procedures for such 
registration does not seem to be defined yet.

I also do not yet see the definitions of how transmission failures are 
reported. E.g. for a semi-reliable channel, how does the receiving 
application get informed that some data may have been lost when it gave 
up with retries? RFC 4103 use such information to mark the place of 
possible loss och text with a special character.

So, there seems to be a lot to standardize and specify for real-time 
text in the data channel that we already have in RFC 4103 for RTP.

There is one thing though that is not yet defined for RFC 4103, and that 
is its use with the AVPF profile that seems to be mandatory for rtcweb.

If we look at the other opportunity, to enhance XMPP Instant Messaging 
with a real-time text mode as specified in XEP-0301 and combine that 
with audio and video in common sessions, how would that XMPP be best 
transported? Completely outside of rtcweb e.g. using BOSH and only 
coordinated by some common session establishment procedure? Or using a 
data channel, going through the work described above but for XMPP transport.

I get the feeling that BOSH is the right choice.

Have anyone done a coordinated combination of XMPP messaging with rtcweb 
video and audio?

And how would a gateway then get hold of all three media in case of 
translation to SIP Total Conversation is needed because the other party 
is using that?

/Gunnar

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Dec 2012 14:35:30 -0800

On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellström <
[email-masked]> wrote:

> 4103, such as suitable reliability level, non-delivery out of order, marks
> if text might have been lost, robustness against packet loss bursts,
> multi-party aspects, action in congestion, negotiation, minimal need of
> feedback, so that it can be used in loosely coupled conferences, bandwidth
> and packet load economy, throtteling, etc.
>
> Going through all these factors and specify it suitably for a new kind of
> transport is not tempting.
>
> real-time text needs to be standardized, and the parameters to be used to
> achieve suitable characteristics. The procedures for such registration does
> not seem to be defined yet.
>
> application get informed that some data may have been lost when it gave up
> with retries? RFC 4103 use such information to mark the place of possible
> loss och text with a special character.
>
> So, there seems to be a lot to standardize and specify for real-time text
> in the data channel that we already have in RFC 4103 for RTP
>

Most of these things don't need to specified for data channels because it
already
provides congestion control, reliability (optionally) and sequenced
delivery (optionally).

I'm sorry, I'm really not seeing the need for something new. It just seems
like
you're making the problem unnecessarily complicated.

-Ekr

---

From: Erik Lagerway <[email-masked]>
Date: Sat, 1 Dec 2012 14:46:29 -0800

+1

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> |
*Hookflash<http://hookflash.com>

****

---

From: Jim Barnett <[email-masked]>
Date: Sat, 1 Dec 2012 22:59:38 +0000

+1

-          Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Saturday, December 01, 2012 5:36 PM
To: Gunnar Hellström
Cc: [email-masked]
Subject: Re: [rtcweb] Consensus call on Text Communication

On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Given that, I don't really see that adding a use case adds much
value, since the data channel capabilities required to support
this are already baked into other use cases.
It was just that it was natural to think about RTP transport first because RFC 4103 already is an RTP packetization and has SDP defined. Al large number of aspects have already been considered when designing RFC 4103, such as suitable reliability level, non-delivery out of order, marks if text might have been lost, robustness against packet loss bursts, multi-party aspects, action in congestion, negotiation, minimal need of feedback, so that it can be used in loosely coupled conferences, bandwidth and packet load economy, throtteling, etc.

Going through all these factors and specify it suitably for a new kind of transport is not tempting.

The data channel spec also says that it is for non-media transport. Thinking of real-time text as media causes a need to make exceptions. Of course I understand that it is doable.

If the data channel is to be used it seems that a label to be used for real-time text needs to be standardized, and the parameters to be used to achieve suitable characteristics. The procedures for such registration does not seem to be defined yet.

I also do not yet see the definitions of how transmission failures are reported. E.g. for a semi-reliable channel, how does the receiving application get informed that some data may have been lost when it gave up with retries? RFC 4103 use such information to mark the place of possible loss och text with a special character.

So, there seems to be a lot to standardize and specify for real-time text in the data channel that we already have in RFC 4103 for RTP

Most of these things don't need to specified for data channels because it already
provides congestion control, reliability (optionally) and sequenced delivery (optionally).

I'm sorry, I'm really not seeing the need for something new. It just seems like
you're making the problem unnecessarily complicated.

-Ekr

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 02 Dec 2012 00:32:37 +0100

On 2012-12-01 23:35, Eric Rescorla wrote:
>
>
> On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     because RFC 4103 already is an RTP packetization and has SDP
>     defined. Al large number of aspects have already been considered
>     when designing RFC 4103, such as suitable reliability level,
>     non-delivery out of order, marks if text might have been lost,
>     robustness against packet loss bursts, multi-party aspects, action
>     in congestion, negotiation, minimal need of feedback, so that it
>     can be used in loosely coupled conferences, bandwidth and packet
>     load economy, throtteling, etc.
>
>     The data channel spec also says that it is for non-media
>     transport. Thinking of real-time text as media causes a need to
>     make exceptions. Of course I understand that it is doable.
>
>     If the data channel is to be used it seems that a label to be used
>     for real-time text needs to be standardized, and the parameters to
>     be used to achieve suitable characteristics. The procedures for
>     such registration does not seem to be defined yet.
>
>     I also do not yet see the definitions of how transmission failures
>     are reported. E.g. for a semi-reliable channel, how does the
>     receiving application get informed that some data may have been
>     lost when it gave up with retries? RFC 4103 use such information
>     to mark the place of possible loss och text with a special character.
>
>     So, there seems to be a lot to standardize and specify for
>     real-time text in the data channel that we already have in RFC
>     4103 for RTP
>
>
Maybe. For me it just looks as the real-time text RTP media was 
forgotten when rtcweb was first specified and that it would be easiest 
to just add it as it is.

And the data channel looks quite under-specified yet, and will need some 
time before it has everything settled and sorted out. I recognize that 
rtcweb is in an early stage and of course we can do experimental 
implementations before everything is settled if some data channel 
implementations are available.

About my questions:

Is it true that a label needs to be standardized for real-time text, and 
the procedures for such standardization and registration are not settled?

Are there error returns in the APIs on both sides for indicating that 
there was a gap in the data sequence when the semi-reliable data channel 
gave up with transmission in order to not stall the channel?

---------------------

Now I read SCtP, and get the impression that the retransmission timeouts 
are far too long for smooth real-time text. The initial value is 3 
seconds. So at least intially in the calls there will be 3 seconds 
hickups every time a text packet is lost. ( I did not take time to 
decode how far down this figure is adjusted if roundtrip time is short, 
maybe this is just an initial problem... )

The redundancy used in RFC 4103 is very inexpensive and rapid. During 
continued typing, earlier text is sent together with next text packet 
after the sample time. So, 300 ms after expected first reception, next 
transmission of the same text is received together with new text. It 
just costs a few more bytes per packet. If first redundant transmission  
fails, one more opportunity appears 300 ms later.  That creates a 
smoother media flow even on quite bad connections.

Gunnar

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 2 Dec 2012 01:21:30 +0100

On Dec 2, 2012, at 12:32 AM, Gunnar Hellström wrote:

>> On Sat, Dec 1, 2012 at 2:09 PM, Gunnar Hellström <[email-masked]> wrote:
> Maybe. For me it just looks as the real-time text RTP media was forgotten when rtcweb was first specified and that it would be     easiest to just add it as it is.
> 
> And the data channel looks quite under-specified yet, and will need some time before it has everything settled and sorted out. I recognize that rtcweb is in an early stage and of course we can do experimental implementations before everything is settled if some data channel implementations are available.   
> 
> About my questions:
> 
> Is it true that a label needs to be standardized for real-time text, and the procedures for such standardization and registration are not settled?
> 
> Are there error returns in the APIs on both sides for indicating that there was a gap in the data sequence when the semi-reliable data channel gave up with transmission in order to not stall the channel?
When using ordered delivery in SCTP, the socket API can give you the stream sequence number. If
you are using PR-SCTP, the receiver can observe this sequence number and figure out that messages
have been abandoned. I think this is currently information is not provided by the JS API.
Maybe that can be added as an optional argument to the onmessage event handler for ordered
data channels.
> 
> ---------------------
> 
> Now I read SCtP, and get the impression that the retransmission timeouts are far too long for smooth real-time text. The initial value is 3 seconds. So at least intially in the calls there will be 3 seconds hickups every time a text packet is lost. ( I did not take time to decode how far down this figure is adjusted if roundtrip time is short, maybe this is just an initial problem... )
Yes, this is the initial value in the RFC. As soon as there are round trip time measurements, they are
used. The FreeBSD implementation uses already the association setup messages for updates.
So timer based data retransmissions would be based on the round trip time measurements (within RTO.min
RTO.max). Please note that for a single packet loss and continued typing a fast retransmit
would be triggered most likely.

Best regards
Michael
> 
> The redundancy used in RFC 4103 is very inexpensive and rapid. During continued typing, earlier text is sent together with next text packet after the sample time. So, 300 ms after expected first reception, next transmission of the same text is received together with new text. It just costs a few more bytes per packet. If first redundant transmission  fails, one more opportunity appears 300 ms later.  That creates a smoother media flow even on quite bad connections.
> 
> Gunnar

---

From: Randell Jesup <[email-masked]>
Date: Sun, 02 Dec 2012 02:52:37 -0500

On 12/1/2012 6:32 PM, Gunnar Hellström wrote:
>
> And the data channel looks quite under-specified yet, and will need 
> some time before it has everything settled and sorted out. I recognize 
> that rtcweb is in an early stage and of course we can do experimental 

See http://mozilla.github.com/webrtc-landing/data_test.html in Firefox 
Nightly.  The JS code for all the call setup is ugly, but the 
Datachannels are pretty simple to use.

Replace {} in createDataChannel() with {outOfOrderAllowed : true, 
maxRetransmitNum : 0} for the equivalent of UDP.

>
> About my questions:
>
> Is it true that a label needs to be standardized for real-time text, 
> and the procedures for such standardization and registration are not 
> settled?

Yes, and at IETF-85 I proposed (and there seemed to be consensus for) 
adding a 'protocol' field similar to WebSocket's, which is what you'd 
want to standardize for.  (Side benefit: it would help standardize 
transmission over WebSockets as well, which have an almost identical API 
(on purpose)).

> there was a gap in the data sequence when the semi-reliable data 
> channel gave up with transmission in order to not stall the channel?

Not currently.  We've planned on adding optional attributes to incoming 
messages with information, but one problem is that just reporting a 
sequence number doesn't tell you if the *stream* lost a packet, as the 
sequence numbers are shared across all streams. Short answer: if you're 
using partial or no reliability (or reliable out-of-order), you'll need 
to include in the application protocol a sequence number if you care 
about them.

We might still be persuaded to re-frame the datagrams with a header with 
a sequence number/etc; we've avoided doing so thus far to simplify 
transmission/reception re-framing.

> just costs a few more bytes per packet. If first redundant 
> transmission  fails, one more opportunity appears 300 ms later.  That 
> creates a smoother media flow even on quite bad connections.

If you decide to use partially-reliable connections, you could still use 
that if you want.  In many cases, I suspect PR-SCTP retransmission might 
beat a 300ms redundancy implementation in speed of correction, but you 
can do both if you want.  And "quite bad connections" are usually today 
low bandwidth and high delay or total packet loss for significant 
periods, not high (random) packet loss. (i.e. WiFi with a poor signal).

-- 
Randell Jesup
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 2 Dec 2012 10:00:25 +0100

On Dec 2, 2012, at 8:52 AM, Randell Jesup wrote:

> See http://mozilla.github.com/webrtc-landing/data_test.html in Firefox Nightly.  The JS code for all the call setup is ugly, but the Datachannels are pretty simple to use.
> 
> Replace {} in createDataChannel() with {outOfOrderAllowed : true, maxRetransmitNum : 0} for the equivalent of UDP.
> 
>> 
>> About my questions:
>> 
> Yes, and at IETF-85 I proposed (and there seemed to be consensus for) adding a 'protocol' field similar to WebSocket's, which is what you'd want to standardize for.  (Side benefit: it would help standardize transmission over WebSockets as well, which have an almost identical API (on purpose)).
> 
>> 
> Not currently.  We've planned on adding optional attributes to incoming messages with information, but one problem is that just reporting a sequence number doesn't tell you if the *stream* lost a packet, as the sequence numbers are shared across all streams. Short answer: if you're using partial or no reliability (or reliable out-of-order), you'll need to include in the application protocol a sequence number if you care about them.
You are right, SCTP uses a sequence number called TSN, which is shared between all streams and
exposing this to the JS use is of limited use. But SCTP has also a sequence number called SSN
for ordered messages within each stream.
So for ordered data channels (no matter if reliable or not) we can expose this number and
for each data channel it would start with 0. It is a 16 bit counter and the receiver can
deduce that messages have been abandoned, if the number increments by more than one.

For unordered data channels this number can't be provided, since messages are delivered to user
as they are received and the sender indicates that ordering is not important.

Best regards
Michael
> 
> We might still be persuaded to re-frame the datagrams with a header with a sequence number/etc; we've avoided doing so thus far to simplify transmission/reception re-framing.
> 
> If you decide to use partially-reliable connections, you could still use that if you want.  In many cases, I suspect PR-SCTP retransmission might beat a 300ms redundancy implementation in speed of correction, but you can do both if you want.  And "quite bad connections" are usually today low bandwidth and high delay or total packet loss for significant periods, not high (random) packet loss. (i.e. WiFi with a poor signal).
> 
> -- 
> Randell Jesup
> [email-masked]
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 02 Dec 2012 10:28:02 +0100

On 2012-12-02 08:52, Randell Jesup wrote:
>
> If you decide to use partially-reliable connections, you could still 
> use that if you want.  In many cases, I suspect PR-SCTP retransmission 
> might beat a 300ms redundancy implementation in speed of correction, 
> but you can do both if you want.  And "quite bad connections" are 
> usually today low bandwidth and high delay or total packet loss for 
> significant periods, not high (random) packet loss. (i.e. WiFi with a 
> poor signal). 

Yes, I realize that hickups or short blocking occurring now and then 
should not be a blocking factor for transport selection for real-time 
text. Hickups and short pauses occur also naturally in human typing, 
scratching an itching spot, looking up at a bird flying by etc. So they 
are accepted by receiving parties.

Thus, a partially-reliable data channel is likely still among the 
possible alternative transports for real-time text.

/Gunnar

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 02 Dec 2012 10:55:18 +0100

Having been in the position counter's seat before.....

When replying to a consensus call response with a note that doesn't 
state a new position, but instead goes into long arguments about the 
issue at hand, or even diverts off into completely new avenues, please 
CHANGE THE SUBJECT!

        Harald

On 12/02/2012 12:32 AM, Gunnar Hellström wrote:
>>     It was just that it was natural to think about RTP transport
>>     first because RFC 4103 already is an RTP packetization and has
>>     SDP defined. Al large number of aspects have already been
>>     considered when designing RFC 4103, such as suitable reliability
>>     level, non-delivery out of order, marks if text might have been
>>     lost, robustness against packet loss bursts, multi-party aspects,
>>     action in congestion, negotiation, minimal need of feedback, so
>>     that it can be used in loosely coupled conferences, bandwidth and
>>     packet load economy, throtteling, etc.
>>
>>     If the data channel is to be used it seems that a label to be
>>     used for real-time text needs to be standardized, and the
>>     parameters to be used to achieve suitable characteristics. The
>>     procedures for such registration does not seem to be defined yet.
>>
>>     I also do not yet see the definitions of how transmission
>>     failures are reported. E.g. for a semi-reliable channel, how does
>>     the receiving application get informed that some data may have
>>     been lost when it gave up with retries? RFC 4103 use such
>>     information to mark the place of possible loss och text with a
>>     special character.
>>
> Now I read SCtP, and get the impression that the retransmission 
> timeouts are far too long for smooth real-time text. The initial value 
> is 3 seconds. So at least intially in the calls there will be 3 
> seconds hickups every time a text packet is lost. ( I did not take 
> time to decode how far down this figure is adjusted if roundtrip time 
> is short, maybe this is just an initial problem... )
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 2 Dec 2012 10:44:11 +0100

On 2012-11-30 10:01, Magnus Westerlund wrote:
> WG,
>
> This is the start of an one week+ call for consensus that will end on
> Sunday the 9th of December. The question for consensus is: Shall a use
> case be added regarding Text communication within the context of
> PeerConnection, i.e. not using the generic capabilites of WebRTC, but
> rather provide a specific media type and its transport.
>
> Please indicate your support or objections for this!

I don't think we should add such a use case.

It could make sense to create a separate document outlining the uses 
envisioned and the resulting requirements. I think we will find that 
those requirements can be met with already existing web technologies 
(but possibly the WebRTC data channel can offer a performance gain).

>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 3 Dec 2012 10:13:50 -0500

If RTT is so trivial it is an extremely short, separate document, then there is no real reason to not do it now, as part of the base protocol.

If RTT is not trivial, then we have bigger problems: if we cannot figure out how to specify a codec that has virtually no negotiation, has real-time requirements but is somewhat jitter insensitive, and extremely low bandwidth, then the idea that rtcweb will deliver voice and video in our lifetime is a fantasy.

Also, many jurisdictions are demanding RTT for real-time communications.  I can see it already: ITU-T H.webrtc supports RTT and IETF WebRTC does not. Therefore, it will be illegal to deploy a site that does not support H.webrtc.

Are we really adamant about shooting ourselves in the foot, or is this all an academic exercise?

Just do it.

On Dec 2, 2012, at 4:44 AM, Stefan Håkansson LK wrote:

> It could make sense to create a separate document outlining the uses envisioned and the resulting requirements. I think we will find that those requirements can be met with already existing web technologies (but possibly the WebRTC data channel can offer a performance gain).
> 
>> 
>> Cheers
>> 
>> Magnus Westerlund
>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Dec 2012 09:31:12 -0800

On Mon, Dec 3, 2012 at 7:13 AM, Eric Burger <[email-masked]>wrote:

> If RTT is so trivial it is an extremely short, separate document, then
> there is no real reason to not do it now, as part of the base protocol.
>
> If RTT is not trivial, then we have bigger problems: if we cannot figure
> out how to specify a codec that has virtually no negotiation, has real-time
> requirements but is somewhat jitter insensitive, and extremely low
> bandwidth, then the idea that rtcweb will deliver voice and video in our
> lifetime is a fantasy.
>

This is a false choice.

It's trivial to do if you use the infrastructure that WebRTC already
provides
for this purpose. It appears to be rather a PITA to do the way that Gunnar
proposes.

-Ekr

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 3 Dec 2012 17:50:49 +0000

On Dec 3, 2012, at 8:13 AM, Eric Burger <[email-masked]> wrote:

> Also, many jurisdictions are demanding RTT for real-time communications. 

name one

---

From: Mark Rejhon <[email-masked]>
Date: Mon, 3 Dec 2012 13:15:47 -0500

On Mon, Dec 3, 2012 at 12:31 PM, Eric Rescorla <[email-masked]> wrote:
> provides for this purpose. It appears to be rather a PITA to do the way that Gunnar
> proposes.

As the author of XEP-0301 (real-time text for XMPP, which most
commonly runs over TCP/IP) -- the data connection facility within
webrtc seems to be fine for real-time text, at least from the
perspective of XEP-0301.   When things are running reliable (no data
loss), on a sufficiently performing server, latency would be a
non-issue.

Reasoning of my point of view: XEP-0301 uses an XML-based real-time
text payload that makes it suitable for almost any kind of channel --
even polled -- it works BOSH too.  This is an even higher-level layer
with more stall problems than even the webrtc data connection
facility, which seems supposedly more real-time than plain TCP/IP from
what I've been reading.  So XEP-0301 has it worse-off (by XMPP needing
to run over TCP/IP) than the webrtc data channel.

Side note -- The XML real-time text payload in XEP-0301 is mostly
channel protocol independent; it can be polled (BOSH), it can be on a
lossy channel (UDP, intermittent wireless connections, etc) as long as
latency is not too big.  Although it is for XMPP, it was designed as a
generic XML-based real time text payload that is channel-independent
since it has its own correct-sequence check and an optional method of
redundancy.  If text smoothing is used (e.g. key press interval
encoding), conversations are usable even with a sustained 2 to 3
second latency (only if it is unavoidable, e.g. weak connections,
congestion), though I certainly strongly, greatly prefer 300ms.  But
it's by all means, totally usable (my opinion, for me, at least), and
TCP retransmit stalls are only a minor disruption; much smaller than
it is for audio and video.  There are 'extenuating' moments (i.e.
unavoidable connectivity degradations like weak wireless reception)
where stalls are impossible to avoid.  It's just a fact of life.

I also see great potential for the webrtc data channel to be used for
other real-time-like connectivity (e.g. video games within webrtc),
and there is no doubt that vendors will optimize the data channels;
this will only benefit real-time text, whichever technology is piped
through them (RFC4103 based, XEP-0301 based)

Mark Rejhon
Author of XEP-0301 -- XMPP Real-Time Text

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 Dec 2012 13:31:54 -0500

Thank you brother Burger... 

So (rant hat on) we seem to agree on at least 2 MTI audio codecs's though
I've seen no further discussion of SHOULD's like 722 AMR WB which might be
useful to interoperate with nearly every future mobile endpoint and
enterprise IP PBX system on the planet. 

We have zero agreement for MTI on video codec's.  

Now we have this discussion that the WG should simply not even deal with
RTT.

If this is the future of interoperable real-time communications... wow! 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Burger
Sent: Monday, December 03, 2012 10:14 AM
To: [email-masked]
Subject: Re: [rtcweb] Consensus call on Text Communication

If RTT is so trivial it is an extremely short, separate document, then there
is no real reason to not do it now, as part of the base protocol.

If RTT is not trivial, then we have bigger problems: if we cannot figure out
how to specify a codec that has virtually no negotiation, has real-time
requirements but is somewhat jitter insensitive, and extremely low
bandwidth, then the idea that rtcweb will deliver voice and video in our
lifetime is a fantasy.

Also, many jurisdictions are demanding RTT for real-time communications.  I
can see it already: ITU-T H.webrtc supports RTT and IETF WebRTC does not.
Therefore, it will be illegal to deploy a site that does not support
H.webrtc.

Are we really adamant about shooting ourselves in the foot, or is this all
an academic exercise?

Just do it.

On Dec 2, 2012, at 4:44 AM, Stefan Håkansson LK wrote:

>> Sunday the 9th of December. The question for consensus is: Shall a 
>> use case be added regarding Text communication within the context of 
envisioned and the resulting requirements. I think we will find that those
requirements can be met with already existing web technologies (but possibly
the WebRTC data channel can offer a performance gain).
> 
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> ---------------------------------------------------------------------
>> - Multimedia Technologies, Ericsson Research EAB/TVM

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Dec 2012 11:02:37 -0800

I posted references to CVAA, the ACS Report & Order and the Access Board Section 255/508 refresh earlier. There is also M376 in EU (see http://www.mandate376.eu/ ) which is similar to Section 255/508 (e.g. a procurement guideline).  In reading these documents it's important to keep in mind that "RTT" can mean a capability in some cases and in others can refer to a specific standard (e.g. RFC 4103 or XEP-0301).

---

From: Adam Roach <[email-masked]>
Date: Mon, 03 Dec 2012 13:26:54 -0600

On 12/3/12 13:02, Bernard Aboba wrote:
> it's important to keep in mind that "RTT" can mean a capability in some cases and in others can refer to a specific standard (e.g. RFC 4103 or XEP-0301).

Which highlights the problem we'll face if we decide to take this work on.

We can do RTT right now with data channels. I can hack together a 
ridiculously simple example on top of Firefox Nightly build if you want 
to see it.

Now, if we decide that we're going to pick through the specific 
standards called out by the various regulatory regimes around the global 
-- well in excess of 100 -- in order to make sure that we've put extra 
special hooks in WebRTC to support whatever technical variant they've 
specified, then we have no hope of ever finishing.

The alternative of picking Gunnar's personal favorite technology (and 
ignoring any regulations that elect to go another way) would seem to add 
quite a bit of work to come up with what ends up being a somewhat 
provincial solution. It would be a half-measure that adds significant 
work while only partially meeting your implied goal of meeting all 
regulations presently in place or being contemplated around the globe.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 Dec 2012 13:24:41 -0500

The US ... for a start ... we'd have to check with our ECRIT friends, Hannes
etal but the moves in the EC along similar lines are equally striking. 

http://transition.fcc.gov/cgb/dro/cvaa.html

Should I remind folks that this is the 20th anniversary of SMS...the most
profitable product on planet Earth other than crack cocaine and laser toner?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings (fluffy)
Sent: Monday, December 03, 2012 12:51 PM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [rtcweb] Consensus call on Text Communication

name one

---

From: Roman Shpount <[email-masked]>
Date: Mon, 3 Dec 2012 23:03:40 +0200

Out of curiosity what commercially available phones/terminals/clients
currently support real time text apart from Real Jabber? What protocols do
they currently support?
_____________
Roman Shpount

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 03 Dec 2012 22:17:01 +0100

I changed subject as Harald asked us to do.

On 2012-12-03 20:26, Adam Roach wrote:
>> it's important to keep in mind that "RTT" can mean a capability in 
>> some cases and in others can refer to a specific standard (e.g. RFC 
>> 4103 or XEP-0301).
>
> ridiculously simple example on top of Firefox Nightly build if you 
> want to see it.
>
> standards called out by the various regulatory regimes around the 
> global -- well in excess of 100 -- in order to make sure that we've 
> put extra special hooks in WebRTC to support whatever technical 
> variant they've specified, then we have no hope of ever finishing.
>
> ignoring any regulations that elect to go another way) would seem to 
> add quite a bit of work to come up with what ends up being a somewhat 
Thanks, Yes, please do a " ridiculously simple example" . It is doable, 
and that is similar to how we started in both H.320 , H.323 and SIP 
once. It is better to be able to show something simple than to discuss 
the best way to do it forever.

Someone asked for regulations:  Here is one: The European Electronic 
Communication Framework directives were revised in 2009,  by 
2009/136/EC, and for example introduced a new definition of "Publicly 
available telephone services" that must be provided to anyone who needs it:
"Publicly available telephone services also include means of 
communication specifically intended for disabled end-users using text 
relay or total conversation services."

And "total conversation services" are defined in ITU-T F.703 to provide 
video, real-time text and audio.

Since May 2011 this shall be valid in all European countries.

There are not many technology specific variants in regulations. They 
instead tend to describe the requirement in quite general terms like the 
European one.

So, we are free to specify a good way to do it in rtcweb as long as it 
is feasible to gateway it together with audio and video into a SIP 
session with audio, video and RFC 4103.

Even if we end up using the rtcweb data channel, I think a standard 
specification should be done.

It is best if we do it with the view that it will become a popular 
mainstream feature. The research references I supplied the other day 
show that that is feasible.

Looking forward to see your example Adam.

//Gunnar

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 03 Dec 2012 23:12:16 +0100

Again moving off the voting subject as requested by Harald.
On 2012-12-03 22:03, Roman Shpount wrote:
> currently support real time text apart from Real Jabber? What 
> protocols do they currently support?
> _____________
> Roman Shpount
>
Here are some ( I hope it is OK to mention a bunch of brand names here - 
a bit off habit in standards work )

Asterisk PBX  T.140/RFC4103
Omnitor Allan eC  Windows total conversation softphone T.140/RFC4103
Omnitor eCmobile Android app T.140/RFC 4103
Omnitor eCtouch Android app T.140/RFC4103
Omnitor eCpad hard pad T.140/RFC4103
multi-party bridge T.140/RFC4103
Aupix TCPhone Windows softphone T.140/RFC4103
Aupix TCPhone Android app T.140/RFC4103
Aupix TCPhone IOS app T.140/RFC4103
Aupix call center T.140/RFC4103
Leadtek 8A10 hard pad T.140/RFC4103
ivés Djanah Windows softphone T.140/RFC4103
ivés call center T.140/RFC4103
T-Meeting TM-9000 hard pad T.140/RFC4103
nWise MMX5 call center and soft phone T.140/RFC4103
A number of emergency service PSAP NG911/NG112 systems T.140/RFC4103
Tenacity IP-TTY  Windows softphone T.140/RFC4103
SBNTech hard pad    T.140/RFC4103
AOL soft chat client - proprietary
Ultratec Captel soft client - proprietary
Texttelefoni.se soft web client for relay - proprietary
RealJabber Soft XMPP client XEP-0301

//Gunnar

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 Dec 2012 15:40:46 -0500

On 12/3/12 13:02, Bernard Aboba wrote:
> it's important to keep in mind that "RTT" can mean a capability in some
cases and in others can refer to a specific standard (e.g. RFC 4103 or
XEP-0301).

We can do RTT right now with data channels. I can hack together a
ridiculously simple example on top of Firefox Nightly build if you want to
see it.

[RS> ] I have no doubt .. :-) 

Now, if we decide that we're going to pick through the specific standards
called out by the various regulatory regimes around the global
-- well in excess of 100 -- in order to make sure that we've put extra
special hooks in WebRTC to support whatever technical variant they've
specified, then we have no hope of ever finishing.

The alternative of picking Gunnar's personal favorite technology (and
ignoring any regulations that elect to go another way) would seem to add
quite a bit of work to come up with what ends up being a somewhat provincial
solution. It would be a half-measure that adds significant work while only
partially meeting your implied goal of meeting all regulations presently in
place or being contemplated around the globe.
[RS> ] 
[RS> ] Adam this is a fair position to take. I suspect the general objection
is that given all the requirements for RTCWEB that are out there right now
it's a near impossible task to sort through as it is much less decide on
something new.  A reasonable position. RTT is thus a "distraction".  

That said, the opposite position is RTT is just to big to ignore for any
number of reasons and we do need to remember that this week is the 20th
anniversary of SMS and text is near and dear to the hearts of the hearing
impaired community, ES 911 proponents not to mention nearly every human
being under the age of 25.  Remember the enormous failures of IM were they
did not interoperate thus granting SMS an open field to market domination.
Silos don't work. You have to choose.  

I still think Bernard's general approach is correct.. try and document what
is out there now and can one or more be selected for MTI with the assumption
that everything else is going to be sent through a gateway.  The regulatory
authorities .. if you read CVAA closely for instance, understand there may
be multiple technical approaches to compliance.  It's is the attempt to
comply that is "safe harbor" in legal terms.  

/a

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Dec 2012 01:06:37 -0500

On 12/3/2012 5:12 PM, Gunnar Hellström wrote:
> Here are some ( I hope it is OK to mention a bunch of brand names here 
> - a bit off habit in standards work )

That list says to me that real-world implementation of RFC 4103 is 
spotty at best.  That's not to say it might not increase significantly 
when national accessibility/emergency requirements go into effect, but 
I'd say right now it's pretty sparse among VoIP softclients (mostly ones 
specifically meant for Deaf/HoH it seems). And Asterisk seems big, until 
you realize it's a PBX and "support" there mean it passes it through, I 
assume.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Dec 2012 01:29:40 -0500

> Silos don't work. You have to choose.

That's fine, but I think the right solution is to do that as a separate 
effort
- to standardize RTT over DataChannels (whether it's T.140 or XEP-301 or
something else). I think the rtcweb's position should be that RTT should be
done over a DataChannel, and thus standardized separately.  If other 
countries
require a different RTT protocol, that can be standardized as well (or ones
which aren't mandated, such as XEP-301 today).

This pushes the *implementation* into the JS layer in a browser, but that's
not a bad thing.  If there are UI elements that would make supporting it 
easier
in a browser, those can be taken up with the W3C and/or the browser vendors.
Even if it were built into core of the browser as a MediaStream, it 
would still
need to surface to the JS app to do the display and input handling anyways.

> comply that is "safe harbor" in legal terms.

My understanding is that all of these apply to applications (certainly 
in the
FCC world), and so not directly to a browser implementing rtcweb - but 
we want
to make sure applications can comply with standards all over the world - and
standards to come.

-- 
Randell Jesup
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Dec 2012 23:31:44 -0800

Randell said: 

> My understanding is that all of these apply to applications (certainly in the FCC world), and so not directly to a browser implementing rtcweb - but 
> we want to make sure applications can comply with standards all over the world - and standards to come.

[BA] Please take a look at the text of the CVAA, M376, the Section 255/508 Update and the ACS Report and Order.  There is nothing in any of those texts that grants special dispensation to applications or services that are browser-based.   For some background on the history of the movement for accessible communications services, the following volume may be of interest:

Karen Peltz Strauss, "A New Civil Right: Telecommunications Equality for Deaf and Hard of Hearing Americans", ISBN-10: 1563682915, 2006.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Dec 2012 23:45:06 -0800

> comply that is "safe harbor" in legal terms.  

[BA] Since we are engineers in the IETF, it seems to me that we should try to approach this as an engineering problem.  That is, first figure out in some detail what it is we're trying to build, then after that, figure out if there is anything missing from our toolkit that would prevent us from building it.  WebRTC combining as it does realtime communications with other facilities of the Web (including accessibility functionality) would appear to have promise as a platform for the creation and deployment of accessible communications applications and services.

---

From: Stefan Hakansson LK <[email-masked]>
Date: Tue, 4 Dec 2012 08:49:54 +0100

On 12/04/2012 08:31 AM, Bernard Aboba wrote:
> Randell said:
>
>  > My understanding is that all of these apply to applications
> (certainly in the FCC world), and so not directly to a browser
> implementing rtcweb - but
> [BA] Please take a look at the text of the CVAA, M376, the Section
> 255/508 Update and the ACS Report and Order.  There is nothing in any of
> those texts that grants special dispensation to applications or services
> that are browser-based.

The key words to me are "applications or services". This responsibility 
lies with  those developing the apps and offering the services, not with 
the browser itself. That said, why don't we go ahead and study this as a 
separate work item (as already proposed) to make sure it is possible to 
support (with a reasonable effort) using a browser as platform?

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Dec 2012 03:36:15 -0500

On 12/4/2012 2:49 AM, Stefan Hakansson LK wrote:
> The key words to me are "applications or services". This 
> responsibility lies with  those developing the apps and offering the 
> services, not with the browser itself. That said, why don't we go 
> ahead and study this as a separate work item (as already proposed) to 
> make sure it is possible to support (with a reasonable effort) using a 
> browser as platform?

Correct IMHO.  And if you read a bunch of the FCC rulemaking (see the 
stuff I linked last week), you'll see they very purposely put the onus 
on service providers and equipment manufacturers, and not on any others 
inbetween (and in practice it's largely on the service provider).  I.e. 
if you have an "advanced communication service", you're beholden for it 
to be accessible, and to choose tools/etc that allow you to do that.  
Thus, we should make certain webrtc is a viable *tool*, but browser 
vendors (if they don't also act as Service Providers with apps) are not 
directly responsible to the FCC on this.  Note: IANAL of course; I just 
play one on mailing lists.

(God, I thought I'd gotten away from being an amateur FCC lawyer when I 
stopped working for a company supplying VRS Service Providers with 
hardware....)  :-(

-- 
Randell Jesup
[email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 04 Dec 2012 10:37:51 +0100

Aain taking subject off from the voting subject.

On 2012-12-04 08:31, Bernard Aboba wrote:
> 255/508 Update and the ACS Report and Order.  There is nothing in any 
> of those texts that grants special dispensation to applications or 
> services that are browser-based.   For some background on the history 
> of the movement for accessible communications services, the following 
> volume may be of interest:
>
> Karen Peltz Strauss, "A New Civil Right: Telecommunications Equality 
> for Deaf and Hard of Hearing Americans", ISBN-10:1563682915, 2006.

Yes, regulations require real-time text anywhere where there is voice 
communication. Only where the call control environment is known, the 
exact technical method is sometimes prescribed. As for SIP it is in some 
cases required to be T.140/RFC 4103.
It is not more strange than rtcweb defining if H.264 or VP8 shall be the 
mandated fall-back for video in order to assure interoperability.

I hope that we can focus less on the regulated requirements and instead 
try to specify and do something of mainstream interest that also 
fulfills the regulations.

The usability research I pointed at recently, and the self test I 
described you can make, clearly indicate that real-time text would be a 
popular mainstream feature. So let us try to define it with that goal. 
RTCWEB gives the image of being at the front end of innovation, so it 
would be logical to pick up this indication from usability research and 
combine a better way of texting together with video and audio.

I still see four main options for the implementation:

1. As a third RTP carried medium in rtcweb, using T.140/RFC4103 with 
redundancy. (over AVPF profile as required in rtcweb.)

2. T.140 transmitted over a well specified use of the rtcweb data 
channel, using a partially-reliable variant with delivery in order and 
indication of loss. I think time-sampled transmission in 300 ms chunks 
is best in order to not overload narrow channels and internal signaling 
in case of use for rapid text streams as from speech-to-text.

3. XMPP with XEP-0301 XML based real-time text separately implemented 
but well coordinated in the same web page as rtcweb audio and video.

In all three cases, there is a need to be able to combine the call and 
the media into a SIP session by a gateway, and this must be possible for 
both the cases when the other party uses AVPF and AVP for its RTP. Many 
implementations do not use AVPF today for any of its media, so there 
will be a need to take rtcweb media through a media gateway anyway for 
audio and video as well as for real-time text.

More reasoning around the options:

1. T.140/RFC 4103 as a new rtcweb medium.
Real-time text is seen as a third medium in the call as it has been done 
before in SIP, H.320, H.323, H.324. It handles its own reliability 
through inexpensive and rapid redundancy. API:s to JS are needed.
Coordination with SIP need often to be done in gateways, because no 
current implementation of AVPF based RFC4103 exists.
( same for other media ).

2. T.140/rtcweb data channel. It may be true that the rtcweb data 
channel is a good mechanism to select for transport of T.140 text. My 
first impression was that it was immaturely specified that it would not 
be safe to use it as a base. But that will surely be amended. We can use 
Adam's offered rapid development as a proof of concept, and make sure 
that the data channel and the use of it for real-time text will be 
sufficiently specified to assure interoperability and good 
functionality. The coordination with the call and the other media in a 
gateway looks doable. All three will at least be managed through SDP, 
and mapping between SDP for data channel and SDP for RTP/RFC4103 looks 
manageable.

3. Separate XMPP/XEP-0301. If there are big actors planning to combine 
rtcweb audio and video with XMPP messaging into a standardized 
multimedia service, I would recommend to use XEP-0301 in that 
environment to get more life into the text part of this concept. It 
would be adaptation to both mainstream users preferences and regulative 
requirements. The coordination with SIP calls need to be done in a 
gateway for this case as well, and may be more tricky than for case 2, 
because the rtt medium is not at all SDP negotiated on the browser side.

Summary:
I think that the gatewaying issues are crucial for selecting the right 
way here. Have anything been done to specify gateway procedures? How 
would case 2 and 3 be handled in gateways?

And, even if case 3 is selected, where the transport of real-time text 
itself is not a rtcweb issue, specification in close coordination with 
rtcweb progress is needed because of the interoperability requirements.

//Gunnar

---

From: Eric Burger <[email-masked]>
Date: Tue, 4 Dec 2012 05:25:00 -0800

WOAH!  If it is a simple matter of implementation in the JS layer of the browser to do RTT, then I need to give Cullen his CDN 100 back, because what this is saying is RTCWEB was finished before it started: I could do any media in a browser in the JS layer. It was Cullen who took me for a sucker bet, not the other way around, because RTCWEB had nothing to do. [The bet was that RTCWEB would be *finished* in one year. I took, how shall we say, the long view.]

Others have piped in with US and European *laws* requiring RTT or other support for hearing impaired (and visually impaired and speech impaired) individuals, so I will not reiterate them here.

As for the stance that we do not need to care about these laws and regulations because the onus is on the people actually deploying the applications and not the manufacturers of the applications, browsers, or servers, I would offer that for once the governing bodies and regulators got it right.  Would you rather have a law that says, "Make sure you meet this goal" or a law that says, "You must implement this technology in this way with these tools"?  Note that if we do not bake in support, the latter approach is what we are likely to end up with.  

And, that is how we end up with H.rtcweb.  No joke.

The converse may also be true.  While there are a few approaches to RTT, I would offer that if we bake one into RTCWEB, or at least have one as a reference implementation, I would not be surprised if those jurisdictions with other approaches either migrate our way or gateway from our way.  This is an opportunity for IETF leadership.  That is a much better situation than IETF irrelevance.

If pretty much every RTC application made available in the Western world requires RTT support, is our position going to be that every developer has to build, buy, copy, or steal RTT support infrastructure?  Or, is our position that since pretty much every RTC application needs it, it should be a part of the infrastructure, i.e., supplied by the browser?  If the logic is applications can do it on their own, then let's again declare victory and not spend the next five years arguing over video codecs as that can be done above the browser.

On Dec 3, 2012, at 10:29 PM, Randell Jesup wrote:

> That's fine, but I think the right solution is to do that as a separate effort
> done over a DataChannel, and thus standardized separately.  If other countries
> not a bad thing.  If there are UI elements that would make supporting it easier
> Even if it were built into core of the browser as a MediaStream, it would still

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Dec 2012 09:19:50 -0500

Correct IMHO.  And if you read a bunch of the FCC rulemaking (see the stuff
I linked last week), you'll see they very purposely put the onus on service
providers and equipment manufacturers, and not on any others inbetween (and
in practice it's largely on the service provider).  I.e. 
if you have an "advanced communication service", you're beholden for it to
be accessible, and to choose tools/etc that allow you to do that.  
Thus, we should make certain webrtc is a viable *tool*, but browser vendors
(if they don't also act as Service Providers with apps) are not directly
responsible to the FCC on this.  Note: IANAL of course; I just play one on
mailing lists.

(God, I thought I'd gotten away from being an amateur FCC lawyer when I
stopped working for a company supplying VRS Service Providers with
hardware....)  :-(
[RS> ] 
[RS> ] Sigh ... it's a dirty job but some of us have to do it.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 04 Dec 2012 15:20:57 +0100

Changing the subject as usual...

On 12/04/2012 08:45 AM, Bernard Aboba wrote:
> [BA] Since we are engineers in the IETF, it seems to me that we should 
> try to approach this as an engineering problem. That is, first figure 
> out in some detail what it is we're trying to build, then after that, 
> figure out if there is anything missing from our toolkit that would 
> prevent us from building it.  WebRTC combining as it does realtime 
> communications with other facilities of the Web (including 
> accessibility functionality) would appear to have promise as a 
> platform for the creation and deployment of accessible communications 
> applications and services.

... and phrased like this, the question then becomes:

Is this within charter for RTCWEB, or does it require a new effort?

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Dec 2012 09:37:59 -0500

The converse may also be true.  While there are a few approaches to RTT, I
would offer that if we bake one into RTCWEB, or at least have one as a
reference implementation, I would not be surprised if those jurisdictions
with other approaches either migrate our way or gateway from our way.  This
is an opportunity for IETF leadership.  That is a much better situation than
IETF irrelevance.
[RS> ] 
[RS> ] Thank you again.  You have summarized my point better than I could
have.  You cannot simply say, "Well the browser doesn't need to deal with
this." It's a recipe for fragmentation and silos. Evaluate the options, as
Bernard suggests, but for the sake of interoperability choose at least one
reference implementation. 

If pretty much every RTC application made available in the Western world
requires RTT support, is our position going to be that every developer has
to build, buy, copy, or steal RTT support infrastructure?  Or, is our
position that since pretty much every RTC application needs it, it should be
a part of the infrastructure, i.e., supplied by the browser?  If the logic
is applications can do it on their own, then let's again declare victory and
not spend the next five years arguing over video codecs as that can be done
above the browser.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 4 Dec 2012 08:05:08 -0800

Comments in-line.

On Tue, Dec 4, 2012 at 6:20 AM, Harald Alvestrand <[email-masked]> wrote:
> [BA] Since we are engineers in the IETF, it seems to me that we should try
> to approach this as an engineering problem.  That is, first figure out in
> some detail what it is we're trying to build, then after that, figure out if
> there is anything missing from our toolkit that would prevent us from
> building it.  WebRTC combining as it does realtime communications with other
> facilities of the Web (including accessibility functionality) would appear
> to have promise as a platform for the creation and deployment of accessible
> communications applications and services.
>
>

I think the answer to this depends on whether the aim is for
RTCWeb/WebRTC to provide
the rendezvous service for a real-time communication based entirely in
the web or not.
As I read the charter that work would involve us being reasonably
certain that the
underlying architecture works when the media being carried is
real-time text, rather
than audio or video, and that the negotiation works for picking a
media type.  After
that a reference to RFC 4103 for currently standard payload format
seems to round out
the work that falls squarely into the charter.

The second potential piece of work I'm much less sanguine about, as
that would be
interworking with gateways.  The Real Time Text Task force
(www.realtimetext.org)
seems to indicate that there is already work going on in defining
gateway/transcoding
and it might be better done there as part of that effort (for those
who don't know
Arnoud van Wijk, he started this work as part of ISOC's efforts
Enabling Access initiative
before r3tf came into being.)  Doing it independently seems likely to create a
gateway mechanism that aims at a past standard rather than upcoming
states of play.

Would the working group like the chairs to start a liaison effort with the R3TF?

regards,

Ted Hardie

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Dec 2012 11:52:46 -0500

On 12/4/2012 9:20 AM, Harald Alvestrand wrote:
>> [BA] Since we are engineers in the IETF, it seems to me that we 
>> should try to approach this as an engineering problem. That is, first 
>> figure out in some detail what it is we're trying to build, then 
>> after that, figure out if there is anything missing from our toolkit 
>> that would prevent us from building it.  WebRTC combining as it does 
>> realtime communications with other facilities of the Web (including 

As that's a charter question, I'll leave it to those with time to 
re-read the charter :-)

I think we absolutely should define how accessibility can be handled 
within rtcweb, and if we can include a reference implementation and/or 
build in the hooks (or more), I'm all for that.  And I agree; if we 
select something it will go a fair ways towards pushing implementations 
(not just in rtcweb) and regulations towards that standard (or towards 
requirements that can be fulfilled by that standard).

I would suggest it's at least a separate standards document; whether 
that's within rtcweb or not is, as mentioned, a process issue I really 
don't care about.

To actually surface this to users does involve the 
applications/websites, since they define most of the UI seen by the 
user.  We can support that with protocols (either reference impls or 
baked in) and perhaps with DOM/W3 changes to provide useful tools, but 
we can't bake the entire UI into the browser without totally stifling 
innovative uses.

This is a tough area for regulators, as the actual applications (and the 
UI) are provided by the website authors.  The classic telecom regulatory 
framework starts to fray when it hits the web.  (To which regulators 
must a website answer to?  What if they're contradictory?  What if they 
only target users from one country? What if they aren't a paid service?)

Before we make core changes to the rtcweb spec we need to consider these 
issues.  Another reason I think a separate standards-track document is 
in order.

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Dec 2012 09:26:07 -0800

On 12/4/2012 8:52 AM, Randell Jesup wrote:
>
> Before we make core changes to the rtcweb spec we need to consider 
> these issues.  Another reason I think a separate standards-track 
> document is in order.
>

There's a bunch of real engineering issues to consider as well. If we 
allow sending of T.140/RFC4103 text on a PeerConnection from JavaScript 
then:

(just to bring up some examples off the top of my head)

- Is the JavaScript rate-limited such that it cannot use this channel as 
a congestion-unconstrained browser-to-browser data channel?
- Will there be a consent dialog raised before the JavaScript can send 
on this channel?
- Do there need to be safeguards to prevent a malicious website or 
malicious injected content from modifying the text that is typed by the 
user? (In other words, is the text channel also able to be marked the 
same way a camera and microphone can be marked to prevent modification 
of the content, and if so, how could that even work?)
- Do there need to be safeguards to prevent a malicious website or 
malicious injected content from calling a PSAP on your behalf and 
engaging in "SWATing" over this channel?

Matthew Kaufman

---

From: Mark Rejhon <[email-masked]>
Date: Tue, 4 Dec 2012 12:43:26 -0500

On Tue, Dec 4, 2012 at 12:26 PM, Matthew Kaufman <[email-masked]> wrote:
> - Is the JavaScript rate-limited such that it cannot use this channel as a
> congestion-unconstrained browser-to-browser data channel?

Not from the perspective of XEP-0301.
XEP-0301 allows rate-smoothing methods that turns random intermittent
arrival of packets (300ms, 100ms, 1000ms, 500ms) into smoothed text
output.  It's usable even up to 2-3 second jitter (poor wireless
reception, satellite connections, etc).   That said, the more steady
and reliable, the better.

It's a graceful degradation of service, but far less abrupt than it is
for audio/video (which suffers more greatly).  Therefore, I pretty
much assume the data channel will be perfectly fine for XEP-0301
during situations where audio is fully intelligible and video isn't
too glitchy.

> - Will there be a consent dialog raised before the JavaScript can send of this channel?

I sure hope it's no more cumbersome than it will be for audio/video,
and that it can be a single-step authorization process for the entire
webrtc environment, otherwise it would not be well-adopted.
Standardization of indicators of function might be recommended (like
the lock icon for SSL), to indicate that live communication is in
progress -- like a red flashing dot ("we're LIVE!")

There are some privacy guidelines in Security Considerations of XEP-0301:
http://xmpp.org/extensions/xep-0301.html#security_considerations

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 04 Dec 2012 19:17:40 +0100

Answers inline

On 2012-12-04 18:26, Matthew Kaufman wrote:
> allow sending of T.140/RFC4103 text on a PeerConnection from 
> JavaScript then:
>
> - Is the JavaScript rate-limited such that it cannot use this channel 
> as a congestion-unconstrained browser-to-browser data channel?
Could be if needed. In RFC 4103 there is a default transmission limit of 
30 characters per second, that can be negotiated by an sdp parameter. 30 
characters per second is regarded sufficient for human input, even from 
speech-to-text applications but for safety sake, I think a limit of 50 
characters per second would be safer  - usability wise.
> - Will there be a consent dialog raised before the JavaScript can send 
The normal thing in a total conversation call is to activate all three 
media as soon as possible after call completion. A video channel can do 
much more harm than the RTT channel.
> malicious injected content from modifying the text that is typed by 
> the user? (In other words, is the text channel also able to be marked 
> the same way a camera and microphone can be marked to prevent 
> modification of the content, and if so, how could that even work?)
If you can do it with audio and video, you should be able to do it with 
real-time text. But that may have limitations for example when 
interworking with a legacy SIP device.
> engaging in "SWATing" over this channel?
Sounds to be questions to be solved in coordination with video and 
audio. Are these issues solved for the other media?

//Gunnar

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Dec 2012 10:53:20 -0800

On 12/4/2012 10:17 AM, Gunnar Hellström wrote:
> Could be if needed. In RFC 4103 there is a default transmission limit 
> of 30 characters per second, that can be negotiated by an sdp 
> parameter. 30 characters per second is regarded sufficient for human 
> input, even from speech-to-text applications but for safety sake, I 
> think a limit of 50 characters per second would be safer - usability 
> wise.

Since the application author (and the JavaScript) can make arbitrary 
changes to the SDP, the browser will need to enforce an upper bound on 
this data rate.

>> - Will there be a consent dialog raised before the JavaScript can 
>> send on this channel?
> media as soon as possible after call completion. A video channel can 
> do much more harm than the RTT channel.

Did you come in late to the RTCWEB work? For privacy there's a 
requirement for camera and microphone access to raise a consent dialog 
in the browser before the camera or microphone is activated. On the 
other hand, there is no requirement to raise a consent dialog before 
opening a data channel. What's the answer for this case?

> If you can do it with audio and video, you should be able to do it 
> with real-time text. But that may have limitations for example when 

I don't think it has anything to do with interworking with a legacy SIP 
device. You can ensure that the audio from the microphone and the video 
from the camera have not been manipulated by JavaScript prior to 
encoding and sending over the RTP channel, and make corresponding 
identity assertions as well. But I don't see how you plan to ensure that 
keys pressed on the keyboard have not been manipulated by JavaScript 
prior to encoding and sending over the RTP channel... unless the plan is 
to have the keyboard be a MediaCapture device, have a consent dialog, 
and bypass the JavaScript entirely.

> audio. Are these issues solved for the other media?

Yes, to the extent that it is possible to ensure that the Audio and 
Video being sent over the channel are actually sourced from the local 
camera and microphone and have not been manipulated it is solved for the 
other media.

Additionally, the barrier to entry to inserting bogus reports of crime 
is exponentially higher for audio as compared to text, and again for 
video as compared to audio, so I think that the risk for RTT is greatest.

Again, is the plan to make the keyboard a MediaCapture device or is the 
plan to allow arbitrary JavaScript the ability to generate the 
characters that are being sent over the RTT channel?

Matthew Kaufman

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 04 Dec 2012 20:54:51 +0100

On 2012-12-04 19:53, Matthew Kaufman wrote:
>>> There's a bunch of real engineering issues to consider as well. If 
>>> we allow sending of T.140/RFC4103 text on a PeerConnection from 
>>> JavaScript then:
>>>
>>> - Is the JavaScript rate-limited such that it cannot use this 
>>> channel as a congestion-unconstrained browser-to-browser data channel?
For T.140 , 50 characters per second is a safe highest limit.
For XEP-0301 it might be harder to predict, because it has 
retransmission for synchronization, and for editing a bit back that can 
cause huge bursts of data.

However, data channels for other purposes might need a lot more. Do all 
data channels need to be standardised and their names and restrictions 
be coded into the browser itself? If not, the malicious application sets 
up another data channel to do its malicious activity without restrictions.
>> The normal thing in a total conversation call is to activate all 
>> three media as soon as possible after call completion. A video 
>> channel can do much more harm than the RTT channel.
>
Yes, I came in late. When I saw that rtcweb was shaping up and gaining 
momentum, I thought it was time to check if real-time text and other 
features of accessibility interest was catered for.

If an incoming session can just grab keyboard input and send it, then 
yes you would need a consent dialogue.

It would be good if the most common case of session setup still has the 
concept of calling and answering often used in other personal 
communication tools, and that the concent can be implicit in these 
operations.

But of course other use cases are possible where explicit consent might 
be needed so that what you intended for local typing in another app not 
just suddenly is sent over an incoming session.

>>> the user? (In other words, is the text channel also able to be 
>>> marked the same way a camera and microphone can be marked to prevent 
> I don't think it has anything to do with interworking with a legacy 
> SIP device. You can ensure that the audio from the microphone and the 
> video from the camera have not been manipulated by JavaScript prior to 
> identity assertions as well. But I don't see how you plan to ensure 
> that keys pressed on the keyboard have not been manipulated by 
> JavaScript prior to encoding and sending over the RTP channel... 
> unless the plan is to have the keyboard be a MediaCapture device, have 
> a consent dialog, and bypass the JavaScript entirely.

Yes, I thought about end-to-end protection from manipulation in the 
middle. That may be feasible by applying SRTP or the corresponding 
security in the data channel when data goes end-to-end. But if there is 
a gateway that needs to break the secured connection and do transcoding, 
it also can inject malicious contents.

But you talked about the local path through Javascript between keyboard 
and browser, and the risk that the app contains malicious code.
Yes, there will be a tricky balance. There will be valid reasons to use  
other than keypress as text input. e.g. voice-to-text, or assistive 
technology producing text in other ways.

Having keyboard input directly to the browser might cause unwanted 
restrictions. I think you can create a suitable security level better 
than I can and draw the conclusions on what is the most feasible 
implementation strategy.

> camera and microphone and have not been manipulated it is solved for 
> the other media.
Have you sacrificed the function for sending prerecorded video and 
speech from a file?
> Again, is the plan to make the keyboard a MediaCapture device or is 
> the plan to allow arbitrary JavaScript the ability to generate the 

Most of the discussions lean towards Javascript control over text 
transmission.
Your concerns might pull it a bit towards the other side - Browser 
controlled.

As usual, the security issues need to be included in the specifications, 
and you can help to bring up the issues and conclusions.

/Gunnar

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 4 Dec 2012 15:08:09 -0500 (EST)

> From: Randell Jesup <[email-masked]>
> 
> spotty at best.  [...]
> And Asterisk seems big, until 

Your statement is completely correct but it also obscures an important
point:  Asterisk passes through RTP packets (or has them bypass the
switching host entirely), and so it supports *all* media carried by
RTP.  In one sense, that means its support for text/t140 RTP was
trivial to implement.  In another sense, it means that supporting
text/t140 RTP in a PBX is simple because it *is* RTP.

(Similarly, the series of PBX products derived from the sipX
open-source project (sipXecs, EADS/PlantCML Patriot/Sentinel, SIPez,
Avaya SCS/AvayaLive Connect) all support text/t140 in the same trivial
manner.)

Dale

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 04 Dec 2012 21:38:57 +0100

> Avaya SCS/AvayaLive Connect) all support text/t140 in the same trivial
Well.
Many SIP products support T.140/RFC4103 in the trivial sense you mean. 
Just pass through.

But Asterisk can do a bit more. It has text APIs that can generate and 
receive text from an RTP channel with RFC 4103 activated.
It also can resolve packet loss and recover text from redundancy to 
correct the text stream.
It is therefore a good environment for gateways for real-time text.
Because of its reasonable multi-media characteristics it can also handle 
calls with combination of audio, video and real-time text.

Gunnar

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Dec 2012 14:41:11 -0800

On 4 December 2012 11:54, Gunnar Hellström <[email-masked]> wrote:
> However, data channels for other purposes might need a lot more. Do all data
> channels need to be standardised and their names and restrictions be coded
> into the browser itself? If not, the malicious application sets up another
> data channel to do its malicious activity without restrictions.

The data channel is congestion controlled, though the details of that
congestion control are TBD.  Currently, if we assume SCTP congestion
control, that would be approximately the same as a single TCP flow.
That would lead to something no worse than a websocket.

RTP uses less rigorously defined congestion control.  So the issue
that Matthew raises is a valid one.  Typical usage scenarios are
actually irrelevant in this context.

WRT consent, I think that keyboard focus could solve the issue, but
that could require specific widgets.  But then if you consider RTT to
follow a media pipeline to display as Dale suggests, that implies new
display widgets as well.  Note that the browser already has access to
your keyboard input...as long as you have the window in (keyboard)
focus.

>From that perspective, I can see how Adam reaches his conclusion - it
removes a lot of these sorts of questions.

~~~~
On the other hand, if you want to consider end-to-end (keyboard to
display) authentication, integrity and confidentiality, then you might
naturally wish to require the control provided by having specific
widgets.  That involves all the tainting stuff and wotnot.  This is
the point that I'd like to see debated a little more.

--Martin

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Dec 2012 15:22:22 -0800

On 12/4/2012 2:41 PM, Martin Thomson wrote:
> widgets. That involves all the tainting stuff and wotnot. This is the 
> point that I'd like to see debated a little more. --Martin

Sure. But not here. That whole conversation needs to move to the w3c 
public list.

Matthew Kaufman

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Dec 2012 15:39:42 -0800

> the point that I'd like to see debated a little more.

[BA] I think that the need for end-to-end RTT support might depend on the scenario.  If we are talking about a scenario which includes video (which might include ASL signing) and audio (which might include speech from the interpreter) then the audio/video would always be protected by SRTP (potentially end-to-end if DTLS/SRTP is used).   In such an environment,  problems with the integrity of realtime text delivered hop-by-hop might be detectable by at least one participant in the conversation.  On the other hand if realtime text is all that is provided (e.g. the user is hearing and speech impaired and voice/video is either not used or is not brought up) then integrity issues might not be detectable, because there is nothing to compare it against. 

Also, there are probably some scenarios in which additional latency might become annoying (such as a multi-user-chat where the delays might cause people to have to revise their replies-in-progress as characters stream in by fits and starts).   For example, in a scenario with some packet loss where re-transmissions are occurring, TCP-based transport (e.g. XEP-0301 running over BOSH) would exhibit head-of-line blocking and it might not be possible to accurately mimic the inter-character timing of the sender.

---

From: Mark Rejhon <[email-masked]>
Date: Tue, 4 Dec 2012 19:02:08 -0500

On Tue, Dec 4, 2012 at 6:39 PM, Bernard Aboba <[email-masked]> wrote:
> For example, in a scenario with some packet loss
> where re-transmissions are occurring, TCP-based transport (e.g. XEP-0301
> running over BOSH) would exhibit head-of-line blocking and it might not be
> possible to accurately mimic the inter-character timing of the sender.

Depends on implementations & on length of stalls.  You can still
accurately mimic the inter-character timing of the sender, even with a
random BOSH poll (every 0.5 to 1.5 second) with inaccurate timings.
XEP-0301 real-time text is simply a buffered series of text transforms
(e.g. appends, inserts, deletes, and optional pauses), so the buffer
provides some immunity to stalls.  In my XEP-0301 implementations, the
buffer is 1 second, providing immunity to ping stalls less than that.
 A TCP/IP stall of 3 seconds just simply causes a 2 second pause, then
playback resumes, with stalls under 1 second often not being visible
to the end user.

Obviously, this is for rich XEP-0301 implementations, supporting the
full standard.  Implementors can still output in blocks, or
word-at-a-time, time-smoothed text, or other implementor-preferred
methods of text output.

For other readers not familiar, see:
http://www.realjabber.org/anim/real_time_text_demo.html

Mark Rejhon
Author of XEP-0301

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 05 Dec 2012 09:26:31 +0100

> opening a data channel. What's the answer for this case?
Raising a consent dialog before activating the keyboard seems kind of 
weird to me.

Let's not go there; consent dialogs have so far been for activiating new 
devices, not for activating transmission channels.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Dec 2012 11:50:02 +0100

WG,

We have been running a consensus call regarding Text Communication in
RTCWEB. The consensus call did not result in any clear conclusions.
However a couple of observations we chairs can make.

  - There is interest in providing an inter-operable solution for
    real-time text communication

  - Some participants believe that the data channel can be part of a
    solution.

  - There has also been discussion regarding using T.140 over RTP.

  - A lot of questions on what amount if any of standardization that is
    required to provide the functionality.

We don't see any consensus on the approach at this point.  We recommend
that the people interested write individual drafts that clarify their
approaches for the WG; this may also help the WG understand if this is
primarily an issue for the IETF or the W3C.

Regards

Magnus Westerlund
As WG chair