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

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

> From: Randell Jesup <[email-masked]>
> 
> Not so simply; MediaStreams in Firefox currently have a strong idea that 
> data has a time for display and a duration. This could be worked around, 
> and might need to for other reasons - but there was no design goal for 
> carrying non-media data in MediaStreams.

I'm not understanding you here.  RTT *is* media.  It may be that you
receive RTT media after its desired display time, but the same thing
can happen with audio and video, and you need some sort of strategy
for coping with that.  (I assume that there is an explicit or implicit
"expiration time", the time after which the data should be discarded
rather than an attempt made at catching up.  But one can construct an
expiration time for RTT media as well as audio or video media.)

> > - Because there is only one implementation per browser, there is less
> >    total implementation effort and the average implementation is more
> >    likely to work well.  It will also have a consistent UI if the user
> >    uses the same browser with multiple web sites.
> 
> I'll note that virtually nothing in webrtc, let alone rtcweb, really 
> touches on UI - UI is generally (and almost must be) handled by the JS 
> application. Assuming the UI is tied to the signaling and media 
> components/hardware is the classic SIP hardware UA way to look at it (or 
> SIP software application).
> 
> We'd need to define a way to inject keystrokes into the stream, and get 
> them out (and perhaps process them into a displayable string). In theory 
> the W3C could define RTT display elements you could hook an RTT media 
> track to; or it could be subsumed into existing audio/video media 
> elements (though there's still the input side, and this might be unduly 
> restrictive of possible applications layouts and uses).

My understanding, or really, assumption, is that the display of WebRTC
video will be done with something that looks and acts somewhat like
current browser video players.  And that, from the Javascript point of
view, it will run as an autonomous process.  The Javascript will make
API calls to tell the video player that RTP packets arriving on a
certain port, with certain codec numbers, are to be decoded with a
certain codec, and then displayed via the video player.  That way,
once the video stream is set up, the Javascript doesn't touch the
media data.

This shields the process of video display from any real-time
limitations of the Javascript engine.  It also allows the browser
engineers to isolate the real time problems of video display into a
small, non-programmable part of the browser.

Similarly, the Javascript establishes a connection between the video
input device, and a particular RTP port, destination address/port,
codec number, codec, etc., but does not need to perform any action to
support ongoing video transmission.

And I expect that audio reception and transmission will handled in a
similar way, with adjustments for how the Javascript specifies the UI
input and output devices.

*Within this conceptualization*, the most *uniform* implementation of
RTT is for it to be handled as "another media type", and that the
Javascript will set up the connection between the RTP and some sort of
RTT input and RTT output widgets, but once the Javascript calls the
APIs to establish the connection, the Javascript does not need to
handle the media data.

However, RTT can be considered to be different from other media:

- The data rate of RTT media is several orders of magnitude lower than
other media, and so it is plausible to have Javascript process the RTT
media.  But this leaves RTT processing at the mercy of Javascript
execution, and my experiencde suggests that Javascript execution is
unreliable on the sub-second timescale.

- The Javascript programmer can plausibly desire to program his own RTT
input/output widget (whereas we do not expect him to do so with audio
and video).  But this is likely to lead to a proliferation of mediocre
RTT input/output widgets with inconsistent UIs.  (By comparison,
free-form long-text input fields are implemented directly by browsers
and do not need Javascript support.)  And *requiring* the Javascript
programmer to program his own RTT input/output widget will lead to
very scattered implementation.

- If we carry the RTT media in some manner other than RTP, different
machinery will be needed to hook the RTT input/output widget to the
transport than is used for audio and video media.

But if we want to handle RTT as a first-class media type, it seems to
me we aren't increasing the total amount of work by handling it like
we do audio and video.  The most significant change is that we're
specifying the real-time part of RTT to be handled directly by the
browser, rather than having every WebRTC coder implement it
individually.

Dale

---

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

> browser, rather than having every WebRTC coder implement it
I think there are a lot of good reasoning in you entry.
A Real-time text UI can be quite tricky and quite processor-consuming.
Imagine two rapid typers, typing along with over 10 characters per 
second, one local and one remote typing simultaneously with a UI 
showing  their entries building up in the real-time text preview style, 
as traditional chat but with the last entries being real-time entries 
continuously building up by entered text. It might be heavy for JS to 
recalculate and display the text area in such conditions.

It might be more fair to the programmers to have the browser provide 
widgets for such RTT UI, and the JS level just assign a window 
placement, size, size of characters etc, and then let the browser handle 
the presentation.

Gunnar

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 4 Dec 2012 22:25:26 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Gunnar Hellström
> Imagine two rapid typers, typing along with over 10 characters per second,
> one local and one remote typing simultaneously with a UI showing  their
> entries building up in the real-time text preview style, as traditional chat but
> with the last entries being real-time entries continuously building up by
> entered text. It might be heavy for JS to recalculate and display the text area
> in such conditions.
> 
> widgets for such RTT UI, and the JS level just assign a window placement,
> size, size of characters etc, and then let the browser handle the
> presentation.

If you want browser vendors to add native "RTT" input and output widgets and map this to GetUserMedia, you really need to take this to the W3C mailing list. It is public.

Matthew Kaufman

---

From: Mark Rejhon <[email-masked]>
Date: Tue, 4 Dec 2012 18:29:31 -0500

>> entered text. It might be heavy for JS to recalculate and display the text area

I should note that this isn't true anymore for modern optimized
browsers, especially on GPU accelerated platforms.  They are
surprisingly efficient, thanks to nearly two decades of browser wars.
 I'm able to update text inside a fixed-size <div></div> using
JavaScript well north of tens or hundreds of thousand times a second
in desktop browser programming, the optimizations in browsers really
show.

My preference: I'd say let rtcweb provide simple text receive/delivery
API's (bare simple minimum to meet legislative requirements), and let
JavaScript provide presentation -- it's just one line of text, such as
divTag.InnerHTML = "hello, world";
It's high-performance nowadays in modern, optimized browsers,
especially when using fixed CSS bounding boxes (to prevent text reflow
overheads).  Just let the web developer worry about presentation of
real-time text, IMHO.

It simplifies things, it keeps webrtc to just the details and API level stuff.
No need to complicate things and bring W3C stuff into play for RTT.

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

---

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

> surprisingly efficient, thanks to nearly two decades of browser wars.

Agree.

> JavaScript provide presentation

Then we need answers to my other questions. How do we rate-limit that 
data channel, how do you prevent malicious script from tampering (or do 
you not care), etc?

Matthew Kaufman

---

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

> Then we need answers to my other questions. How do we rate-limit that data
> channel, how do you prevent malicious script from tampering (or do you not
> care), etc?

It's my assumption that data channels are designed to handle rates
higher than a few bytes a second.  If data-channels are used
generically for other media (e.g. photo transfer, file transfer,
network video game, etc) it's quite easy to assume that the bandwidth
of data channels would be in some significant number of kilobytes per
second.

For bandwidth rate, both T.140/RFC4103 and XEP-0301 can run at rates
at under 1 kilobytes a second (8 kilobits a second), including all
protocol overhead, in the worst-case typing scenarios.   Only
situations such as copy-and-pastes would cause sudden surges, but if
the channel is not rate-limited, the copy and pastes will just carry
through. (This is preferred).

For transaction rate, XEP-0301 is specified to buffer key presses
(with or without interval) at a 0.3 to 1.0 second transmit interval,
but this is not enforced.  (RFC4103/T.140 specifies similiar numbers).
 XEP-0301 can function usefully at 2 second transmit intervals (though
both I and Gunnar recommends against this), or at immediate
character-at-a-time transmit.  (Not recommended either, since it
spikes bandwidth, because it potentially means 30 packets a second
when holding a key press down at a typematic of 30 chars/sec).

