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: gunnar.hellstrom@omnitor.se web: www.omnitor.se

-----Ursprungligt meddelande----- Från: H323MAIL [mailto:H323MAIL@vocaltec.com] Skickat: måndag, augusti 30, 1999 04:41 Till: ITU-SG16@mailbag.cps.intel.com; rem-conf@es.net Ämne: RE: Submission of draft-ietf-avt-rtp-text-00.txt to IETF

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 gunnar.hellstrom@omnitor.se or to the rem-conf@es.net 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