Re: [rtcweb] No Plan - but what's the proposal

[Emil Ivov <[e-mail]>]

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 <[e-mail]> wrote:
>
>>
>>
>> On 05.06.13, 02:40, Cullen Jennings wrote:
>>>
>>>
>>> On Jun 4, 2013, at 4:07 AM, Iñaki Baz Castillo <[e-mail]>
>>> wrote:
>>>
>>>> 2013/6/3 Emil Ivov <[e-mail]>:
>>>>>>> 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