Re: [rtcweb] No Plan - SDP offer/answer clarification

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 05 June 2013 12:45 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
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 173E921F9958 for <rtcweb@ietfa.amsl.com>; Wed, 5 Jun 2013 05:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.8
X-Spam-Level:
X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 7M6TxWnIfVzs for <rtcweb@ietfa.amsl.com>; Wed, 5 Jun 2013 05:45:50 -0700 (PDT)
Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id DBF2E21F9959 for <rtcweb@ietf.org>; Wed, 5 Jun 2013 05:45:49 -0700 (PDT)
Received: by mail-qa0-f41.google.com with SMTP id bn16so3259150qab.7 for <rtcweb@ietf.org>; Wed, 05 Jun 2013 05:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kcwfxEE91/XgVw23RoWYHPhoQ3m+1p4Cs6Mv9hHLy4g=; b=Du2eRv9yJwHZXSsCt4A2y6aOBWEMVVLGNt0PRyZ+Gx3tXFK0w3NT4iV8OxXwkTLV1r vPfdGdK/xDn3c+EwIJfAK0Zaa8WXKA499A9sLkVvt2pNtq150kWGgcXXP5K3/nVCWvpp GTKVmjPh5cNowecIfeC4HZ2b/ubap7f9GEsqsxzf7wJmxAddgncMfAqx3GvVRRShrS1D tEOnjk1dNQObbtrwG455mlL8OVNxL03d/FAihfUFcZGz7r8gbucYkZr3XGKHGG+2QdVK 0iRjklf0IfXohUWk79nEJoAkrZQZDGEj2PN+U4xEg4WlMve53YEz4sRPlyexf/XVv9V/ 4D6w==
MIME-Version: 1.0
X-Received: by 10.49.0.145 with SMTP id 17mr32176601qee.26.1370436348335; Wed, 05 Jun 2013 05:45:48 -0700 (PDT)
Received: by 10.49.30.2 with HTTP; Wed, 5 Jun 2013 05:45:48 -0700 (PDT)
In-Reply-To: <51AE5492.2090000@jitsi.org>
References: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com> <51AC73EE.5080603@jitsi.org> <026201ce60a6$6d406f20$47c14d60$@gmail.com> <51ADD8DD.1060409@jitsi.org> <02d601ce6143$0084cf50$018e6df0$@gmail.com> <51AE5492.2090000@jitsi.org>
Date: Wed, 5 Jun 2013 07:45:48 -0500
Message-ID: <CAHBDyN7-ExigqLV4_Ju10F33rzPrn6g3vRbc5=o6dxb+NeBFYg@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
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: Wed, 05 Jun 2013 12:45:51 -0000

