Re: [rtcweb] Text communication in RTCWEB sessions -job overview

Randell said:
"I'd state (from this very short description) that XEP is a better match 
for web and webapps (and WebRTC), though XML is not necessarily an ideal 
encoding format for JS apps.  But if interoperability with existing 
T.140-based infrastructure is important (and realize gateways will be 
involved!), then something easily transformed into RFC 4103/4351 might 
be preferred (if XEP can't be).  (But this does not necessarily mean 
transmission over RTP is a *requirement* between a rtcweb UA and the 
gateway.)  (Cue Hadriel's normal statement about gateways not always 
having access to the media channels.... ;-) Though he hasn't spoken 
about DataChannel gatewaying; it may make his head explode - sorry 
Hadriel.)"

This is a discussion carried over from rtcweb, about how to include text 
communication, ( primarily real-time text ) in sessions where audio and 
video is handled by rtcweb/WebRtc.

There is a need to interop with SIP calls with all three media defined 
by SDP and carried by RTP. Real-time text is a real-time medium as audio 
and video, it just has lower requirements on end-to end delay and synch. 
This combination is implemented and used both in user terminals and 
services. It is also specified and developed for emergency service 
access. The SDP and RTP for this is specified in RFC 4103, and the 
coding and presentation aspects in ITU-T T.140. It is a regular codec - 
transport pair as most video and audio codecs and RTP transports. Text 
is UTF-8 coded. Currently no implementations use AVPF, so gateways are 
needed even for RTP to RTP translation.

There is also a need to renew, enhance, improve Instant Messaging with a 
real-time mode so that communicating parties do not need to sit waiting, 
and do not need to shorten off their text entries manually to keep the 
conversation going. Real-time text transmits time-sampled and keeps the 
other party informed while text is created. IM is often coordinated with 
real-time conversational media to form a user experience that could be 
quite similar to the SIP multimedia call with all three media if only 
the IM part was more fluent. There is an XEP draft for this, XEP-0301, 
with XML embedded UTF-8-coded text.

These two methods to handle real-time text can be transcoded with some 
slight risk for features that are hard to represent well in the other 
coding.

It needs to be specified somewhere how to include real-time text in 
applications and servers using rtcweb for audio and video.
And how to achieve interoperability with SIP calls with the three media.

If the transport mechanism is not decided to be done in RTCWEB, I see a 
need anyway to have a consistent specification on how to negotiate and 
coordinate the three media in the session, so that a gateway can combine 
them on the SIP side. That would perhaps not be a true RTCWEB task, but 
very much depending on RTCWEB.

If the transport is decided to use RTCWEB, then APIs in WebRtc are 
needed for creating the text stream, sending real-time text and 
receiving real-time text. It seems reasonable to do the UI directly in 
JS.  The API could possibly have some similarity to the DTMF API.  That 
is at least UI actions that need to be commmunicated with a codec that 
insert or extract from an RTP payload codec, and acts timer-controlled 
rather than keystroke-controlled ( to avoid congenstion ).

So, two questions:

1. For non-rtp: How would coordination of audio and video in RTP be done 
with real-time text in some other browser-controlled communication, so 
that they can be handled as one session?

2. For RTP: What API additions would be needed to handle text input and 
output and communication through a rfc4103 codec?

Gunnar


On 2012-11-19 14:27, Randell Jesup wrote:
> On 11/19/2012 3:54 AM, Gunnar Hellström wrote:
>>
>> Yes, now after the overview of what would be needed in RTCWEB and 
>> WebRTC to include RTT I agree that starting with "draft-x-rtcweb-rtt" 
>> would be good for clarifying requirements and alternatives and draw 
>> conclusions.
>>
>> For your info, all real-time text methods in IP environments transmit 
>> time-sampled text, with sample time of 300 -700 ms.
>>
>> 1. RFC 4103 uses RTP, with redundancy to get reliability, and 
>> declares the stream in SDP as text medium. T.140 is the text codec, 
>> just saying that text shall be transmitted by UTF-8 and specifying 
>> some control codes. There are two payload types combined RED for 
>> simple RFC 2198 type redundancy and T140 for the text itself. The 
>> recommended sample time is 300 ms. This is in use in SIP applications 
>> and also specified in emergency service specifications.
>>
>> 2. RFC4351 also uses RTP in a very similar way to send RTT. But it 
>> has SDP declaration as audio and is transmitted multiplexed with 
>> audio codecs in a similar way as RFC 4733. The main use was intended 
>> to be for reliable transport of legacy real-time text through IP 
>> between VoIP gateways, where the extra ports needed for a separate 
>> text RTP stream through separate ports would possibly be expensive. 
>> RFC4351 was given Historic status already from its approval in order 
>> to discourage from any other use. Transmission is UTF-8-coded.
>>
>> 3. XEP-0301 is a draft XMPP extension, that transmits time sampled 
>> text in XMPP Messages, but not as Body, but as RTT XML elements, so 
>> it can be sent and presented as a gradually built up message, and 
>> then replaced by the message when completed. The recommended sample 
>> time is 700 ms, and in order to avoid jerky impression, the 
>> presentation of keystrokes are timed within these transmission 
>> intervals. Transmission is UTF-8.
>
> I'd state (from this very short description) that XEP is a better 
> match for web and webapps (and WebRTC), though XML is not necessarily 
> an ideal encoding format for JS apps.  But if interoperability with 
> existing T.140-based infrastructure is important (and realize gateways 
> will be involved!), then something easily transformed into RFC 
> 4103/4351 might be preferred (if XEP can't be).  (But this does not 
> necessarily mean transmission over RTP is a *requirement* between a 
> rtcweb UA and the gateway.)  (Cue Hadriel's normal statement about 
> gateways not always having access to the media channels.... ;-) Though 
> he hasn't spoken about DataChannel gatewaying; it may make his head 
> explode - sorry Hadriel.)
>

Received on Wednesday, 21 November 2012 13:12:35 UTC