Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan)

Emil Ivov <emcho@jitsi.org> Wed, 05 June 2013 10:48 UTC

Message-ID: <51AF178D.2040406@jitsi.org>
Date: Wed, 05 Jun 2013 12:48:45 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Enrico Marocco <enrico.marocco@telecomitalia.it>
References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB113528171@xmb-aln-x02.cisco.com> <51A8EAB7.8080206@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB11352940B@xmb-aln-x02.cisco.com> <51ACD224.8080100@jitsi.org> <CABcZeBNp72QirKG1WPaX0HFjCFC+WRJ4Zh-H9L8zaVmmb4Yuog@mail.gmail.com> <51AD042E.2090302@jitsi.org> <CABcZeBPgs17NqjnVC06APSzUebWZpKtqisRJy8Op+Zp=Kn7jaw@mail.gmail.com> <51AD0AC2.2080001@jitsi.org> <CABcZeBNOyPpcsxFqtagcNvTEFaMBGdfDZuSJx7dJJnzXwTW7Ww@mail.gmail.com> <51ADA539.1020505@jitsi.org> <CABcZeBP1RSZC4cAtUEDFEkkE0bugW9EMgtWaQehX61qaL=2i3A@mail.gmail.com> <51AF00B7.8070402@telecomitalia.it>
In-Reply-To: <51AF00B7.8070402@telecomitalia.it>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan)
Precedence: list

On 05.06.13, 11:11, Enrico Marocco wrote:
> On 6/4/13 3:13 PM, Eric Rescorla wrote:
>> I would like to see a *complete* example with all the data flowing back
>> and forth
>> and the API calls (even if they are mocked up) that you think the sides will
>> make.
>
> Not trying to steal Emil's job,

Steal away! The JS API part of this is something that we haven't even 
started designing yet so any feedback is welcome.

> here's a rough example of how I (from a
> web developer PoV) would like to be allowed to do it. Required API
> extensions are in 5. and 8. (i.e. the .ssrc MST attributes).
>
> Regular PC setup (this already well known):
> http://goo.gl/cKfNf
>
> Stream add:
> http://goo.gl/ZNSdZ

This is indeed along the lines of what I also had in mind. Stefan 
already made a comment on rtcweb about how obtaining SSRCs directly from 
a stream doesn't really fit right now as a stream may be attached to 
many, one or no peer connections. So I suppose the actual API would have 
to take this into account and get the SSRC from some object that 
represents a relation between a track and a specific peer connection. 
Some sort of a PeerTrackDescriptor ... or something like that.

Looking at the example itself I see it ends at bob asking Alice to stop 
sending a specific SSRC. I believe Eric's questions were also about that 
part, so here are a couple of more lines at the side of Alice:

onSigna(action, ssrc)
{
   if(action == 'stopTrack')
     stopTrack(ssrc);
}

stopStream(ssrc)
{
    localTracks[ssrc].stop();
}

In the above localTracks is a locally maintained array/map of the tracks 
Alice is currently sending. Obviously you could also just loop a "for" 
over the tracks in your streams but since you didn't want to "grovel" ...

Of course there's work to be done on the APIs but on the whole, Eric, 
does this answer your question?

Emil

> Again, this is a *rough* example. The clear advantage (from my PoV of
> course) is that, once the peer connection is established, the app does
> not have to care about additional renegotiations, but in exceptional
> cases (i.e. the new stream needs a new PT): no need to handle O/As
> crossing on the wire, nor rollbacks.
>
> The clear drawback is that, as it is now, it looks awfully ugly: tracks
> are attached to the existing stream for transmission, but rendered on a
> new stream on the receiving side. This is because the focus was on
> minimizing the impact on the API. It could be probably improved with
> more substantial changes, e.g. for allowing the instantiation of the
> remote stream on the receiving side before the RTP packets actually
> start flowing. Kind of what plan B does, but without the additional,
> painful, O/A+O/A exchange.
>
> Enrico
>
>
>

-- 
https://jitsi.org

Re: [MMUSIC] [rtcweb] Translating Plan A into No … Cullen Jennings
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Emil Ivov
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Eric Rescorla
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Emil Ivov
Re: [MMUSIC] [rtcweb] No Plan Paul Kyzivat
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Emil Ivov
Re: [MMUSIC] [rtcweb] No Plan Emil Ivov
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Eric Rescorla
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Emil Ivov
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Christer Holmberg
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Eric Rescorla
Re: [MMUSIC] [rtcweb] No Plan Paul Kyzivat
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Paul Kyzivat
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Enrico Marocco
Re: [MMUSIC] [rtcweb] Translating Plan A into No … Emil Ivov
Re: [MMUSIC] [rtcweb] No Plan Emil Ivov
Re: [MMUSIC] [rtcweb] No Plan Paul Kyzivat
Re: [MMUSIC] [rtcweb] No Plan Emil Ivov