Subject: Re: [clue] Fwd: [rtcweb] No Plan

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Mon, 3 Jun 2013 18:53:27 +0000

>> That goes against the CLUE signaling proposals we've been discussing.

I think we should revisit the existing CLUE proposals to be more in line with the latest discussions in MMUSIC. At the time when we discussed this, it was not obvious which direction the MMUSIC group will take and we have learned a lot internally in the CLUE team as well. 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 30. mai 2013 09:23
To: Mary Barnes; CLUE
Subject: Re: [clue] Fwd: [rtcweb] No Plan

Hi Mary,

> As chair, I strongly encourage folks to review this proposal and 
> comment on the RTCWEB mailing list (while I personally think the discussion should be on the MMUSIC mailing list, it seems impossible to get RTCWEB folks to do that consistently).

I've managed to move the BUNDLE discussions to the MMUSIC list ;)

> Individually, I really like this approach of minimizing dependency and interactions with SDP O/A and leaving the more complex signaling to the applications (e.g., CLUE).

I have nothing against trying to minimize SDP O/A transactions. But, from a CLUE perspective please note the following statement in the draft:

	"For the sake of interoperability this specification strongly advises
   	against the use of multiple m= lines for a single media type."

That goes against the CLUE signaling proposals we've been discussing.

Regards,

Christer

---------- Forwarded message ----------
From: Emil Ivov <[email-masked]>
Date: Wed, May 29, 2013 at 1:59 PM
Subject: [rtcweb] No Plan
To: [email-masked]

Hey all,

Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less.

The following "no plan" draft attempts to present one such approach:

http://tools.ietf.org/html/draft-ivov-rtcweb-noplan

The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP.

Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways.

Comments are welcome!

Cheers,
Emil

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Jun 2013 11:44:22 -0400

> I think we should revisit the existing CLUE proposals to be more in line with the latest discussions in MMUSIC. At the time when we discussed this, it was not obvious which direction the MMUSIC gro…

We definitely will need to revisit to align with bundle.
But we still don't know where that will end up, so IMO its premature to 
do so. I'm certainly following that discussion closely.

In the meantime I think our decision to assume no bundling and a single 
encoding per m-line can allow us to proceed.

IMO the main impact on what we are doing is the proposal to put the 
entire description of encodings into SDP rather than in the 
advertisement. Depending on the outcome of the bundle discussions we may 
need to change that. But doing so shouldn't be that big a deal.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Jun 2013 16:20:21 +0000

Hi,

> But we still don't know where that will end up, so IMO its premature to do so. I'm certainly following that discussion closely.
>
> In the meantime I think our decision to assume no bundling and a single encoding per m-line can allow us to proceed.

I agree.

In addition, I haven't seen anything in our current assumptions that would prevent usage of BUNDLE, if someone wants to.

> IMO the main impact on what we are doing is the proposal to put the entire description of encodings into SDP rather than in the advertisement. Depending on the outcome of the bundle discussions we may need to change that. But doing so shouldn't be that big a deal.

Let's also keep in mind that RTCWEB is NOT defining what is sent on the wire. WHATEVER CLUE defines, it can be sent to a JS APP. The question is when whether the JS APP can "map" that into proper API language towards the browser.

Regards,

Christer