Subject: Re: [AVTCORE] Call for consensus on multiplexing multipe media streams.

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 15 Nov 2011 18:47:35 -0800

> So the WG chairs are asking which direction to take
> 
> 
> 
> The options we have are:
> 
> 
> 
> 1. Go forward with both solutions.
> 
> 2. Only define multiplexing of multiple RTP sessions in a single transport flow.
> 
> 3. Only define multiplexing of multiple media types in a single RTP session.
> 
> 4. Not enough information in order to decide, more discussion is needed.

My preference is (2) but I am also fine with (1) if that is the consensus. 

-acbegen

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 16 Nov 2011 10:52:26 +0800

> My preference is (2) but I am also fine with (1) if that is the consensus.

(Sorry about tagging on to this point in the thread, but I joined the 
list late)

I'm fine with either 2 or 3, but only because I think that 2 and 3 can 
look exactly the same on the wire and only differ in the semantics... 
and I don't really care which semantics we choose.

I'm not ok with a kind of 2 that isn't wire-equivalent to 3.

Matthew Kaufman

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 05:44:14 +0000

If what Matthew says is true, that 2 and 3 are on-the-wire equivalent, then I'm totally confused by the choices now.

Can the chairs please clarifies what the consensus call options mean?  

In particular, can you do so by indicating actual drafts, rather than using high-level terminology?

-hadriel

On Nov 15, 2011, at 9:52 PM, Matthew Kaufman wrote:

> (Sorry about tagging on to this point in the thread, but I joined the list late)
> 
> I'm fine with either 2 or 3, but only because I think that 2 and 3 can look exactly the same on the wire and only differ in the semantics... and I don't really care which semantics we choose.
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Roni Even" <[email-masked]>
Date: Wed, 16 Nov 2011 08:14:48 +0200

Hi Hadriel,
There is background information about the different multiplexing in
http://tools.ietf.org/html/draft-westerlund-avtcore-multiplex-architecture-0
0 
I would like to say that this is an individual draft does not reflect
consensus of the WG. Sections 3 till 6 provide the overview that may be
helpful for you.

As a WG chair I cannot comment on  sections 7-9 but they are relevant but
caused discussion.

The different proposals are in

http://tools.ietf.org/html/draft-westerlund-avtcore-transport-multiplexing-0
1 for option 2
 
and 

http://tools.ietf.org/id/draft-lennox-rtcweb-rtp-media-type-mux-00.txt for
option 3

All the documents were discussed in the AVTcore session.

Roni Even
AVT co-chair

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hadriel Kaplan
> Sent: Wednesday, November 16, 2011 7:44 AM
> To: [email-masked]
> Subject: Re: [AVTCORE] Call for consensus on multiplexing multipe media
> streams.
> 
> 
> If what Matthew says is true, that 2 and 3 are on-the-wire equivalent,
> then I'm totally confused by the choices now.
> 
> > I'm fine with either 2 or 3, but only because I think that 2 and 3
> can look exactly the same on the wire and only differ in the
> semantics... and I don't really care which semantics we choose.
> >
> > Audio/Video Transport Core Maintenance [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 06:42:11 +0000

OK, so that's how I had also interpreted the original consensus-call email options.
Thank you for the clarification.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 23:39:27 +0000

> I'm not ok with a kind of 2 that isn't wire-equivalent to 3.

I don't believe the two can technically be on-the-wire equivalent.  Even if you do #2 without a shim header, the nuances of being distinct multiple RTP sessions means:
1) With #2 each RTP session has its own RTCP, so there'll be separate RTCP packets on-the-wire for audio vs. video (for example); whereas #3 means there's one RTCP and thus there's one RTCP packet on-the-wire carrying multiple SSRCs.
2) With #2 each RTP session has its own SRTP key/context, and potentially you could even do SRTP for one media type and not the other at the same time; with #3 the SRTP fate is tied, since it's one RTP session.
3) With #2 one RTP session can use AVPF, such as the video one, while the other does not; with #3 I think they'd all be doing AVPF or all not.

-hadriel