Release 2000 Architecture Adhoc meeting

[Edgar Martinez [1]]

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 at omnitor.se
web:    www.omnitor.se

> -----Ursprungligt meddelande-----
> Från: H323MAIL [mailto:H323MAIL at vocaltec.com]
> Skickat: måndag, augusti 30, 1999 04:41
> Till: ITU-SG16 at mailbag.cps.intel.com; rem-conf at 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 at omnitor.se or to the rem-conf at 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