I do not think it is the responsibility of this taskgroup to decide
absolute bandwidth and transaction limits for RTT; it should be
afforded the same neutrality as a generic data channel.   However,
reasonable universal protections are fine (e.g. rate limiting,
length-per-transaction limits similiar to standard instant messages,
etc.)    Copy and pastes are contentious, only because of its
implications for privacy accidents, and for bandwidth, but are also
useful because people use copy & pastes during regular messaging.
The problems for RTT is similiar to the problems for standard text
messaging -- e.g. excessively long frequent copy & pastes is exactly
the same kind of problem for both RTT and for standard instant
messaging.

Thus, I'd therefore look at existing messaging precedents for security
considerations for RTT; with only minor differences (e.g. due to the
real-timeness of RTT) without encumbering RTT excessively.   The same
message-length considerations can be transferred to RTT (at least for
message-based RTT), and transaction rate can be limit to meet the
lowest recommended number found in existing RTT specs (e.g. rate limit
to one packet every 300ms, plus a bit of safety headroom for surges
caused by TCP stalls and other effects).  I personally prefer my
implementations to have no rate limit, though I understand the need to
block DoS issues caused by theoretical malicious incoming RTT, if they
are not solved by other means in a non-inconvenient manner...

Mark Rejhon
Author of XEP-0301

---

From: Randell Jesup <[email-masked]>
Date: Wed, 05 Dec 2012 03:27:47 -0500

> of data channels would be in some significant number of kilobytes per

I've transferred 270+MB files from myself to myself (local loopback) 
through IP sitting in an IETF meeting, in a time measured in seconds.  
So DataChannels can be high bandwidth.  It's also congestion controlled 
(currently using default SCTP congestion control, which is TCP-like).  
Eventually we hope to move it to a low-delay CC algorithm to coordinate 
with RMCAT.  In the meantime, we've discussed bandwidth limitations on 
the DataChannel based on application wishes (such as percentages, a 
fixed amount, combining percentages with fixed upper/lower limits, 
etc).  See discussions and drafts from recent IETFs.

> through. (This is preferred).

This should be absolutely no problem.

> the same kind of problem for both RTT and for standard instant

We should think about more than just RTT; RTT is just one form of text 
communication as we've discussed.  There's a stairstep of forms from 
char-by-char RTT through XEP301 to SMS to AIM/Jabber/IRC to forums to 
email (to snailmail), and plenty of ways you can vary them (speed of SMS 
delivery, etc).  All have their uses - and rtcweb is not limited to 
realtime communication.  (You'd think so, but in fact it's really not.)  
There are possible store-and-forward uses (both for audio/video and 
data), which could be leveraged in systems with poor connectivity or in 
distributed networks (think Arab Spring, etc).  These might not be ideal 
efficient uses from a pure networking perspective - but they'll be a 
technology easily available to people without having to build all the 
related facilities (encryption, codecs, negotiation, audio/video 
capture, etc).

These certainly aren't core usecases - but they're possibilities created 
by providing building blocks and not apps with a bow on them.

> are not solved by other means in a non-inconvenient manner...

Pretty much agreed, with the proviso that no reasonable solution I can 
think of avoids the JS app being involved in the capture and display of 
text.  Perhaps the closest I could think of could be having the browser 
sign each character with a sequence number before handing it to the app 
(perhaps a chaining cipher if it's using a reliable channel, else a 
block cipher).  Then the receiver can verify it's signed by the same 
cert used for the media (not available directly to the app).  Display is 
trickier if you don't get magic certifying-RTT-text-display-boxes in the 
DOM.

NOTE:
As mentioned, a bunch of this belongs in the W3C, and I think most of 
the rest should be a separate document (here or in another WG) or a new WG.

-- 
Randell Jesup
[email-masked]

---

From: <[email-masked]>
Date: Wed, 5 Dec 2012 09:40:16 +0100

That's the gist of it:
- with audio/video, the RTP stream sources (camera, microphone) are fully under browser control.
- With RTT, there is currently no browser-controlled source for text entered by the user. This would have to be a new HTML element. A consent dialog for this element looks like overkill, though. The user must type in it to make it send. That's different from camera/microphone which send without user activity.

