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

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 04 June 2013 18:15 UTC

Return-Path: <bernard_aboba@hotmail.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 9980F21F9A0D for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 11:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.651
X-Spam-Level:
X-Spam-Status: No, score=-100.651 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, 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 Ukkss-L0McZY for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 11:15:23 -0700 (PDT)
Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id A6BFD21F9D1B for <rtcweb@ietf.org>; Tue, 4 Jun 2013 10:29:50 -0700 (PDT)
Received: from BLU404-EAS142 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jun 2013 10:29:48 -0700
X-EIP: [P/V4b4gTSHE3ZL+MIK0sibzIdn7r4JwC]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU404-EAS14250610902587788E9538F939E0@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com> <51AC73EE.5080603@jitsi.org> <026201ce60a6$6d406f20$47c14d60$@gmail.com>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <026201ce60a6$6d406f20$47c14d60$@gmail.com>
Date: Tue, 4 Jun 2013 10:29:45 -0700
To: Roni Even <ron.even.tlv@gmail.com>
X-OriginalArrivalTime: 04 Jun 2013 17:29:48.0894 (UTC) FILETIME=[1D17F7E0:01CE6149]
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: Tue, 04 Jun 2013 18:15:27 -0000

No. It just means that you cannot have two different codecs with the same PT on the same m line (without Bundle) or in any m-line (with Bundle).  

On Jun 3, 2013, at 3:11 PM, "Roni Even" <ron.even.tlv@gmail.com> 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
> 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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb