Subject: I-D ACTION:draft-ietf-avt-rtp-text-00.txt

From: [email-masked]
Date: Wed, 01 Sep 1999 07:02:55 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload for Text Conversation
	Author(s)	: G. Hellstrom
	Filename	: draft-ietf-avt-rtp-text-00.txt
	Pages		: 7
	Date		: 31-Aug-99
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-text-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-text-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Sep 1999 21:40:25 -0400

I have a minor comment on this.

For redundancy, it makes use of rfc2198. There is nothing wrong with
this, but it is not the only scheme one can use for recovery from
errors. The FEC payload format, soon to be an RFC (under consideration
by IESG) provides an additional mechanism (FEC itself can be used with
rfc2198 to carry the FEC). This draft, and others that have been
recently specifying the use of redundancy for loss resilience, might be
more general by also indicating that the FEC payload format can be used
also.

-Jonathan R.

[email-masked] wrote:
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 3 Sep 1999 16:21:44 +0200

A response on selection of redundancy method.
---------------------------------------------

Jonathan Rosenberger indicates that FEC also could be a feasible redundancy
method as well as RFC 2198.
When doing research for the redundancy method, I studied FEC, but selected
RFC 2198. The main reason was to try to keep overhead low.
The main load in the text conversation application will be the packet
headers and RTP headers. The text itself is usually minimal.

If I understand FEC right, FEC creates redundancy by using a separate
stream, including packet headers and all what belongs to a media stream. For
the text case this would mean a big load increase. I do not want to force
that as the only solution, and I think it is good to keep the number of
alternatives low. It increases the opportunity of interworking.

I realise that it is important to develop the general redundancy mechanism
FEC, but based on the arguments above, I prefer to stick to what is
specified in the rtp-text draft.

Regards
______________________________________________
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: [email-masked] [mailto:[email-masked]]För
> Jonathan Rosenberg
> Skickat: torsdag, september 02, 1999 03:40
> Till: [email-masked]
> Kopia: [email-masked]
> Ämne: Re: I-D ACTION:draft-ietf-avt-rtp-text-00.txt
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Sep 1999 12:13:24 -0400

> A response on selection of redundancy method.

The FEC can be sent as a separate media stream, but it can also be sent
encapsulated in the redundant payload format. The result is that the
overhead can actually be lower; this is because you are using more
efficient FEC codes than just duplication of the payload. Here's an
example. Lets say you take two RTP packets, and generate an XOR over
them. This xor is sent as a redundant payload on top of the next RTP
packet. The result is that every other packet has a redundant payload
which is the xor of the previous two:

1    2    3    4    5    6     7
         1*2       3*4         5*6

          ^
          |
         1*2 a redundant payload of media packet 3

where a*b = a xor b. Call this "approach 1"

Now, consider the case of just sending each payload twice. The resulting
stream is:

1    2    3    4    5    6    7
     1    2    3    4    5    6
     ^
     |
     1 a redundant payload of media packet 2

Call this "approach 2".

Consider the overheads. Lets say the text is N bytes. In approach 1,
there is redundancy in every other packet. The ones without redundancy
have 40 bytes IP/UDP/RTP overhead. The ones with redundancy have 40
bytes, plus 4 bytes for the redundant rfc2198 header, plus 12 bytes for
the FEC, plus 1 byte for the main header plus N bytes of xor. So, over
two packets, its 40 + 40 + 4 + 12 + 1 + N = 97 + N bytes for 2N bytes of
text. The overhead percentage is thus 97+N/(97+3N)

In approach 2, each packet is the same. Its 40 bytes IP/UDP/RTP, plus 4
bytes rfc2198 header, plus N bytes redundancy plus 1 byte main rfc2198
header per N bytes of text. Thats 45+N for N bytes of text. The overhead
percentage is thus 45+N/(45+2N).

It turns out that approach 1 is better for N larger than 7 bytes, and
approach 2 better for N less than 7 bytes. Asymptotically for large N,
the FEC 1.5 times as efficient. Note that the error resiliency in either
case is identical - recovery from a single packet loss. Different FEC
schemes will result in different amounts of overhead and protection.

The conclusion to be drawn, however, is not that FEC has more overhead,
but that since it can be sent piggybacked using rfc2198, and since it
can be more efficient than just duplicating data, its overhead can be
lower.

-Jonathan R.

---

From: "Clayton Sigman" <[email-masked]>
Date: Fri, 3 Sep 1999 12:39:25 -0400

FYI: NASA typically uses a Reed-Solomon FEC that has
about 12% overhead (32 bytes of FEC for up to 232 bytes of data).
The FEC is appended after the data (i.e. same transport packet).

Clayton Sigman
ESDIS Systems Engineer for Mission Networks
NASA GSFC Code 585, Matrixes to 423
Mailstop Code 423
Greenbelt, MD 20771

email: [email-masked]

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
To: Gunnar Hellström <[email-masked]>
Cc: <[email-masked]>; Mickey Nasiri (ECS) <[email-masked]>;
Michele Mizzaro <[email-masked]>
Sent: Friday, September 03, 1999 12:13 PM
Subject: Re: SV: I-D ACTION:draft-ietf-avt-rtp-text-00.txt

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 4 Sep 1999 07:14:35 +0200

Further discussion on FEC redundancy.
-------------------------------------
Jonathan:
Thank you for the further explanation of FEC, and how it can be used within
the same stream. It seems to be a neat and general method for redundancy
coding, and I think it is good that it got this exposure.

For the text case, where the normal payload is 1 or 2 bytes per packet, I
see that the plain text redundancy and FEC with xor come out approximately
equal in terms of load, with the plain text method being slightly more
efficient.

Since the plain text method also has less complexity, I see no big reason to
introduce FEC in the text case.

Regards
Gunnar

______________________________________
Gunnar Hellström
LM Ericsson
Sweden

Tel +46 751 100 501
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

> -----Original message-----
> From: [email-masked] [mailto:[email-masked]]För
> Jonathan Rosenberg
> Skickat: den 3 september 1999 18:13
> Till: Gunnar Hellström
> Kopia: [email-masked]; Mickey Nasiri (ECS); Michele Mizzaro
>
>
> Gunnar Hellström wrote:
> >