Re: [rtcweb] A problem with both A and B

Suhas Nandakumar <suhasietf@gmail.com> Thu, 23 May 2013 09:40 UTC

Return-Path: <suhasietf@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 0735921F8BC5 for <rtcweb@ietfa.amsl.com>; Thu, 23 May 2013 02:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=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 Zawg9t11c23d for <rtcweb@ietfa.amsl.com>; Thu, 23 May 2013 02:40:01 -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 4093121F8BBC for <rtcweb@ietf.org>; Thu, 23 May 2013 02:40:01 -0700 (PDT)
Received: by mail-qa0-f41.google.com with SMTP id bn16so3296170qab.14 for <rtcweb@ietf.org>; Thu, 23 May 2013 02:40:00 -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=K1h2dhSs8x4OiS7zbJ09uXx9FivaDH9mSpRnxnLo0+Y=; b=AJDmsGlGgq9yqy5sR/jY+MXjkpYxXOoEH6stKAL+TBsbc1PwzlfvsOn9ZkDTzIdysp ZXZEinXDiCMfntnKe1LYxZ8mO0bXn6O6Sfc/V31/5bPxc6vL4yOEse/lCPzMQZE0gc9v 8zGoHs6iqxkFZjsEMAWeC5OGBovqlKc6dMLBHphy358JwqEI1yM7pRLsxysW8SPXAXfp PQ2+fQ0JO2tYv7lTCo/IlXaTGQEYVUBhpQuUcuzN6nOZxUAGGmQ5YuEI6waCRMD1WH1H FtVDoiLefNtoeqgA73Jw0bYGDCW0ErOzdCkd4kRxaPiOnfiSgPm9qB02ZoxM5AZ/HC0Q 1hXQ==
MIME-Version: 1.0
X-Received: by 10.49.85.131 with SMTP id h3mr12292349qez.42.1369302000462; Thu, 23 May 2013 02:40:00 -0700 (PDT)
Received: by 10.49.25.14 with HTTP; Thu, 23 May 2013 02:40:00 -0700 (PDT)
In-Reply-To: <CAMvTgccWBC+4GXJ_mjYj66Lmkhc_eTtr1G3nVC1u59ya1RLgtg@mail.gmail.com>
References: <BLU403-EAS40305B2D015B786CC67EB9293AC0@phx.gbl> <CABkgnnXX3zoeKqjFxjsfMgaGGRM0JzymaeWfA13LEjUZ4tGF9Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C373EF0@ESESSMB209.ericsson.se> <519A4C9A.6020501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C374F13@ESESSMB209.ericsson.se> <519BD580.7080205@alum.mit.edu> <519C86EF.5080601@ericsson.com> <519CE696.1010606@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2D081A@ESESSMB209.ericsson.se> <CAMRcRGRkH5evUDZUFKObWD3CjY4wGSGVHQfbLhuV6pQzDc0SJw@mail.gmail.com> <CAMvTgccWBC+4GXJ_mjYj66Lmkhc_eTtr1G3nVC1u59ya1RLgtg@mail.gmail.com>
Date: Thu, 23 May 2013 02:40:00 -0700
Message-ID: <CAMRcRGSOd7sEx71toD5PJrOS-2RhD3CtCWHP6Br+yf0YS0g8Lg@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Kevin Dempsey <kevindempsey70@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bd7566a54244a04dd5f7781"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] A problem with both A and B
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, 23 May 2013 09:40:03 -0000

Hey Kevin,

On Thu, May 23, 2013 at 1:40 AM, Kevin Dempsey <kevindempsey70@gmail.com>wrote:

> Adding or removing a source generally doesn't need a SDP O/A. The offerer
> has indicated where media of a given type should be sent. The answerer can
> arrange for any source it wants to send to that destination. It is unusual
> for an answerer to send more that one SSRC at a time, but changing  the
> source (and SSRC) is not uncommon
>

%Suhas% True in some cases and False in some.

What if the new source produces pre-encoded stream that is not been
negotiated within the current session ?
example: video m=line with VP8 is setup and H.264 encoded camera is added
as new source. This needs a O/A negotiation for the appropriate decoder
context to be setup on the receiver side
OR similarly
a high resolution video layer/feed or  a different ptime based audio source
is added or a sendonly source is added.



How the offerer handles the change of SSRC, or receiving multiple SSRCs is
> application specific. I believe most SIP endpoints I have used render only
> one SSRC per m= line at a time and have some mechanism to switch SSRC when
> the one they were rendering stops.
>