RTT over the data channel seems like a simpler option to me. TCP is real-time enough for text. I frequently use ssh to log into far away servers, and the occasional delayed character is not that annoying. And with ssh, the delay and chance of retransmission is twice that of Real Time Text.. Is there really a use case which requires tight synchronization between RTT and A/V streams?

Rgeards
Wolfgang Beck

Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Wolfgang Beck
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 581 2832 (Tel.)
www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 05 Dec 2012 10:39:33 +0100

> RTT over the data channel seems like a simpler option to me. TCP is real-time enough for text. I frequently use ssh to log into far away servers, and the occasional delayed character is not that an…
I think you are right in your assessment.
The requirement is not for tight synchronization between RTT and A/V.

The user expectation is for conversational flow.

If you type a question, and expect a response start flowing in text, you 
expect the other party to start responding quickly. If a response is not 
beginning quiclkly enough, or there are long pauses, the waiting user 
starts wondering if the question was not understood, or needed extra 
info or so, and might start sending additional info or other questions, 
leading to confusion and conversational collissions.

For this conversational application, I assess that occasional extra 
delay of up to 4 or even 5 seconds, not more than once per minute are 
acceptable. ( I have no research for acceptance of exactly this 
situation with mid-response delay. )

Combined with video, there is of course a little bit of extra wondering 
by the receiving user, seeing the typing user, but for some seconds not 
seeing any resulting text. Still, within 5 seconds and not so often, it 
likely just causes a bit of annoyance.

Gunnar

---

From: <[email-masked]>
Date: Wed, 5 Dec 2012 12:51:21 +0000

Gunnar Hellström wrote:
>> RTT over the data channel seems like a simpler option to me. TCP is real-
>time enough for text. I frequently use ssh to log into far away servers, and the
>occasional delayed character is not that annoying. And with ssh, the delay and
>chance of retransmission is twice that of Real Time Text.. Is there really a use
>case which requires tight synchronization between RTT and A/V streams?
>If you type a question, and expect a response start flowing in text, you expect
>the other party to start responding quickly. If a response is not beginning
>quiclkly enough, or there are long pauses, the waiting user starts wondering if
>the question was not understood, or needed extra info or so, and might start
>sending additional info or other questions, leading to confusion and
>conversational collissions.
>
>For this conversational application, I assess that occasional extra delay of up to
>4 or even 5 seconds, not more than once per minute are acceptable. ( I have
>no research for acceptance of exactly this situation with mid-response delay. )
>
>Combined with video, there is of course a little bit of extra wondering by the
>receiving user, seeing the typing user, but for some seconds not seeing any
>resulting text. Still, within 5 seconds and not so often, it likely just causes a bit
>of annoyance.
>

So can we conclude that the RTCWeb data channel can provide good enough transport for Real Time Text service? If so, would there still be some other showstoppers why implementing an RTT-compliant service on top of RTCWeb browser would not be possible? I don't say that having some *additional* support in the browser to make the RTT implementation *easier* would not be important, but that would be less critical, and could be solved by JS libraries. 

Markus

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 05 Dec 2012 14:29:07 +0100

On 2012-12-05 13:51, [email-masked] wrote:
> So can we conclude that the RTCWeb data channel can provide good enough transport for Real Time Text service? If so, would there still be some other showstoppers why implementing an RTT-compliant service on top of RTCWeb browser would not be possible? I don't say that having some*additional*  support in the browser to make the RTT implementation*easier*  would not be important, but that would be less critical, and could be solved by JS libraries.
I think that solution is feasible.

It seems that the following is needed:

Standards for
1.-the Data channel label name.
2. -The characteristics of the Data Channel: semi-reliable, give up 
after maximum 5(?) seconds, indication on gap in reception, delivery in 
order.

3. -The format of text. ITU-T T.140. ( using UTF-8 )     ( or core of 
XEP-0301 in some way)
4. -Minimum transmission interval. ( 200 ms ?)

5. Translation in SIP/rtcweb gateway between  RFC 4103 sdp and 
rtcweb/t.140 sdp

One reason for the need of the standards is for proper interworking with 
SIP sessions.

Libraries for
Time sampling, transmission and local display of keyboard input as RTT data.
Reception, and presentation of received text.
Handling of single party and multi-party calls.
Handling coordination in same call as audio and video.

Not showstopper, but I wonder: Are there any thoughts of having anything 
similar to SIP media-tags and language-tags to show capabilities and 
preferences even before call negotiation?  That could be if importance 
for routing of sessions to the best capable terminal matching the 
preferences of the caller or the opposite.

Gunnar

---

From: Eric Burger <[email-masked]>
Date: Wed, 5 Dec 2012 05:43:45 -0800

I like #1-4 below. I do not like #5 as a hard requirement. If we may not really deliver voice or video to the legacy network, I am not hung up on not delivering RTT either.

On Dec 5, 2012, at 5:29 AM, Gunnar Hellström wrote:

>> So can we conclude that the RTCWeb data channel can provide good enough transport for Real Time Text service? If so, would there still be some other showstoppers why implementing an RTT-compliant service on top of RTCWeb browser would not be possible? I don't say that having some *additional* support in the browser to make the RTT implementation *easier*
>>  would not be important, but that would be less critical, and could be solved by JS libraries. 
>> 
> 2. -The characteristics of the Data Channel: semi-reliable, give up after maximum 5(?) seconds, indication on gap in reception, delivery in order. 
> 
> 3. -The format of text. ITU-T T.140. ( using UTF-8 )     ( or core of XEP-0301 in some way)   
> 5. Translation in SIP/rtcweb gateway between  RFC 4103 sdp and rtcweb/t.140 sdp
> 
> 
> One reason for the need of the standards is for proper interworking with SIP sessions. 
>  
> Libraries for
> Not showstopper, but I wonder: Are there any thoughts of having anything similar to SIP media-tags and language-tags to show capabilities and preferences even before call negotiation?  That could be if importance for routing of sessions to the best capable terminal matching the preferences of the caller or the opposite.
> 
> Gunnar
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 05 Dec 2012 14:47:16 +0100

On 2012-12-05 14:43, Eric Burger wrote:
> If we may not really deliver voice or video to the legacy network, I am not hung up on not delivering RTT either.
What does this mean?
I thought someone talked about not building silos anymore?

Gunnar

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 05 Dec 2012 17:15:57 +0100

On 12/05/2012 02:47 PM, Gunnar Hellström wrote:
>> If we may not really deliver voice or video to the legacy network, I 
>> am not hung up on not delivering RTT either.
> What does this mean?
At the Protothon meetup in London, someone created an application that 
created an ambient sound by relaying sounds across peoples' laptops - 
you created a sound, and it came out of someone else's speaker, offering 
an unique, created-on-the-fly, multi-person musical instrument.

That application (which was created by ~4 people in ~8 hours) will 
likely never be used to deliver any kind of content to the legacy network.

Of course the legacy network needs its voice, and some newer parts of 
the legacy network need their video and RTT. We want to find good ways 
of feeding that to them.

But that's not the only game in town.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 7 Dec 2012 03:09:16 +0000

Gunnar, 

I'd be very interested to see someone prototype up a gateway that, on one side, downloaded some JS to a web browser that created a DataChannel connection from the browser to the gateway and provide a UI for RTT. On the other side of the gateway it could do SIP with T.140. My guess is that someone could get this working and it would help see if things were missing from the WebRTC API / RTCWeb protocols to be able to do this. I suspect that items 1,2,3, and 4 are in the control of the gateway so may not need to be standardized. As to #5, I would hope the SDP in  WebRTC is compatible with SIP offer / answer so I would hope nothing complicated was need to be specified for #5. As to language tags, the browser can use the Accept-Languages header in the HTTP. 

Cullen

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 07 Dec 2012 07:34:24 +0100

