[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] SF Issue Summary: draft-lazzaro-avt-rtp-framing-contrans-00.txt
Hi everyone,
This is the summary message for the Wednesday, 19th March AVT WG
presentation:
Framing RTP over Connection-Oriented Transport (Lazzaro) 15
draft-lazzaro-avt-rtp-framing-contrans-00.txt
I'm CC'ing this to MMUSIC, given the topical overlap of the I-D.
This summary is somewhat long, because I describe the decisions that
will move the document forward, so that WG members who won't be in San
Francisco can voice their views on the lists by responding to this
post. My presentation in San Francisco will put the 3 open issues
described below up on the screen, to see if at least within the room a
consensus can be found.
---
This I-D began with an extended discussion on the WG:
http://www1.ietf.org/mail-archive/working-groups/avt/current/msg01847.html
Three requirements arose from this discussion:
[1] A memo was needed to document the "classical" framing of RTP over
TCP, to facilitate interoperability with applications that use it
(several are mentioned in the linked WG thread).
[2] There was an MMUSIC I-D that defined SDP conventions for setting
up a TCP media session (draft-ietf-mmusic-sdp-comedia-04.txt, soon to
be draft-ietf-mmusic-sdp-comedia-05.txt), but comedia defines neither
the SDP fmt token to specify an RTP/AVP stream, nor the TCP framing
such a stream should use.
[3] RTSP has support for interleaving RTP and RTCP media streams into
the TCP stream used for RTSP control method traffic. However, although
RTSP also has the syntactic power to specify non-interleaved TCP session
in the SETUP method, there is (apparently) no semantics in common use
for this syntax.
Requirement [1] is simple to address: write a new I-D to document
classical RTP TCP framing. Sections 2-3 of
draft-lazzaro-avt-rtp-framing-contrans-00.txt attempt to do this.
#####> Open Issue #1
Does draft-lazzaro-avt-rtp-framing-contrans-00.txt accurately capture
classical TCP framing, as used in practice? In specific, are the
details in Section 3 correct?
----
The second requirement is more controversial. Given that we try to
avoid "there's more than one way to do it", it would be best if there
was one RTP/AVP TCP framing method for use with
draft-ietf-mmusic-sdp-comedia-05.txt. The discussion in the WG thread
linked above did not reach consensus, but instead ended with two
different options:
A. Define classical TCP framing as the framing method for RTP/AVP
to use with draft-ietf-mmusic-sdp-comedia-05.txt.
B. Write an AVT I-D that describes RTSP interleaved-mode
RTP/AVP framing, as run over a stand-alone TCP stream.
Define this framing method as the framing method to use
with draft-ietf-mmusic-sdp-comedia-05.txt.
Section 4 of draft-lazzaro-avt-rtp-framing-contrans-00.txt implements
"A". Two more open issues:
#####> Open Issue #2
Is A or B above the right path to take? Or, should we define SDP fmt
codes for both A and B?
----
and
#####> Open Issue #3
If A is the right option to take, are the SDP details in Section 4 of
the draft-lazzaro-avt-rtp-framing-contrans-00.txt acceptable to
everyone?
----
The final requirement involves RTSP support for non-interleaved TCP.
Section 5 of draft-lazzaro-avt-rtp-framing-contrans-00.txt defines
candidate RTSP semantics to use the classical TCP framing in RTSP.
However, recent discussions in the Rtspspec-bugs transcripts seem to
indicate that the editors of the core RTSP draft would prefer to
handle this issue as a part of the RTSP draft document. So, unless I
hear otherwise, I would think that deleting Section 5, and all
mentions of RTSP, from draft-lazzaro-avt-rtp-framing-contrans-00.txt,
is appropriate.
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt