Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

Jason,

(I removed the cross posting)

I started a thread in mmusic about "bundle splitting". It is predicated 
on the assumption that the offerer may propose to bundle some m-lines 
that the answerer can't handle if bundled together. But it could handle 
some smaller bundles of the same m-lines. With "Plan A" that should be 
enough to solve the problem.

With the Plan B described here, there is a variant of that. The offerer 
may offer an m-line with several SSRCs. The answerer wants those 
"flows", but may not be able to handle them in the same m-line. (It 
needs to receive them at different addresses, corresponding to separate 
hardware.)

In my earlier posting, I proposed that a subset of the bundled m-lines 
that can be received at a single address be accepted, and the others 
refused in the answer. And that then there be a new offer in the reverse 
direction, accepting those same m-lines, but bundling them separately. 
The assumption here is that they will still be identified as being 
associated with the same flows.

Would something analogous work with Plan B as you see it? The initial 
answerer would need to refuse SSRCs. Then it would need to send a new 
offer, with a separate m-line, and include something indicating the 
flows it wanted there. It could use the same MSIDs, but it can't 
necessarily use a=ssrc with the original SSRCs, because the new m-line 
is a separate SSRC space.

This may work, but the details elude me.

I also have a concern about use of ssrc-group for multicast. That only 
works if the all the members of the multicast group share the same 
m-line (or at least the same bundle.) That may not always be the case. 
When it does't, we need a more generalized grouping, that can reference 
specific SSRCs in different m-lines.

	Thanks,
	Paul

> ---------- Forwarded message ----------
> From: Justin Uberti <juberti@google.com>
> Date: Fri, May 3, 2013 at 1:08 AM
> Subject: [rtcweb] Fwd: New Version Notification for
> draft-uberti-rtcweb-plan-00.txt
> To: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
>
>
> Scribbled down the basic concepts of what I have been referring to as
> "Plan B" - a way to signal multiple MediaStreamTracks in SDP without
> needing a separate m= line for each.
>
> Hopefully this will make discussion of this topic easier.
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Thu, May 2, 2013 at 10:46 PM
> Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
> To: Justin Uberti <justin@uberti.name>
>
>
>
> A new version of I-D, draft-uberti-rtcweb-plan-00.txt
> has been successfully submitted by Justin Uberti and posted to the
> IETF repository.
>
> Filename:        draft-uberti-rtcweb-plan
> Revision:        00
> Title:           Plan B: a proposal for signaling multiple media
> sources in WebRTC.
> Creation date:   2013-05-03
> Group:           Individual Submission
> Number of pages: 15
> URL:
> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
> Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00
>
>
> Abstract:
>     This document explains how multiple media sources can be signaled in
>     WebRTC using SDP, in a fashion that avoids many common problems and
>     provides a simple control surface to the receiver.
>
>
>
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>