Subject: RE: Submission of draft-ietf-avt-rtp-text-00.txt to IETF

From: "H323MAIL" <[email-masked]>
Date: Mon, 30 Aug 1999 16:41:15 +0200

Hi Gunnar,

I believe we had this discussion before - And I still find no justification
to sending Text (which inherently must be lossless and is extreme low
bit-rate)
using RTP.  Nothing stops us from opening an TCP channel using OLC/CLC
procedures
and sending text over it.  I agree - when lip-sync is required, TCP delay
(on average
1/3 for text chat type apps) may miss out a little, but I don't believe
that to be
such a big issue.

The main problem I see is that using RTP on average text typist means that
IP/UDP/RTP/Text
packets are going to be sent every 2-3 characters, and even with
redundancy, packetloss
can still occur which is unacceptable.

- gur

The document "RTP Payload for Text Conversation" is submitted to IETF-draft
as agreed in the avt wg in the IETF Oslo meeting. Comments are welcome to
the author at [email-masked] or to the [email-masked] mail
list.

This RTP payload is used by H.323 Annex G Text conversation and text SET

ABSTRACT

   This memo describes how to carry text conversation session contents
   in RTP packets. Text conversation session contents is specified in
   ITU-T Recommendation T.140 [1].

   Text conversation is used alone or in connection to other
   conversational facilities such as video and voice, to form multimedia
   conversation services.

   This RTP payload description contains an optional possibility to
   include redundant text from already transmitted packets in order to
   reduce the risk of text loss caused by packet loss. The redundancy
   coding follows RFC 2198.

Gunnar Hellstr

öm
______________________________________
Gunnar Hellström
LM Ericsson
Sweden

Tel +46 708 204 288 or +46 556 002 03
Fax +46 8 556 002 06
Video +46 8 556 002 05
Txt (All kinds) +46 8 556 002 05
E-mail [email-masked]
WWW:     http://www.omnitor.se

---

From: "Michael Welzl" <[email-masked]>
Date: Mon, 30 Aug 1999 17:10:11 +0200

Hi,

> 1/3 for text chat type apps) may miss out a little, but I 

But what if you'd like to sync subtitles to a streaming movie?
Maybe offer a streaming movie with subtitles for different languages?
I think that's where this payload type could really be valuable.

> can still occur which is unacceptable.

In conjunction with a movie, it's probably just as acceptable or
unacceptable as losing part of the movie itself.

Regards,
Michael

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 30 Aug 1999 18:16:49 +0200

Comments on the questions from Gur, on the need for an RTP transport of
text.
----------------------------------------------------------------------------
----
The first application of the proposed RTP format is H.323 Annex G Text.
There, it is possible to select TCP or RTP for the transport, with a
preference for TCP.

RTP is added mainly for the cases when it is not feasible to use TCP. One
good example is in the loosely coupled conference situation (H.332 extended
to support text ). I am quite sure that in the close future there will
appear other situations where TCP is not feasible (mobile?).

I do not expect there to be any strict requirement on lip sync between video
and text presentation. A delay of .5 seconds is easily accepted. So, in that
sense, both transports can do.

I agree that character loss is unwanted.
With the indicated procedure to mark lost characters with a special
character ("Lightning"), I expect that the acceptance of character loss
increases over the case of loss without a sign. I expect an acceptable loss
rate during a text conversation session to be 1 or 2% if loss is marked.

As a summary, I still think there is a need for an rtp-based transport of
text.   Agree?

Specification of tcp or rtp in H.323 Annex G - Text
----------------------------------------------------
I am now reviewing H.323 Annex G Text, that is to be submitted as a white
document soon. I see that the description of selection of reliable or
unreliable transport is a bit vague.
I now plan to specify usage of the new DataProtocolCapability parameters tcp
and udp as values in DataApplicationCapability.application=t140. With the
interpretation of udp to be rtp-text.

Do you find this acceptable? It is clear and easily interpreted, but it
dictates use of IP as the network protocol. Will that limit the application?

Regards
Gunnar
______________________________________________
Gunnar Hellström
LM Ericsson
Sweden

Tel +46 8 556 002 03
Mob: + 46 708 204 288
Txt and video +46 8 556 002 05
Fax +46 8 556 002 06

e-mail: [email-masked]
web:    www.omnitor.se

> -----Ursprungligt meddelande-----
> Från: H323MAIL [mailto:[email-masked]]
> Skickat: måndag, augusti 30, 1999 04:41
> Till: [email-masked]; [email-masked]
> Ämne: RE: Submission of draft-ietf-avt-rtp-text-00.txt to IETF
>
>
> Hi Gunnar,
>