On Tue, Jun 4, 2013 at 3:56 PM, Emil Ivov <emcho@jitsi.org> wrote:
> Hey Roni,
>
>
> On 04.06.13, 18:46, Roni Even wrote:
>>
>> Hi Emil,
>>
>> I get it what you call de-multiplexing is just selecting the right codec
>> but
>> not the decoding of individual streams which need to be handled by the
>> SSRC.
>> The SSRC is not needed only for mapping it to a different MediaStream it
>> is
>> needed also for decoding.
>
>
> Why is that? Do you have in mind something like the case that Cullen
> described, where two different screens, each with its own codec chain, would
> need to render two different SSRCs that both have PT 99, H.264 PM=1?
>
> If so then you'll simply need to tell this to the remote side with
> application-specific signalling.
>
>
>> Yet  for the decoding you do not need to know the
>> SSRC in advance
>
>
> Yes. I don't. Therefore, I don't want the browser to make me send it. If you
> need it however, then sure, just transmit it with your own
> application-specific signalling. In a CLUE channel for example.
>
>
>> and you suggest that the mapping between SSRC and
>> MediaStream will not be done in SDP under the assumption that current
>> systems will only support one audio and one video stream so multiple
>> stream
>> support is not required.
>
>
> See above.
>
>
>> The question will be what happens further down the road, I hope you are
>> not
>> saying that from now on the only systems will be based on WebRTC and there
>> will not be any new SIP systems that will work end to end with a SIP
>> application and support multiple streams.
>
>
> Oh believe me, I am very, very far from saying that. The reason I am
> insisting on No Plan is exactly because I work on such non-WebRTC systems
> and I don't want my life to be harder than it should be.
[MB] Indeed. This is exactly why I really like No Plan.  I think it
provides CLUE much more flexibility in doing things in an optimal way
for the CLUE application.  CLUE has not yet finalized their signaling
solution - giving CLUE the flexibility to signal some stuff in the
CLUE channel as needed (versus SDP) is a much better option long term
for CLUE.   I don't have a detailed plan - otherwise, I'd submit it to
CLUE as an individual although personally, I don't think chairs should
have strong positions in a WG as it makes it much more difficult for a
chair to negotiate consensus since it's clear there is a bias for a
specific solution.  And, for the record, my comments here are as an
individual and I am not representing CLUE as a WG (as Paul is not
either in his comments).  Certainly, as a chair I will go with the
consensus of the CLUE WG.  [/MB]
>
>
>> So there may be different ways to
>> convey such information that will be application profile dependent and
>> will
>> require gateways. I think that CLUE is taking a different approach to map
>> between the SSRC and the Media Captures using SDP and RTP/RTCP to provide
>> the mapping and not an application channel.  CLUE does not require to know
>> all SSRCs in advance, dynamic mapping from SSRC  to Media Captures
>> proposal
>> is to use RTP header extensions and RTCP SDES and not the CLUE channel to
>> carry the mapping from SSRC to the CaptureID.  So the SDP can have static
>> SSRC mapping when the SSRC are known. In both cases the assumption is that
>> the m-line include all the pt numbers that will be used during the call
>> even
>> for new streams that will be added later.
>
>
> OK, then I believe we are in complete agreement.
>
> Emil
>
>
>
>>> -----Original Message-----
>>> From: Emil Ivov [mailto:emcho@jitsi.org]
>>> Sent: 04 June, 2013 3:09 PM
>>> To: Roni Even
>>> Cc: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
>>>
>>> Hey Roni,
>>>
>>> On 04.06.13, 01:05, Roni Even wrote:
>>>>
>>>> Hi Emil,
>>>> My understanding is that you propose to de-multiplex by the pt number
>>>> so you cannot have two rtp streams with the same payload type number
>>>
>>>
>>> A PT number is only used to pick a codec/processing chain. Different
>>> SSRCs
>>> would then be used as an indication that packets belong to different RTP
>>> flows and that they have to end-up in different MediaStream-s and
>>> eventually <video> tags. This works with No Plan and it does not require
>>
>> that
>>>
>>> SSRCs be known in advance.
>>>
>>> Does this answer your question?
>>>
>>> Emil
>>>
>>>
>>>
>>>
>>>> Roni
>>>>
>>>>> -----Original Message-----
>>>>> From: Emil Ivov [mailto:emcho@jitsi.org]
>>>>> Sent: 03 June, 2013 1:46 PM
>>>>> To: Roni Even
>>>>> Cc: rtcweb@ietf.org
>>>>> Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
>>>>>
>>>>> Hey Roni,
>>>>>
>>>>> On 03.06.13, 13:29, Roni Even wrote:
>>>>>>
>>>>>> Hi,
>>>>>> I read the draft and the email thread and I think I have similar
>>>>>> questions to the ones Cullen made.
>>>>>> My understanding was that the proposal is to  do one SDP offer/
>>>>>> answer exchange  and add remove streams using other means (not
>>>>>> specified)
>>>>>
>>>>>
>>>>> Yes, this is exactly it.
>>>>>
>>>>>> I looked at the offer example is section 3 and it has
>>>>>>
>>>>>> a=max-send-ssrc:{*:1}                      // declaring maximum
>>>>>>       a=max-recv-ssrc:{*:4}                     // number of SSRCs
>>>>>>
>>>>>> I have some clarifying questions?
>>>>>>
>>>>>> 1. Is the proposal to always offer max-send-ssrc=1?
>>>>>>
>>>>>> 2. What is the answer in this case can it be max-send-ssrc=4?
>>>>>
>>>>>
>>>>> The max-ssrc in the SDP was just an example for capabilities that the
>>>>
>>>> offerer
>>>>>
>>>>> could add to SDP (could be useful for mobile devices for example). It
>>>>> is
>>>>
>>>> by no
>>>>>
>>>>> means essential to the approach.
>>>>>
>>>>>> 3. If max-send-ssrc >1 in the answer and the m-line has, for
>>>>>> example, support for H.264 and VP8 with max-send-ssrc=2  and
>>>>>> de-multiplexing is based on pt number, it will require four pt in
>>>>>> the m-line since there can be two
>>>>>> VP8 or two H.264 RTP streams
>>>>>>
>>>>>>       m=video 5002 RTP/SAVPF 97 98 99 100
>>>>>>       a=mid:video
>>>>>>       a=rtcp-mux
>>>>>>       a=rtpmap:97 VP8/90000
>>>>>>       a=rtpmap:98 VP8/90000
>>>>>>       a=rtpmap:99 H264/90000
>>>>>>       a=rtpmap:100 H264/90000
>>>>>> Is my understanding correct?
>>>>>
>>>>>
>>>>> Can you help me understand why you need the PT duplication? Is this
>>>>> just
>>>>
>>>> so
>>>>>
>>>>> that you could understand distinguish between two sources? If so,
>>>>> then it wouldn't be necessary.
>>>>>
>>>>> With No Plan you would just send:
>>>>>
>>>>>         m=video 5002 RTP/SAVPF 97 99
>>>>>         a=mid:video
>>>>>         a=rtcp-mux
>>>>>         a=rtpmap:97 VP8/90000
>>>>>         a=rtpmap:99 H264/90000
>>>>>
>>>>> If then you want to have one of the VP8 streams rendered on the left
>>>>
>>>> screen
>>>>>
>>>>> and the other on the right, you will add this in application-specific
>>>>
>>>> signalling. A
>>>>>
>>>>> web application could do this like this:
>>>>>
>>>>> {
>>>>>        "leftSSRC": "1234",
>>>>>        "rightSSRC": "5678"
>>>>> }
>>>>>
>>>>> An WebRTC-to-SIP gateway could transform this into SDP or whatever
>>>>> that target devices need.
>>>>>
>>>>> Does this answer your question?
>>>>>
>>>>> Emil
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Roni
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>>>>>> Behalf Of Emil Ivov
>>>>>>> Sent: 29 May, 2013 10:00 PM
>>>>>>> To: rtcweb@ietf.org
>>>>>>> Subject: [rtcweb] No Plan
>>>>>>>
>>>>>>> Hey all,
>>>>>>>
>>>>>>> Based on many of the discussions that we've had here, as well as
>>>>>>> many others that we've had offlist, it seemed like a good idea to
>>>>
>>>> investigate a
>>>>>>>
>>>>>>> negotiation alternative that relies on SDP and Offer/Answer just a
>>>>
>>>> little
>>>>>>
>>>>>> bit
>>>>>>>
>>>>>>> less.
>>>>>>>
>>>>>>> The following "no plan" draft attempts to present one such approach:
>>>>>>>
>>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>>>>>>
>>>>>>> The draft relies on conventional use of SDP O/A but leaves the
>>>>
>>>> intricacies
>>>>>>
>>>>>> of
>>>>>>>
>>>>>>> multi-source scenarios to application-specific signalling, with
>>>>>>
>>>>>> potentially a
>>>>>>>
>>>>>>> little help from RTP.
>>>>>>>
>>>>>>> Hopefully, proponents of Plans A and B would find that the
>>>>>>
>>>>>> interoperability
>>>>>>>
>>>>>>> requirements that concerned them can still be met with "no plan".
>>>>>>> Of
>>>>>>
>>>>>> course
>>>>>>>
>>>>>>> they would have to be addressed by application-specific signalling
>>>>
>>>> and/or
>>>>>>>
>>>>>>> signalling gateways.
>>>>>>>
>>>>>>> Comments are welcome!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Emil
>>>>>>>
>>>>>>> --
>>>>>>> https://jitsi.org
>>>>>>> _______________________________________________
>>>>>>> rtcweb mailing list
>>>>>>> rtcweb@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> https://jitsi.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> https://jitsi.org
>>
>>
>>
>
> --
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb