Subject: [AVT] A new version of the text transport is ready. FW: I-D ACTION:draft-ietf-avt-rfc2793bis-01.txt

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 8 Jan 2004 00:25:40 +0100

A new version of the RTP transport specification for real time interactive
text is available as described below.

Further down is a collection of comments received on the previous version,
and the responses from the authors.

I hope this specification will contribute to compatibility between
conversational multimedia applications as well as other applications
including text among available media.

Actions in ITU are depending on progress of this specification, so any
further comment should be submitted to the IETF avt group very soon.

Regards
-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, January 07, 2004 10:01 PM
To: IETF-Announce:
Subject: I-D ACTION:draft-ietf-avt-rfc2793bis-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: RTP Payload for Text Conversation
	Author(s)	: G. Hellstrom
	Filename	: draft-ietf-avt-rfc2793bis-01.txt
	Pages		: 19
	Date		: 2004-1-7

This memo describes how to carry text conversation session contents
in RTP packets. Text conversation session contents are 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-rfc2793bis-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2793bis-01.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-rfc2793bis-01.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.

------Answers on comments by Magnus Westerlund -------------------------

> 1. The abstract should probably be rewritten, I think the second
> paragraph is not relevant enough for this, while the RTP payload format
> for gateways are not mentioned at all.

Done. The second paragraph is replaced with a short notice about the two RTP
payloads.

> 2. I think the TOC is long enough to have it alone on the second page,
> i.e. I would propose that one start the introduction chapter on page 3.

Done.

> 3. The third last paragraph in chapter 1 seems to be a clear motivation
> for using TCP to transport text. I think there need to be some further
> elaboration on the reasons for using RTP, because the second last
> paragraph is not a obvious result of the previous one.

A description of the benefit of using RTP for text transmission is added.

> 4. Chapter 1, last paragraph, last sentence "and introduces a means of
> transporting text
>    interleaved with voice within the same RTP session.". Is " a means"
> correct english?

Changed to "a method".

> 5. In section 2, a reference to the complete information for RFC 2119
> would be nice.

Done.

> 6. Section 3:   "When transport of T.140 text session data in RTP is
> desired, the
>    payloads as described in this specification SHOULD be used." This
> sentence seems a bit strange. I don't think using normative words about
> using this payload format real has any meaning.

Changed to a sentence that describes the contents of the section instead.

> 7. Section 3.1, "This format is primarily used when text is transmitted
> on a separate
>    RTP session dedicated for the transmission of text and not shared
>    with other media, such as audio, DTMF, etc.  IP textphone devices
>    most commonly use this format."
>
> I think the restriction this payload format imposes on the media stream
> should be clearly documented in this section.

One unnecessary restriction has been eliminated. That was that FEC use was
described as possible for audio/t140 only. Now it is described as possible
for both formats. Other specific restrictions are not known. The description
of ITU-T T.140 gives the application framework and the natural restrictions
that follow from the intention of carrying text character by character in a
live conversation. We do not see a need to describe any specific restriction
here.

> 8. Section 3.2: "This T140block counter may be utilized to detect lost
> characters." I think one should clearly indicate that the counter if for
> detecting not lost characters but lost T140 blocks. I also think the
> comments made in the WG session in Minneapolis that the last block
> before a switch to another audio format can't be detected.

"characters" are now changed to "blocks".

The exact same problem exists with text/t140. If you do not get the last
transmitted UDP packet, you will not know until you get the next one. The
end result is precisely the same, regardless of text/T140 or audio/t140.
That is similar to
the case for other conversational media. You cannot be sure you heard the
last word, seen the last move or read the last character that the other end
expressed.

> 9. Section 3.6, "Note, also, that incoming text from a PSTN circuit
> might be at a higher bit-rate than can be played out on an egress PSTN
> circuit." The scenario and what is meant in this sentence is not clear.

We do not want to extend the discussion here of characteristics of the old
PSTN
textphone types, their different speeds, and what can be done in the transit
gateway application. We find it more appropriate to describe the
transmission
format here and discuss application in depth in the specifications of
gateway
applications that the audio/t140 format is intended for.

> 10. Section 3.7; "For profiles that use dynamic payload type number
> assignment, this payload format is identified by the name "T140" (see
> section 8). If redundancy is used per RFC 2198, the Payload Type MUST
> indicate that payload format ("RED")." I think that one should be
> clearer. We are using MIME type according to the definition in chapter
> 8, and also RED has its MIME type that can be used to identify the name.
> Therefore I would reformulate the sentences to: "For profiles that use
> dynamic payload type number assignment, this payload format can be
> identified by the MIME types "text/T140" and "audio/T140" (see section
> 8). If redundancy is used per RFC 2198, another payload type number
> needs to be provided for the redundancy format. MIME types for
> identifying RFC 2198 are available in RFC 3555 and RFC YYYY." Where RFC
> YYYY is the RFC number for the text/RED registration.

