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

From: Mary Barnes <[email-masked]>
Date: Wed, 29 May 2013 14:13:21 -0500

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).

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).

Mary.

---------- 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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 May 2013 07:22:35 +0000

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 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