> I'd be very interested to see someone prototype up a gateway that, on one side, downloaded some JS to a web browser that created a DataChannel connection from the browser to the gateway and provide…
Cullen,
Yes, I think that is a good and realistic challenge, and an activity 
that I would like to participate in.
You are also right that for the gateway application it can likely be 
done without standardization, when the gateway implementation is also 
managing the web page used for the UI.

The need for standardization comes in for the following cases:
a. When you from the same UI want to have a SIP call at one moment, and 
a WebRTC call to another user of another browser and web server at 
another moment.

b. When you want to separate the management and development of the 
gateway from the web pages and web servers.

c. When you want to encourage development of the smartest web page for 
RTT communication that can fit into any server environment and have 
communication with other web pages used in that or other environments.

Thanks for the hint on Language-tags. Is there anything similar for 
media-tags. Declaring and detecting "text" media capability or 
requirement can be a way to select the proper terminal among a set being 
reachable through the same address. This is not urgent at the moment, 
just good to know if such mechanisms are already in place.

A prototype is likely perfectly doable, and can by simple agreement also 
include any of cases a,b,c.
Maybe Adam's promised development is already half-ready with the UI part 
to incorporate in this effort. ;-)

Gunnar

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Dec 2012 09:45:18 -0800

On 6 December 2012 22:34, Gunnar Hellström <[email-masked]> wrote:
> Thanks for the hint on Language-tags.

Sadly, Accept-Language is a feature that is almost universally
ignored.  I'm sad to say it, but people trust geo-ip services far more
than they trust this particular header.  You only need to travel to
learn this sad fact.

> Is there anything similar for
> media-tags. Declaring and detecting "text" media capability or requirement
> can be a way to select the proper terminal among a set being reachable
> through the same address.

Detecting "text" capability would not be necessary in Cullen's
proposed scenario.  The capability would be provided by the
application.

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 07 Dec 2012 21:45:58 +0100

> proposed scenario.  The capability would be provided by the
Yes, understood. I was thinking about more advanced routing functions etc.
Exploring such things can wait, and I know that they are very seldom used.

We need to sort out the basic functionality first.

Gunnar

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Dec 2012 13:57:16 -0700

Begin forwarded message:

> Yes, I think that is a good and realistic challenge, and an activity that I would like to participate in.
> You are also right that for the gateway application it can likely be done without standardization, when the gateway implementation is also managing the web page used for the UI.
> 
> a. When you from the same UI want to have a SIP call at one moment, and a WebRTC call to another user of another browser and web server at another moment.
> 
> b. When you want to separate the management and development of the gateway from the web pages and web servers.
> 
> c. When you want to encourage development of the smartest web page for RTT communication that can fit into any server environment and have communication with other web pages used in that or other environments.

I think much of this could be covered in a internet draft that said how to write a gateway from WebRTC RTT over Data Channel to SIP / T.140. It would be good to have and ID that showed how to do that. That draft could cover things like how frequently to send data and formatting and such. It could also covering gatewaying to RTT over XMPP. ( I won't even mention MSRP :-)

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 11 Dec 2012 20:50:31 +0100

On 2012-12-11 20:19, Dale R. Worley wrote:
>> From: Gunnar Hellström <[email-masked]>
>>
> In SIP, a user agent can register with the "sip.text" capability
> indicator (RFC 3840, 3841) to indicate that it supports text media:
>
>      Contact: <sips:[email-masked]>;text
>
> An INVITE can specify that it should be routed to a UA that has
> registered with such a capability:
>
>      Accept-Contact: *;text
>
> Also, if the initial SDP includes an m= line that specifies text
> media, call routing can prefer a Ua with text support.
>
> Dale
Yes, it is these functions I am referring to.

They are well defined on the SIP side, and look useful.
But they are used to a large degree on the SIP Header level.
So far I have only seen the SDP level clearly specified in rtcweb.

My question was if there have been any thoughts about establishing 
anything similar to these SIP header parameters in rtcweb, so that the 
routing functions based on media and language capabilities can be 
established.

Gunnar