Subject: [AVT] draft-ietf-avt-rfc2793bis-02 RTP packetisation for text conversation published

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 19 Feb 2004 10:10:23 +0100

A new internet draft: draft-ietf-avt-rfc2793bis-02 has been published. It is
intended for real time chatracter by character text transmission in RTP.

Below the announcement copied here, there is a list of comments and
responses on the -01 version.

The new draft will be reviewed in the avt meeting in IETF 59, with the
intention that this work shall rapidly approach the last call state.

A couple of other activities in the interactive text conversation area will
be briefly covered in the same session to complete the picture of maturing
support for real time text over IP connections, including, but not only
covering SIP calls.

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

	Title		: RTP Payload for Text Conversation
	Author(s)	: G. Hellstrom, P. Jones
	Filename	: draft-ietf-avt-rfc2793bis-02.txt
	Pages		: 20
	Date		: 2004-2-18

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-02.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-02.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-02.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.

-------------Comments on the -01 version ( mainly from Magnus Westerlund)
and answers ---------------------
1. Abstract: You need to remove the [1] reference.
<GH<Done

2. Section 1: There is a MUST in the introduction. It should be changed
to lower case must of two reasons. First, this document does not define
that T.140 elements use ISO 10646-1. Secondly, having normative language
in an introduction is not appropriate.
<GH<Done

3. Section 3.2: Last sentence of second paragraph. "This T140block
counter may be
   utilized to detect lost blocks." I would propose to change this to:
"This T140block counter is intended to be
   utilized to detect lost blocks and avoid duplication of blocks."
<GH<Done

4. section 3.3, last sentence: Is this SHOULD correct? Why does the
paragraph implies that CCS SHOULD be place in one block, why not MAY or
SHALL?
<GH<No, SHOULD is suitable here. Nothing drastic happens if part of a CCS is
lost, and it depends a lot on the structure of the transmitter if it is
feasible to expect transmission of CCS in one block.

5. The robustness features of the draft. As I have privately commented I
would prefer to see the robustness features be collected into a single
chapter. I think by moving sections: 3.4, 3.5,  3.8, 3.9, and 4.4 into a
new chapter, between 4 and 5 the draft can be made more understandable.
<GH<I think the other way, it is good to have all code examples in one
chapter, and to get the information about robustness while you are reading
about the block basics. - No action.

6. Section 3.6: I think one should be more explicit about the fact that
the rendering of (reasonably) late blocks is recommend and very beneficial.
<GH<Done

7. Section 3.6: End of last paragraph: I think I understand the
motivation behind the recommendation that voice is discarded rather then
the T.140 when going from IP to PSTN at a gateway. However I think one
should reflect somewhat on the effects on the audio also.
<GH<Done

8. Section 3.7: Timestamp. "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."
I think the "generally set to be 8000 Hz" is not good enough. There
needs to be strict rules on what to do, otherwise you are in trouble. I
think that if not out-of-band signalling, where the interleaved audio
can be matched in rate, a fixed rate shall be set.

I am also missing the sentence saying: "When using this payload format
interleaved with an audio codec, the rate SHOULD be chosen to be the
same as the audio codec(s) to avoid RTP timestamp rate switching."
<GH<Done

9. Section 3.7: Missing marker bit definition. Even if not used it MUST
be defined as being not used and set to 0.
<GH<Done

10. Section 3.8: I think there are no reason to have a section called
"additional headers" and then simply having it state, no headers exist.
It is mostly about redundancy anyway, please rename.
<GH<Sorry, missed that, no action yet.

11. section 3.9, second paragraph. This paragraph is very hard to
interpret. First it talks about audio/t140, then about text/t140, and
when you come to the rules you are rather confused about for what it
applies. Please try to improve the paragraph through restructuring.
<GH<Simplified

12. In regards to the robustness options. As we now have available
mechanism to report packet losses, RFC 3611, but probably more important
draft-ietf-avt-rtcp-feedback and its NACK format, there is now
possibilities to do reactive repairs. I think the possibility should at
least be mentioned, or if it doesn't work, that should be motivated.
Please investigate this.
<GH<Done

13. Section 5, Second paragraph: "To control the character transmission
rate, the "fmtp" attribute [7]
   is used with the following syntax:"
I think this sentence should be changed to explain that; first CPS is a
MIME parameter, secondly that this is how it is mapped according to
section x to SDP.
<GH<Done.

14. Section 6.3: The RED SDP examples. Why does one have a=fmtp lines
like this? To my understanding of the pt list it should only contain a
single 98. This is either a bug here, or problem in the text/red document.
<GH<This is how RFC2198 is specified in SDP

15. Section 7: I think the security section can be improved:
- Separate the three main issues, confidentiality, integrity, and source
authentication. They are different, and have different severity and
attacks, and different counters.
- The section should give recommendations to mechanism that allows one
to counter these problems. For the two first SRTP works very well. For
the last it provides some properties that can be used to accomplish
that, combined with the signalling.
So please expand this.
<GH<Done

16. Section 8: Should be titled "IANA Consideration". And the
introduction to the chapter should request that the two mime types are
registered.
<GH<Done

17. Section 8.1, and 8.2: The registration should mention "This type is
only defined for transfer via RTP."
<GH<Done

18. Section 8.1, and 8.2: Security consideration: Please point at
section 7 of RFC XXXX.
<GH<Done

19. Section 8.2: The rate parameter for audio should contain the rule
that it SHOULD be matched with interleaved audio codecs.
<GH<Done

20. Section 11: Are really all references normative. I would expect that
5, 6, and 8 are informative. I have however not looked closely at it.
<GH<They look normative.

21. As it seems there will be some more RFC editors notes, they may be
moved into a separate RFC-editor section instead of being spread through
the document.
<GH<done.

22. <GH<The explanation on the applicability of the two formats text/t140 vs
audio/t140 were requested to be refined to more clear show the difference
and application area. Sections 3.1 and 3.2 have been amended. Comments
already received on the new wording in section 3.2 in version -02 indicate
that there is a need for further adjustment to give a balanced view of the
application area of the audio/t140 format for IP transit of text between
PSTN equipment.
-------------------------------------------------------------

Best regards
Gunnar Hellström
-------------------------------------------
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]
--------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 28 Feb 2004 07:31:06 +0100

Thanks Frank for good observations.

The two typos are obvious, thanks for spotting them.

The broken sentence in section 3.7 will be corrected during the IETF meeting
next week.

Regards

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Frank Shearar
Sent: Thursday, February 19, 2004 4:58 PM
To: [email-masked]
Subject: RE: [AVT] draft-ietf-avt-rfc2793bis-02 RTP packetisation for
text conversation published

Hi Gunnar,

The new draft has a sentence that I don't understand. You'll find it
at the end of section 3.7:

"If multiple timestamp rates are used by the audio payload types, it
is RECOMMENDED that different payload types for audio/t140 at all user
rates.."

What does it mean?

And two typos:

End of section 5, line 522 - "termporary" -> "temporary"

End of section 7.1, line 804 - "[9]rovides" -> "[9] provides"

Thanks,

frank

-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/toip_archive/maillist.html