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 >> >> >
- [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Dale R. Worley
- Re: [rtcweb] A problem with both A and B Bernard Aboba
- Re: [rtcweb] A problem with both A and B Martin Thomson
- Re: [rtcweb] A problem with both A and B Roni Even
- Re: [rtcweb] A problem with both A and B Stefan Håkansson LK
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Kevin Dempsey
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Sergio Garcia Murillo
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Kevin Dempsey
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Kevin Dempsey
- Re: [rtcweb] A problem with both A and B Paul Kyzivat
- Re: [rtcweb] A problem with both A and B Paul Kyzivat
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Kevin Dempsey
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Kevin Dempsey
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Paul Kyzivat
- Re: [rtcweb] A problem with both A and B Martin Thomson
- Re: [rtcweb] A problem with both A and B Stefan Håkansson LK
- Re: [rtcweb] A problem with both A and B Paul Kyzivat
- Re: [rtcweb] A problem with both A and B Paul Kyzivat
- Re: [rtcweb] A problem with both A and B Stefan Håkansson LK
- Re: [rtcweb] A problem with both A and B Suhas Nandakumar
- Re: [rtcweb] A problem with both A and B Kevin Dempsey
- Re: [rtcweb] A problem with both A and B Suhas Nandakumar
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Sergio Garcia Murillo
- Re: [rtcweb] A problem with both A and B Emil Ivov
- Re: [rtcweb] A problem with both A and B Christer Holmberg
- Re: [rtcweb] A problem with both A and B Cullen Jennings (fluffy)
- Re: [rtcweb] A problem with both A and B Richard Barnes