Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-framing-contrans-06.txt

From: [email-masked]
Date: Tue, 06 Sep 2005 18:50:02 -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		: Framing RTP and RTCP Packets over Connection-Oriented Transport
	Author(s)	: J. Lazzaro
	Filename	: draft-ietf-avt-rtp-framing-contrans-06.txt
	Pages		: 11
	Date		: 2005-9-6
	
This memo defines a method for framing Real Time Protocol (RTP) and
     Real Time Control Protocol (RTCP) packets onto connection-oriented
     transport (such as TCP).  The memo also defines how session
     descriptions may specify RTP streams that use the framing method.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-framing-contrans-06.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-framing-contrans-06.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.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Tue, 6 Sep 2005 19:37:30 -0700

> Filename     : draft-ietf-avt-rtp-framing-contrans-06.txt

I'm curious if a framing scheme similar to RTSP's binary data
encapsulation was considered. It adds 2 bytes of overhead per frame,
but I would guess frame sizes would typically be much larger when
going over a connection-oriented protocol (for example, I use 16 KB
frames when going over TCP as opposed to 1400 or so byte frames over
UDP), making the amortized cost relatively small.

The main problem I see is that the proposed framing format precludes
the use of a single stream from transporting both RTP and RTCP since
there is no type marker. For example, with RTSP, I can use a single
stream with a channel ID of 0 for RTP and channel ID of 1 for RTCP.

A message start marker (e.g. '$' in RTSP) also helps to re-sync the
stream if a transient error caused one side to lose track of where it
was within the stream (without having to tear down and re-establish
the connection to re-sync). This is relatively common over serial-ish
connections, but may also occur with other partial reliability
streams. A one byte start marker isn't a very reliable synchronization
marker, but combined with the expected channel ID range, and length
and RTP/RTCP validation, it provides a reasonable means for
re-syncing.

Another minor issue is that, depending on how the particular transport
protocol or its API works, alignment issues may be more complicated
because the RTP packet within the frame may be misaligned due to the
16-bit length followed immediately by the RTP packet data. For
example, if the transport protocol API returns a whole message (e.g.
SCTP is message-oriented rather than stream oriented like TCP), the
RTP packet data may be offset by 16 bits. Adding the 8 bit marker and
8 bit channel ID, avoids this alignment issue, in addition to the
other benefits offered by the additional fields.

For example, a frame format such as the following (like RTSP), might
be worth considering:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      '$'      |  channel ID   |            LENGTH             |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                                                               |
|                      RTP or RTCP packet ...                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Channel ID of 0 = RTP
Channel ID of 1 = RTCP
Other channel ID's reserved for future use.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 7 Sep 2005 09:29:05 +0100

> UDP), making the amortized cost relatively small.

The aim of this draft was to document the format defined in RFC 1889  
but removed from RFC 3550 due to lack of implementation reports at  
that time. It doesn't preclude other framing schemes, such as the  
RTSP encapsulation, if they're appropriate.

Colin