%Suhas% Agreed. A change in SSRC or totally new SSRC(s) seen at the
end-point can be handled in a App Specific way.

Thanks
Suhas

> On 23 May 2013 09:03, Suhas Nandakumar <suhasietf@gmail.com> wrote:
>
>> Great Summarization Paul.
>>
>> My 2 cents
>>
>> SDP O/A enables parties in a session to decide on a compatible view of
>> the session. This implies setting up appropriate transport  , media stack
>> (encoders, decoders) context and alike in a way that the parties involved
>> can have a successful session.
>>
>> Regardless of Plan A or Plan B , any modifications to session parameters
>> ( adding new source, removing a source, modifying existing parameters) that
>> impacts resources managed, needs to be negotiated and O/A helps in this
>> regard.
>>
>> Thanks
>> Suhas
>>
>>
>> On Wed, May 22, 2013 at 9:08 AM, Stefan Håkansson LK <
>> stefan.lk.hakansson@ericsson.com> wrote:
>>
>>> On 5/22/13 5:41 PM, Paul Kyzivat wrote:
>>> > On 5/22/13 4:50 AM, Stefan Håkansson LK wrote:
>>> >> I think this was a good summary.
>>> >>
>>> >> But regarding "a mechanism for describing the role and intent of each
>>> >> RTP stream in the RTP session.", do we really need that? Isn't the
>>> >> combination of ssrc and the msid draft sufficient?
>>> >>
>>> >> Together the clearly identify how ssrc's map into PC-streams and
>>> >> PC-tracks, and the application can convey the remaining info (e.g.
>>> >> PC-stream xx represents the speaker audio+video, yy the room video
>>> etc.)
>>> >> needed in any way it likes .
>>> >
>>> > My statements were not intended to be rtcweb-specific. The bundling
>>> > stuff is going to be a more general SDP extension. IMO the problems
>>> that
>>> > rtcweb and clue have encountered that need this are just the tip of the
>>> > iceberg.
>>>
>>> You're probably right in this (and I have to admit my comments are
>>> usually quite rtcweb centric).
>>>
>>> >
>>> > My point about the role/intent is that the application must have some
>>> > means to determine this. It doesn't always need to be in SDP. But the
>>> > old approach that is mostly based on the cases being so simple that it
>>> > is always obvious without signaling are now breaking down. And in the
>>> > case of SIP apps there are few mechanisms to build on other than SDP.
>>>
>>> I agree to the above.
>>>
>>> But taking my usual rtcweb shortcut, could we imagine that rtcweb solves
>>> this with something like msid (i.e. you just provide the identity of
>>> each stream, and leave it up to the app to exchange what content it
>>> represents)?
>>>
>>> Once we have something that is usable in a SIP world (an agreed way to
>>> signal this in SDP), perhaps the web app could add that to the SDP. (Not
>>> that clean, but could work).
>>>
>>> >
>>> >       Thanks,
>>> >       Paul
>>> >
>>> >> Stefan
>>> >>
>>> >> On 2013-05-21 22:13, Paul Kyzivat wrote:
>>> >>> On 5/21/13 3:20 AM, Christer Holmberg wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>>>> I don't think it's a BUNDLE issue whether adding/removing of
>>> streams
>>> >>>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue.
>>> >>>>>>
>>> >>>>>> BUNDLE is about sharing a 5-tuple.
>>> >>>>>
>>> >>>>> I don't agree.
>>> >>>>>
>>> >>>>> RTP is already able to support multiple RTP streams sharing an RTP
>>> >>>>> session (and 5-tuple).
>>> >>>>>
>>> >>>>> What BUNDLE is about is describing that in SDP.
>>> >>>>> And that includes how SDP O/A works.
>>> >>>>
>>> >>>> Multiple RTP streams can already share an RTP session today, using
>>> >>>> multiple SSRCs per m- line :)
>>> >>>>
>>> >>>> If adding a new stream means adding a new m- line, then an SDP O/A
>>> is
>>> >>>> obviously needed - bundle or no bundle.
>>> >>>>
>>> >>>> If adding a new stream means adding a new SSRC, within an existing
>>> m-,
>>> >>>> then it is also an SDP O/A issue - bundle or no bundle.
>>> >>>
>>> >>> AFAIK there is wide agreement that an RTP *session* can carry
>>> multiple
>>> >>> RTP streams.
>>> >>>
>>> >>> An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP
>>> >>> session. There is disagreement whether it is permissible for the
>>> >>> resulting RTP session to carry multiple RTP streams. The specs are
>>> >>> ambiguous on this point. Clearly there are well identified cases
>>> where
>>> >>> they do, and we aren't likely to rule those incorrect. Its also clear
>>> >>> that some of these cases start out sending a single SSRC, and then
>>> later
>>> >>> "add" another. (It may actually be a substitution.)
>>> >>>
>>> >>> So it seems clear to me that you may add an RTP stream to an RTP
>>> session
>>> >>> described by an m-line without doing another O/A exchange.
>>> >>>
>>> >>> What is lacking in such cases is a mechanism for describing the role
>>> and
>>> >>> intent of each RTP stream in the RTP session. In some cases it is
>>> >>> possible to get by without this, by assuming that the two ends have
>>> >>> consistent *assumptions* about how to infer the role/intent. But
>>> there
>>> >>> are many cases where this isn't enough.
>>> >>>
>>> >>> Extra SDP syntax has been defined in an ad hoc way to get at bits and
>>> >>> pieces of this problem. E.g., the a=ssrc attribute. What has already
>>> >>> been defined doesn't seem suficient for all the new cases we are no
>>> >>> discussing.
>>> >>>
>>> >>> BUNDLE is *another* proposal for addressing part or all of this
>>> problem.
>>> >>> But BUNDLE brings along another problem: for BUNDLE to be useful, it
>>> >>> must be possible to associate each RTP packet with one of the bundled
>>> >>> m-lines. Without BUNDLE we don't have that problem.
>>> >>>
>>> >>> To summarize:
>>> >>>
>>> >>> - without bundle, we need a mechanism for describing the role/intent
>>> >>>     of each RTP stream in the RTP session. *If* we choose to describe
>>> >>>     that with SDP, then we need an O/A exchange each time we add
>>> >>>     an RTP stream.
>>> >>>
>>> >>> - with BUNDLE and Plan A, the assumption is that each m-line in the
>>> >>>     bundle describes a single RTP stream, and so the other SDP stuff
>>> >>>     in that media section can be used to describe the role/intent of
>>> >>>     that RTP stream. By design this requires a new m-line for each
>>> >>>     RTP stream, so adding one requires an O/A. We then assume that
>>> there
>>> >>>     is enough stuff in each media section to decide which m-line each
>>> >>>     packet should be associated with.
>>> >>>
>>> >>> - with BUNDLE and Plan B, there may be multiple RTP streams per
>>> >>>     m-line. As in Plan A we need to associate each packet with one of
>>> >>>     the m-lines. Like the no-bundle case we still need some mechanism
>>> >>>     to describe the role/intent if the individual RTP streams.
>>> >>>     In some cases (e.g., a=ssrc) the same info that classifies to
>>> >>>     an m-line may also specify the role of each stream. That case
>>> >>>     also leads to an O/A for each stream add.
>>> >>>
>>> >>>     If you have a non-SDP way to discover the role/intent of each
>>> >>>     RTP stream, and you use a way of classifying to one of the
>>> >>>     bundled m-lines *without* enumerating every RTP stream, then
>>> >>>     you can perhaps avoid an O/A for each stream add. E.g., if you
>>> >>>     just bundle one audio and one video m-line, and use PT to
>>> >>>     distinguish those.
>>> >>>
>>> >>> Note: in above I said Plan A uses an m-line for each RTP stream. That
>>> >>> isn't always the case. There are some cases (at least in clue) where
>>> >>> each m-line is intended to describe a "flow" (clue capture) that may
>>> >>> correspond to different RTP streams over time, or that might include
>>> >>> supporting FEC streams, etc. Depending on your assumptions about this
>>> >>> case it may start to take on some of the characteristics of Plan B.
>>> >>>
>>> >>>       Thanks,
>>> >>>       Paul
>>> >>>
>>> >>> _______________________________________________
>>> >>> rtcweb mailing list
>>> >>> rtcweb@ietf.org
>>> >>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> >>
>>> >> _______________________________________________
>>> >> rtcweb mailing list
>>> >> rtcweb@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/rtcweb
>>> >>
>>> >
>>> > _______________________________________________
>>> > rtcweb mailing list
>>> > rtcweb@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>> >
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>