Subject: [clue] comments on draft-lennox-clue-rtp-usage-01

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 12 Nov 2011 02:54:32 -0800

Jonathan and Allyn, thanks for putting this draft together. I have a
couple comments/questions.

Section 3 reads, 

   "During call setup, a single RTP session is negotiated for each media
   type.  In SDP, only one media line is negotiated per media and
   multiple media streams are sent over the same UDP channel negotiated
   using the SDP media line."

Would it be more accurate to say a single RTP session is negotiated for
each media type within a capture set? For example, the framework draft
defines a "purpose" attribute, and I would envision one RTP session
being negotiated for main video and another for presentation video, as
defined in CLUE. Of course, you could multiplex these (and that argument
is being debated elsewhere), but I think the basic idea is multiple
streams of the media type and purpose be multiplexed in a single RTP
session. Reading further I see you touch on this in section 6.

Section 5.3, how do you see the combined approach working for audio when
you are sending multiple audio streams? I am not an audio expert, so
this is not a criticism, it is really a question. Would you send the
multiplex ID periodically, or a bunch of times whenever there is a
change in the information in hopes that at least one of the packets is
received properly?

Cheers,
Charles

---

From: "Paul Witty (pauwitty)" <[email-masked]>
Date: Mon, 14 Nov 2011 00:02:15 +0100

When it comes to RTP sessions, we find ourselves restricted by
requirements for compatibility with existing systems; it's much easier
to get one video media line, and one audio media line through a border
controller than it is to have a slides video media, a sign language
video media, a main video, and an audio line.  Even if an endpoint
offers multiple media lines, it should be willing to e.g. multiplex all
video streams, of whatever purpose, into a single video rtp session if
this is what the far end negotiates.

For audio, with the combined approach my suggestion would be to send the
multiplex ID for a short period after changing the stream sent within a
particular capture, e.g. for a second or so.  With typical 20ms packets,
this would be 50 packets, so the hope would be that at least one of
these would get through.

Of course, there will occasionally be the case where a receiver fails to
receive any of these packets containing in a multiplex ID.  In this
case, I'd suggest reusing the RFC5104 FIR message; for video, on
receiving an FIR, we will send an IDR, and each of packet within the IDR
will be tagged with the multiplex ID.  For audio, on receiving a FIR, we
can continue to send media as normal, but tag packets with the multiplex
ID for a short period of time.

-- 

Paul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles Eckel (eckelcu)
Sent: 12 November 2011 10:55
To: [email-masked]
Subject: [clue] comments on draft-lennox-clue-rtp-usage-01

Section 3 reads, 

Cheers,
Charles

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue