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=3D0
    o=3D- 20518 0 IN IP4 198.51.100.1
    s=3D
    t=3D0 0
    c=3DIN IP4 203.0.113.1
    a=3Dice-ufrag:F7gI
    a=3Dice-pwd:x9cml/YzichV2+XlhiMu8g
    a=3Dfingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7
    a=3Dgroup:BUNDLE m0 m1

    m=3Daudio 56600 RTP/SAVPF 96 0
    a=3Dmid:m0
    a=3Drtpmap:96 opus/48000
    a=3Drtpmap:0 PCMU/8000
    a=3Dptime:20
    a=3Dsendrecv
    a=3Drtcp-mux
    [ICE candidates]

    m=3Dvideo 56602 RTP/SAVPF 97 98
    a=3Dmid:m1
    a=3Drtpmap:97 H264/90000
    a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1
    a=3Drtpmap:98 VP8/90000
    a=3Dsendrecv
    a=3Drtcp-mux
    [ICE candidates]

There is no information about the specific streams because such=20
information isn't necessary for a remote WebRTC browser or a generic UA. =

They will both just decode incoming streams and at that point=20
resolutions and frame rates will become clear.

If for some application specific reasons the remote party does need to=20
know in advance what resolutions and frame rates each individual stream=20
will have this will go in application-specific signalling. Such=20
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=20
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=20
offer (except for the transport negotiation). This was explained here:

http://www.ietf.org/mail-archive/web/mmusic/current/msg11354.html

for convenience:

    v=3D0
    o=3D- 20518 0 IN IP4 198.51.100.2
    s=3D
    t=3D0 0
    c=3DIN IP4 203.0.113.1
    a=3Dice-ufrag:F7gI
    a=3Dice-pwd:x9cml/YzichV2+XlhiMu8g
    a=3Dfingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7
    a=3Dgroup:BUNDLE m0 m1

    m=3Daudio 5000 RTP/SAVPF 96 0
    a=3Dmid:m0
    a=3Drtpmap:96 opus/48000
    a=3Drtpmap:0 PCMU/8000
    a=3Dptime:20
    a=3Dsendrecv
    a=3Drtcp-mux
    [ICE candidates]

    m=3Dvideo 5002 RTP/SAVPF 97 98
    a=3Dmid:m1
    a=3Drtpmap:97 H264/90000
    a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1
    a=3Drtpmap:98 VP8/90000
    a=3Dsendrecv
    a=3Drtcp-mux
    [ICE candidates]

As pointed out in the link above, the difference between a), and b) is=20
going to be in application specific signalling that will turn off some=20
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=20
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=20
in the SDP O/A generated by the browser. The advantage of No Plan is=20
that it does not mandate for such information to be in SDP which=20
lightens the signalling load in a number of cases.

Cheers,
Emil

P.S. I am confused as to where this discussion should be happening.=20
There have been contradictory comments from chairs that seem to say how=20
this should be in MMUSIC and how it actually doesn't belong to MMUSIC=20
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=F1aki 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
>>
>
>

--=20
https://jitsi.org