Re: [rtcweb] No Plan - but what's the proposal
Emil Ivov <emcho@jitsi.org> Thu, 06 June 2013 09:17 UTC
Return-Path: <emil@sip-communicator.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665AA21F8895 for <rtcweb@ietfa.amsl.com>; Thu, 6 Jun 2013 02:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001]
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 fKn5cKHdqSM1 for <rtcweb@ietfa.amsl.com>; Thu, 6 Jun 2013 02:17:02 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 65E8921F8756 for <rtcweb@ietf.org>; Thu, 6 Jun 2013 02:17:02 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hn14so131657wib.13 for <rtcweb@ietf.org>; Thu, 06 Jun 2013 02:17:01 -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=xmwzzedlA1o8szXj/DankyJsfZNmrKs2m/uue6QSmr8=; b=jebGSfiEGroxJsfMjWxZm6LASd8KUhkLB8I5wAAecMZe2qqY8A54HHsSUMIKhoVB6/ hJbAw5afMEXGzZd/As3vSmELm2fEZDsRpjOBTStVXJxzxSxUG963dOwUmVLBAt5qO5Ov p3j5zW62kVNMLnsw/Ls8pPl7+5wYsZuPSH0KqzTHT5gXR5gwmUmoOkw65FmmRfcdIAsr FZothoWpc43uIWCSnBRWWrTc9Nv9P81/Kgd+4XSzV5ALWW1UjwZiAk+INNosqIpqjAJy LSJJp5GFkOesUCfw08z7LlU2lwe2XwDikGBlrfZBJ7PeUX4U/ub03Vov2FtCBcTNoqxZ SqsA==
X-Received: by 10.194.83.5 with SMTP id m5mr31609064wjy.20.1370510221424; Thu, 06 Jun 2013 02:17:01 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:2995:1866:e2bc:6206]) by mx.google.com with ESMTPSA id e5sm14399140wiy.5.2013.06.06.02.16.59 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 02:17:00 -0700 (PDT)
Message-ID: <51B0538A.5040800@jitsi.org>
Date: Thu, 06 Jun 2013 11:16:58 +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: Cullen Jennings <fluffy@iii.ca>
References: <51A65017.4090502@jitsi.org> <C3639EB3-0F44-4893-88DA-BB9F9C96A116@iii.ca> <51A8EB7F.6000506@jitsi.org> <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> <51ACF998.5030202@jitsi.org> <CALiegf=pJtdL2A6V7bprZ_F=V39Fadb+kRw3yfO+6+MFVZ9x2A@mail.gmail.com> <5ED2CC48-1514-4C00-AEE8-A334EB67A6F4@iii.ca> <51AF5784.3060307@jitsi.org> <13444A29-86C6-4D69-964D-AE9A5BA7BB4A@iii.ca>
In-Reply-To: <13444A29-86C6-4D69-964D-AE9A5BA7BB4A@iii.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmhNF4VPR+nsm+BrE46H7gzzEWpHKCb6sHxTmLaw4KP+sXKy8zTseZa18bFqLRfNHOkubeh
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] No Plan - but what's the proposal
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 09:17:04 -0000
Hey Cullen, On 06.06.13, 07:41, Cullen Jennings wrote: > > I've trying to help you explain and I keep asking for an example but > I don't think we have had a complete example yet. I know you think > there is a complete example so let me try and be more specific so > perhaps we can get to the bottom of the disconnect. > > Let me try to be specific. > > Say an application running on Alice's browser want to generate an > offer that says the browser is ready to send and receive 2 streams of > video and 1 stream of audio look like? Imagine that one of the video > streams is a document camera running at high res but low frame rate > while the other is video of the speaker running at a higher frame > rate. What exactly does the SDP passed from the browser to the JS > applications look like. It looks exactly like the one I posted here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07724.html For convenience: v=0 o=- 20518 0 IN IP4 198.51.100.1 s= t=0 0 c=IN IP4 203.0.113.1 a=ice-ufrag:F7gI a=ice-pwd:x9cml/YzichV2+XlhiMu8g a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 a=group:BUNDLE m0 m1 m=audio 56600 RTP/SAVPF 96 0 a=mid:m0 a=rtpmap:96 opus/48000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=sendrecv a=rtcp-mux [ICE candidates] m=video 56602 RTP/SAVPF 97 98 a=mid:m1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 a=rtpmap:98 VP8/90000 a=sendrecv a=rtcp-mux [ICE candidates] There is no information about the specific streams because such information isn't necessary for a remote WebRTC browser or a generic UA. They will both just decode incoming streams and at that point resolutions and frame rates will become clear. If for some application specific reasons the remote party does need to know in advance what resolutions and frame rates each individual stream will have this will go in application-specific signalling. Such signalling may very well accompany the above SDP. An SDP gateway or a JS app may even choose to merge them both together, but this is out of scope. > I agree the applications can do whatever it > wants to communicate the relevant data to the far end so I don't care > about the signaling protocol or JSON that JS app can send across > the wire. But next question, can the far end start sending media > immediately to the browser? Of course! Why wouldn't it be able to? > Finally the far end does something that > causes the applications to generate an SDP answer from the JS > applications to Alice's browser. I want and example of that that > looks like in the cases where the far end a) accepted all the video > streams and b) rejected some but not all of the video streams. Both cases look the same way and they both look pretty much like the offer (except for the transport negotiation). This was explained here: http://www.ietf.org/mail-archive/web/mmusic/current/msg11354.html for convenience: v=0 o=- 20518 0 IN IP4 198.51.100.2 s= t=0 0 c=IN IP4 203.0.113.1 a=ice-ufrag:F7gI a=ice-pwd:x9cml/YzichV2+XlhiMu8g a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 a=group:BUNDLE m0 m1 m=audio 5000 RTP/SAVPF 96 0 a=mid:m0 a=rtpmap:96 opus/48000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=sendrecv a=rtcp-mux [ICE candidates] m=video 5002 RTP/SAVPF 97 98 a=mid:m1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 a=rtpmap:98 VP8/90000 a=sendrecv a=rtcp-mux [ICE candidates] As pointed out in the link above, the difference between a), and b) is going to be in application specific signalling that will turn off some specific SSRCs. That signalling can also accompany the SDP. > If we can get an simple example like this sorted out, then perhaps it > will be easy to extrapolate to the ones in the say the use case > document and start looking at things like number of round trips and > audio clipping. Looking forward to that. I am especially interested as to why you think there could be any audio clipping or other negative effects with this. Keep in mind that you can get exactly the same information to the remote end as with Plans A and B, the only difference is what part of that is in the SDP O/A generated by the browser. The advantage of No Plan is that it does not mandate for such information to be in SDP which lightens the signalling load in a number of cases. Cheers, Emil P.S. I am confused as to where this discussion should be happening. There have been contradictory comments from chairs that seem to say how this should be in MMUSIC and how it actually doesn't belong to MMUSIC and should happen on RTCWEB. I'd be grateful if chairs of both WGs could sort this out and provide guidance. > Cullen > > > PS - my apologies but a bunch of the time I have to work on this ends > up on planes so there is some time warp sometimes from what data I > had to read on the list vs what is on the list by the time my emails > arrive. I also tend to try and process email sent to me before > dealing with all list email which I tend to deal with in batches. So > I'm sending this without having read the all the list traffic. > > > On Jun 5, 2013, at 10:21 PM, Emil Ivov <emcho@jitsi.org> wrote: > >> >> >> On 05.06.13, 02:40, Cullen Jennings wrote: >>> >>> >>> On Jun 4, 2013, at 4:07 AM, Iñaki Baz Castillo <ibc@aliax.net> >>> wrote: >>> >>>> 2013/6/3 Emil Ivov <emcho@jitsi.org>: >>>>>>> We create an offer that would describe the media types >>>>>>> and the bundle. We use that offer to also describe >>>>>>> capabilities in terms of maximum resolutions, supported >>>>>>> header extensions, potentially max-ssrc-s, etc. >>>>>>> >>>>>>> It is up to the application how to handle the rest. If >>>>>>> it needs to transmit additional signalling: let it. If it >>>>>>> wants to encode that in SDP, great. If it wants to attach >>>>>>> it in JSON next to the browser generated SDP, that also >>>>>>> works. >>>>>> >>>>>> >>>>>> Great - I have super news for you. The WG agree to do that >>>>>> a year or more ago. >>>>> >>>>> >>>>> So I've heard indeed. >>>>> >>>>> Unfortunately however, it seems that we might have forgotten >>>>> this decision. We are now trying hard to come up with a >>>>> signalling mechanism that will do everything with >>>>> Offer/Answer. >>>> >>>> >>>> I think there is a misunderstanding here. I understand from >>>> Emil's mail that media re-negotation or streams addition after >>>> the first SDP O/A is not carried as a new full SDP O/A. Am I >>>> right? >>>> >>>> >>> >>> >>> I'm just trying to understand what the "No Plan" proposal is. I >>> have not even started to think about what parts of if I like. So >>> far, the more we talk about this, the more confused I get. I >>> think some simple examples that showed what O/A got passed across >>> the API from the JS into the browser for applications with >>> multiple video steams would really help. >> >> Then, in case you've missed any of these: >> >> You asked how Plan A endpoints would work with No Plan browsers >> here: >> >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07696.html >> >> The reply, with sample SDP went here: >> >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07724.html >> >> You then moved the thread to MMUSIC and asked to see the answer >> here: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11347.html >> >> In the above you also asked how the answerer could refuse one video >> stream. I replied with the SDP answer and additional sample >> signalling here: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11354.html >> >> I don't think I've seen any additional questions from you since >> then.You are now saying that the situation is still unclear, so >> please let me know if I can help in any way. Otherwise we could >> also switch to whatever problems you have with the approach >> itself. >> >> In the mean time, again on MMUSIC, Eric has asked for more detailed >> examples including sample JS code here: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11360.html >> >> Enrico has put up a very helpful and very complete example to this >> here: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11382.html >> >> I added a nit here: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11386.html >> >> Cheers, Emil >> >> -- https://jitsi.org >> > > -- https://jitsi.org
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Richard Barnes
- Re: [rtcweb] No Plan Cullen Jennings
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Martin Thomson
- [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Mary Barnes
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan - PT based MUX Cullen Jennings
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- Re: [rtcweb] No Plan Mark Rejhon
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- [rtcweb] RTT (was Re: No Plan) Matthew Kaufman
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Matthew Kaufman
- Re: [rtcweb] RTT (was Re: No Plan) Paul Kyzivat
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was Re: No Plan) Gunnar Hellstrom
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Barry Dingle
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- [rtcweb] Translating Plan A into No Plan (Was: No… Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Eric Rescorla
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] Translating Plan A into No Plan (Was… Martin Thomson
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] RTT (was :No Plan ) Paul Kyzivat
- Re: [rtcweb] No Plan - but what's the proposal Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Jonathan Lennox
- Re: [rtcweb] No Plan Jim Barnett
- Re: [rtcweb] Translating Plan A into No Plan (Was… Roni Even
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- [rtcweb] Repair Flows and No Plan (Was: No Plan) Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was :No Plan ) BeckW
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] Repair Flows and No Plan (Was: No Pl… Sergio Garcia Murillo
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Silvia Pfeiffer
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- [rtcweb] Plan xyz discussions; MMUSIC <> RTCweb R… Flemming Andreasen
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Peter Thatcher