Subject: Re: [rtcweb] No Plan

From: Bernard Aboba <[email-masked]>
Date: Wed, 29 May 2013 13:30:33 -0700

I also like it quite a bit. In particular I think it is more compatible with simulcast and layered coding than Plan A or Plan B.

Mary Barnes <[email-masked]> wrote:

Personally, I really like this approach.  I think it will work well
for CLUE. You might also want to add a reference to XCON in section 4.
  The very reason we chartered XCON was because it seemed much more
sensible to include more complex conferencing operations in a separate
application layer protocol as opposed to overloading SIP/SDP O/A.

Mary.

On Wed, May 29, 2013 at 1:59 PM, Emil Ivov <[email-masked]> wrote:
> 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
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 29 May 2013 22:55:23 +0200

Hi,

I also think it is the best approach.

Best regards
Sergio

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 May 2013 17:00:41 -0400

Like Paul, I'll reserve a full judgement until I've had a little more time
to digest this.  At first read, though, it seems like there's a lot of
"magic happens here" in the draft.  There's an example of how you establish
a legacy-compatible stream, and an assertion that JS can do the rest.  The
truth of this assertion isn't obvious to me.  It would be helpful if the
document had an example of, say, how one might add a stream.

--Richard

On Wed, May 29, 2013 at 4:55 PM, Sergio Garcia Murillo <
[email-masked]> wrote:

>  I also like it quite a bit. In particular I think it is more compatible
>> with simulcast and layered coding than Plan A or Plan B.
>>
>>> http://tools.ietf.org/html/**draft-ivov-rtcweb-noplan<http://tools.ietf.org/html/draft-ivov-rtcweb-noplan>
>>>
>>> ______________________________**_________________
>>> rtcweb mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>
>> ______________________________**_________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>> ______________________________**_________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 May 2013 15:15:43 -0600

On 5/29/13 3:00 PM, Richard Barnes wrote:
> Like Paul, I'll reserve a full judgement until I've had a little more
> time to digest this.  At first read, though, it seems like there's a lot
> of "magic happens here" in the draft.

As Alan Lakein used to say: "Failing to plan is planning to fail."
Hopefully that's not true of the "No Plan Plan" for RTCWEB. :-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 May 2013 15:17:46 -0700

> Hopefully that's not true of the "No Plan Plan" for RTCWEB. :-)

I hope that what Emil intends is for these other things to be
addressed by expanding the WebRTC API in various ways to accommodate
the use cases we've identified.

There's an argument for not doing these things in SDP.  It's also
known as Comment 22.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 May 2013 16:47:54 -0600

> There's an argument for not doing these things in SDP.  It's also

Yes, agreed. I have yet to read Emil's proposal in depth, so my comment
was just a general observation and not feedback on the I-D.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 30 May 2013 11:03:34 +0200

On 5/29/13 11:00 PM, Richard Barnes wrote:
> of "magic happens here" in the draft.  There's an example of how you
> establish a legacy-compatible stream, and an assertion that JS can do
> the rest.  The truth of this assertion isn't obvious to me.  It would be
> helpful if the document had an example of, say, how one might add a stream.

This is how I'd do it, in a way that seems quite consistent with no-plan:

1. sender gets the additional local tracks

2. sender tells the receiver on the app-specific signalling channel
   (assuming a plain-english-over-something one): "I can also send you
   video and audio of a webcam I've just installed in the girls locker
   room. They'll have SSRC xxx and yyy" (xxx and yyy retrieved through
   JS API -- kind of what exists in Chrome today for stats)

3. receiver responds "Shoot!"

4. sender attaches the new tracks to the local stream attached to the
   existing connection

	4.1. if appropriate media lines exist (i.e. with the required
             media type and payloads), new media will be sent there,
             same ports, new SSRCs

	or

	4.2. if a new media line is required, the sender receives an
             event to be handled by an
             RTCSessionDescriptionCallback-like callback that triggers
             renegotiation in the usual app-specific way (AFAIK the API
             doesn't have such an event right now)

5. receiver gets addtrack notifications and the application will take
   care of their display, according to the app-specific information
   received on the app-specific signalling channel

The most critical part here is 4.2 (i.e. additional O/A exchanges, what
no-plan tries to reduce). It would probably never happen when the sender
is a browser, seldom otherwise.

I'm certainly not the greatest JS expert, but I don't see an easier way
to achieve this. I'm also not the greatest expert of legacy RTP devices
(although I deal with them every day), but I'm pretty convinced that for
such non-trival scenarios some kind of gatewaying will be required
anyway. The no-plan approach seems to make it easier than both plan A
and plan B.

Enrico

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 May 2013 11:14:02 -0400

> 3. receiver responds "Shoot!"

What does the receiver say if it can use the media, but cannot receive 
it over the *existing* audio and video m-lines where it is receiving 
other media already?

	Thanks,
	Paul

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 30 May 2013 17:53:32 +0200

> it over the *existing* audio and video m-lines where it is receiving 

I may have misinterpreted the draft, but it seems to me the whole point
here is about having WebRTC endpoints support multiple SSRCs on the same
m-line. If that's the case, an endpoint not supporting that would
qualify as "legacy". It would be behind a gateway anyway, and the
gateway function would be in the best position to translate both SDP and
media in a way it can digest.

Enrico

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 May 2013 12:53:52 -0400

> media in a way it can digest.

"legacy" and "decomposed" are not the same thing.

Presumably the design center for webrtc is a browser running on one 
system with a single display. And in that case everything to a single 
address makes sense.

But consider webrtc in the context of clue/telepresence. A browser be a 
very good basis for a controller for a telepresence room - providing the 
UI for managing a telepresence system. But that room will also have 
multiple displays. Each may have its own rendering hw.

Or, if that is too extreme for you, consider a simple PC running a 
browser and connecting to a telepresence room. The PC may be putting 
several video streams into windows, and be happy to get them on a single 
address/port. But the *other* end may be a sip-based clue system, 
decomposed, that can't group all of the streams into a single bundle. 
This is not a *legacy* case - we are still designing clue.

	Thanks,
	Paul