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

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

Return-Path: <emil@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B82821F9A01 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 03:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_26=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqssAhdDuG1m for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 03:48:49 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3570E21F99ED for <mmusic@ietf.org>; Wed, 5 Jun 2013 03:48:48 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hj6so1138006wib.11 for <mmusic@ietf.org>; Wed, 05 Jun 2013 03:48:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ZJ6+v/4FAEeus9zRhfxfZo3Bh174CJ/uFMN0oh+XyXU=; b=Nhhxv03MtPwJxjgqnDfkiSfjw0i3pwRwu5OeRdCKqrkV/j+qzA0G2ZSuYo7KKSQkjC OUqbdOvvCn+QEOnVAFe92vVJPLJtT8Nq396jWCx/qFJf4t/kkUR1t+brXcymY8fL5x9M jMW/831IxDM+jKOYKlIm3e/LXL3Y1SxNeO3mqJLdTYZ3EfxTzgw74y3lDjqLN4xCMci1 r+HTlUlv2pMoZiQHHvu3YV8bprlZjKEbX05eCif+qu07PCIILJejl+meR/rO86HZuk4o kiNoYF/cX6VxtlW2mFSF9eMCqstj77Wy6rMY73Hhs4ZhudI6FGuCo1Bwi3Uu23k2h4rN pxCg==
X-Received: by 10.180.87.162 with SMTP id az2mr6069814wib.10.1370429327992; Wed, 05 Jun 2013 03:48:47 -0700 (PDT)
Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id cw8sm9470085wib.7.2013.06.05.03.48.46 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 03:48:47 -0700 (PDT)
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
X-Gm-Message-State: ALoCoQkISisE95jNE1RVp1fj5+R4TD3YfrqiRUZzTxNkdngNG2eB/ES5pxJZwkcEp+baKQw0cyOF
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)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 10:48:50 -0000

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