Done.

> 11. Section 3.7, The RTP sequence number: redefining the RTP sequence
> number through normative text is not good. Please provide a reference to
> RFC 3550 and then you can have the informative text.

Done.

> 12. Section 3.7: "Timestamp: The RTP Timestamp encodes the approximate
> instance of entry of the primary text in the packet. A clock frequency
> of 1000
>      Hz MUST be used for text/t140.  The clock frequency may be
> specified for audio/t140 and is generally set to be 8000 Hz, as that is
> most common for audio."
>
> In the last sentence above, it says: The clock frequency may be ... This
> is unclear, it needs normative language, making it clear that the rate
> MAY be set to any value, if not specified by out of band mechanism a RTP
> TS rate value of 8000 SHALL be used.

Changed to
"For audio/T140, the clock frequency
     MAY be set to any value. If not specified by out of band mechanism,
     the frequency value is generally set to be 8000 Hz, as that is most
     common for audio."

> 12.5. Section 3.7, why is the marker bit not defined?

The marker bit is not used.

> 13. Section 3.8: What is the following text doing in this chapter?
>   "When redundant transmission of the data according to RFC 2198 is
>    desired, the RTP header is followed by one or more redundant data
>    block headers, one for each redundant data block to be included.
>    Each of these headers provides the timestamp offset and length of the
>    corresponding data block plus a payload type number indicating this
>    payload format ("T140").  Redundant data older than 16383 divided by
>    the clock frequency MUST not be transmitted."
>
> It would seem to belong in section describing the usage of RED. I think
> there are more things in regards to usage of RED, like section 3.9,
> that can be collected in a separate chapter clarifying that it concerns
> the usage of RED for t140.

Using RED or other ways to incrrease reliability has influence over many
sections. It
touches the user needs of reliability, the packetisation, the procedures to
discover and
recover loss, the marking of unrecoverable loss, the SDP parameters, and the
MIME registrations.
We find it more natural to cover these aspects in one chapter each and
within these chapters cover the
transmission variants.

> 14. Section 4.1 "A maximum buffering time of 500 ms is specified." Where
> is it specified?

The buffering time is specified in T.140. The reference was quite confusing
as you noticed, it is changed.

> 15. Section 5: Another comment from the WG meeting in Minneapolis, was
> the need to make it clear that although the MIME parameter CPS  the
> instantaneous reception rate might be higher due to jitter.

Added.

> 16. Section 8.1, as text/t140 in RFC 2793 does not have rate, and it is
> not need (due to fixed rate), I would remove it. The mapping to SDP
> chapter can simply explain that one simply puts in the rate.

Still, the rate is a required parameter in the MIME registration. Therefore,
it is not removed.
It is also best to maintain it for backwards compatibility with RFC2793
implementations.

> 17. There should also be an interoperability consideration regarding CPS
> parameter.

The action required is described in the text. Further implications if the
parameter is not obeyed,
belongs more to descriptions in gateway specifications where the audio/t140
format is applied.

-----------Answers on comments by Gregg
Vanderheiden--------------------------------------------

>I think we should move to amend RFC2793bis to INCLUDE the redundancy as a
>central part of the standard.  (a MUST).

>Can you think of why you would use RFC2793bis without redundancy?     Will
>it be used for anything besides text over VoIP?

>I am particularly concerned that in an emergency, an otherwise QOS
>environment could become congested quickly and RFC2793 would fail except if
>it had redundancy required.   And if it will be required, then why not add
>it to the base definition.

Gregg wanted that the use of text/t140 with 300 ms between transmissions and
one original and 3 redundant generations
of text transmitted, would be pronounced as mandatory to ensure sufficient
text reliability in
congested and catastrophy situations.

We have a very clear sharpening from the current RFC2793, by RECOMMENDING
these parameters.
We do not want to limit the application by mandating these parameters, and
believe that we can rely on implementers to be wise enough to follow the
RECOMMENDED values when there are no reasons to do otherwise.

-----------Answers on Frank Shear´´s
comments-------------------------------------------------------
>I noticed that the RFC 2793bis draft never speaks of byte ordering. Is it
>assumed, since this is usually used in the context of RTP, that the byte
>order of the T140block counter is the byte order defined in RTP, i.e.,
>network order?

>Wouldn't it be slightly better to specifically mention the byte order in
the
>draft, just to avoid any potential confusion?

The following text is inserted:
a 16-bit "t140block counter" (with the most
   significant bit transmitted first)

>A very minor mistake: in section 5, "from section 14 or RFC 3550 apply"
>should be "from section 14 of RFC 3550 apply".

Woops, we missed that one. ( it is now in section 7 ). Hope it can be left
for final edits.

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rfc2793bis-01.txt