Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt )
Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Sun, 19 May 2013 11:35 UTC
Return-Path: <stefan.lk.hakansson@ericsson.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 8E72821F8D7A for <rtcweb@ietfa.amsl.com>; Sun, 19 May 2013 04:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.692
X-Spam-Level:
X-Spam-Status: No, score=-4.692 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666]
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 pcKR31IadEup for <rtcweb@ietfa.amsl.com>; Sun, 19 May 2013 04:35:49 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BABF921F8D31 for <rtcweb@ietf.org>; Sun, 19 May 2013 04:35:48 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fe36d000007102-df-5198b913e5c7
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 73.3D.28930.319B8915; Sun, 19 May 2013 13:35:47 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Sun, 19 May 2013 13:35:47 +0200
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt )
Thread-Index: AQHOUNuv7sx/DKV64Ei4hdgR8OpAYQ==
Date: Sun, 19 May 2013 11:35:46 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2CDEE8@ESESSMB209.ericsson.se>
References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, <CALe60zAi_Lx3QFCbBQ5aPNkgorJAff0E79jkpbQX1Qt3wf2bzg@mail.gmail.com>, <CAOJ7v-1Wk6u7XiYrNVmoqr5Jisu2WRvZpte7hQTOiP8YHUc6hg@mail.gmail.com>, <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <BLU169-W108D56DF61B85814543873C93BA0@phx.gbl>, <518AAAF2.5000207@alum.mit.edu>, <CA+9kkMBw4+kXAv6qLCcmGLwMxAqR6P-Tk8dm-ardv_jihHx0Hw@mail.gmail.com>, <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, <CA+9kkMC-NnF+VugBOZNhY4-Cz1tqJA44WSF9dg45g4GCWxkh-g@mail.gmail.com>, <518D6C76.5060606@alum.mit.edu>, <CAHBDyN6xYor-XWnLEkufoQPYrDc+KurrM0m3HBTqLXqNkPtDkQ@mail.gmail.com> <BLU169-W82D3FCC3246D6D878FA44E93A00@phx.gbl> <5191F948.3040402@ericsson.com> <51920280.3080308@jitsi.org> <519223A0.1040908@ericsson.com> <5192947F.90206@jitsi.org> <1447FA0C20ED5147A1AA0EF02890A64B1C2CCE9A@ESESSMB209.ericsson.se> <519531F6.1010201@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvra7wzhmBBttPKVqs2TmBxWLtv3Z2 ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlXH57A2mgj/aFVumqzUwzlHuYuTkkBAwkbg2 eQcThC0mceHeerYuRi4OIYHDjBLnXy5lhnCWMEp8WX6VFaSKTSBQYuu+BWwgtoiAvER32yKw bmYBdYk7i8+xgzQIC8xhlPi1dxUjiCMiMJdRYt+St1AdehJTtq5gBrFZBFQlep6dZQGxeQV8 JbZ8nsEIsa6fXaJxZQNYghHoqO+n1kCtEJe49WQ+1LECEkv2nGeGsEUlXj7+xwphK0k0LnnC ClGvJ3Fj6hQ2CFtbYtnC18wQywQlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl hpsYgfFwcMtv3R2Mp86JHGKU5mBREuft1Z4aKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR cfk/xUNnS/JiTNS5vp4VMP/BOb18VoTmTLk0Pd8lZ//Yf3b63qMQus2V+8jVw+IWK43eJwrd /qYTO+P6aoktNlfEFz1IS9k2TfF52hlfbaWerQVRS1LbXIuq7k0uOHnS4ID+uuO8266VLZP7 nD3z+j6jaxcWTj3A+3nBs502uzas7r13mGGlkxJLcUaioRZzUXEiAFmjlntVAgAA
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt )
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: Sun, 19 May 2013 11:35:54 -0000
On 5/16/13 9:22 PM, Emil Ivov wrote: > > > On 16.05.13, 12:45, Stefan Håkansson LK wrote: >> On 5/14/13 9:46 PM, Emil Ivov wrote: >>> Hey Stefan, >>> >>> On 14.05.13, 14:44, Stefan Håkansson LK wrote: >>>>>> SSRCs - this would be SDP >>>>> >>>>> Again, including SSRCs in SDP O/A is tricky in conferencing scenarios. >>>> >>>> Here seems to be something that I have missed. That there are existing >>>> implementations that do not signal SSRC is fine, and in most cases there >>>> would be only one audio and one video SSRC used anyway. And rtcweb (and >>>> Clue?) should be able to interoperate (but perhaps your web app need to >>>> be designed in a specific way). >>>> >>>> But if we design something forward looking, that can handle many >>>> streams, that can handle layered codecs and FEC data, signaling SSRCs >>>> seems like a must to me. >>>> >>>> But I have missed that this is problematic in conferencing scenarios, >>>> could you tell me why (and I probably should know :) )? >>> >>> The issue that I am referring to (I describe this in an earlier mail to >>> Harald here http://goo.gl/M8NbQ ) is that of a conference based on an >>> RTP translator. It's basically what we do in Jitsi Videobridge. >>> >>> Let's say that I am a WebRTC app that can act as a conference focus and >>> that has access to an RTP translator somewhere. I'd like to organise a >>> conference with 10 people (you and I among them). >>> >>> I ask the RTP translator to allocate 10 ports for me and then I start >>> calling participants. >>> >>> You are the first one that I am going to join into this new call. >>> >>> At this point, the only SSRC(s) that I could possibly give you are those >>> that I am going to use. I won't be able to tell you anything for the >>> eight other participants. For all I know, some or all of these >>> participants could turn out to be RTP translators themselves and there >>> could be a number of SSRCs behind each of them too. >>> >>> The very logical and easy thing that your webapp could do here is not to >>> care and simply render each and every SSRC that you get. Most apps are >>> going to be perfectly happy with that. >>> >>> If, on the other hand you needed me to re-offer you every time a new >>> participant joins in order to work properly, then things would easily >>> get quite messy even if everyone is using WebRTC. >>> >>> Then, note that some of the participants can be simple SIP endpoints >>> (that's why we bothered with SDP in the first place right?) so the only >>> way I can get their SSRCs is with some extra signalling between me and >>> the RTP translator. This is not a problem per se, but it can only happen >>> after the SIP participants have joined the call and started streaming >>> data, that has reached the translator. And even then they will have no >>> MSIDs. >>> >>> All in all, we would be enforcing some very laborious signalling when >>> it is absolutely unnecessary. >> >> Thanks, I then understand the use-case you're envisioning. >> >> I think it could work under certain conditions, but as soon as there are >> repair flows, enhancement layers or simulcast involved, there is a need >> anyway to somehow signal what each SSRC represents. > > I don't think anyone is arguing against this. > >> Then it is another >> question if it happens via SDP or via RTP header extensions or some >> other means. >> >> There was a discussion at the Stockholm rtcweb interim on what >> topologies that would be supported, but I fail to remember if this case >> was included or excluded. > > I couldn't find the discussion (in what WG did it happen?) but > topologies based on RTP translators of one sort or another seem to be > the default way of handling video conferencing these days so I don't see > how we could possibly rule them out. It was at the rtcweb interim in Stockholm last June (but I don't remember the details of the outcome of the discussion). I'm no expert, but how do you handle things like congestion management with translators? IIUC the RMCAT group has decided to handle the simple point-point case only. (I'm not trying to remove translators from the topologies we cover - I just want to bring all the pieces to the table). > >> It also seems to me that people have quite different views in the >> discussion. > > Of course, where would the fun be otherwise? :) > >> One view seems to be that SDP exchanges should be used even >> for things like pause/resume, resolution changes, > > Right! That's the wrong view ;). We made two important choices in this > working group: > > a) we will not impose a signalling protocol, and > b) we will use SDP O/A to make it easier to talk to legacy apps/devices. > > Let's not try to compensate for the former by hijacking the latter. > >> another that we should >> avoid SDP exchanges even when people join/leave a conference. > > Even? I'd argue that this is _the_ place where avoiding SDP O/A is most > important! > > Emil >
- Re: [rtcweb] Fwd: New Version Notification for dr… Christer Holmberg
- [rtcweb] Fwd: New Version Notification for draft-… Justin Uberti
- Re: [rtcweb] Fwd: New Version Notification for dr… Harald Alvestrand
- Re: [rtcweb] Fwd: New Version Notification for dr… Harald Alvestrand
- Re: [rtcweb] Fwd: New Version Notification for dr… Stefan Håkansson LK
- Re: [rtcweb] Fwd: New Version Notification for dr… Christer Holmberg
- Re: [rtcweb] Fwd: New Version Notification for dr… Roni Even
- Re: [rtcweb] Fwd: New Version Notification for dr… Harald Alvestrand
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Harald Alvestrand
- Re: [rtcweb] Fwd: New Version Notification for dr… Christer Holmberg
- Re: [rtcweb] Fwd: New Version Notification for dr… Paul Kyzivat
- Re: [rtcweb] Fwd: New Version Notification for dr… Bernard Aboba
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Bernard Aboba
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Roni Even
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Bernard Aboba
- Re: [rtcweb] Fwd: New Version Notification for dr… Stefan Håkansson LK
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Harald Alvestrand
- Re: [rtcweb] Fwd: New Version Notification for dr… Paul Kyzivat
- Re: [rtcweb] Fwd: New Version Notification for dr… Ted Hardie
- Re: [rtcweb] Fwd: New Version Notification for dr… Paul Kyzivat
- Re: [rtcweb] [MMUSIC] New Version Notification fo… Cullen Jennings (fluffy)
- Re: [rtcweb] [MMUSIC] New Version Notification fo… Hutton, Andrew
- Re: [rtcweb] New Version Notification for draft-u… Cullen Jennings
- Re: [rtcweb] New Version Notification for draft-u… Cullen Jennings
- Re: [rtcweb] New Version Notification for draft-u… Ted Hardie
- Re: [rtcweb] New Version Notification for draft-u… Paul Kyzivat
- Re: [rtcweb] New Version Notification for draft-u… Ted Hardie
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Eric Rescorla
- [rtcweb] We are moving beyond the assumptions on … Paul Kyzivat
- Re: [rtcweb] We are moving beyond the assumptions… Bernard Aboba
- Re: [rtcweb] We are moving beyond the assumptions… Emil Ivov
- Re: [rtcweb] We are moving beyond the assumptions… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Justin Uberti
- Re: [rtcweb] We are moving beyond the assumptions… Roni Even
- Re: [rtcweb] We are moving beyond the assumptions… Paul Kyzivat
- Re: [rtcweb] New Version Notification for draft-u… Mary Barnes
- Re: [rtcweb] New Version Notification for draft-u… Bernard Aboba
- Re: [rtcweb] We are moving beyond the assumptions… Martin Thomson
- Re: [rtcweb] New Version Notification for draft-u… Martin Thomson
- Re: [rtcweb] We are moving beyond the assumptions… Justin Uberti
- Re: [rtcweb] We are moving beyond the assumptions… Justin Uberti
- Re: [rtcweb] We are moving beyond the assumptions… Emil Ivov
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Emil Ivov
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] We are moving beyond the assumptions… Ted Hardie
- Re: [rtcweb] We are moving beyond the assumptions… Paul Kyzivat
- [rtcweb] Why requiring pre-announcement of SSRCs … Emil Ivov
- Re: [rtcweb] We are moving beyond the assumptions… Ted Hardie
- Re: [rtcweb] Why requiring pre-announcement of SS… Justin Uberti
- Re: [rtcweb] Why requiring pre-announcement of SS… Roni Even
- Re: [rtcweb] New Version Notification for draft-u… Paul Kyzivat
- Re: [rtcweb] Why requiring pre-announcement of SS… Emil Ivov
- Re: [rtcweb] Why requiring pre-announcement of SS… Bernard Aboba
- Re: [rtcweb] Why requiring pre-announcement of SS… Emil Ivov
- Re: [rtcweb] Why requiring pre-announcement of SS… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] Why requiring pre-announcement of SS… Emil Ivov
- [rtcweb] Common ways of handling video conference… Harald Alvestrand
- Re: [rtcweb] Common ways of handling video confer… Emil Ivov
- Re: [rtcweb] Why requiring pre-announcement of SS… Stefan Håkansson LK
- Re: [rtcweb] Why requiring pre-announcement of SS… Emil Ivov
- Re: [rtcweb] Common ways of handling video confer… Paul Kyzivat
- Re: [rtcweb] Common ways of handling video confer… Emil Ivov
- Re: [rtcweb] Common ways of handling video confer… Roni Even
- Re: [rtcweb] Why requiring pre-announcement of SS… Cullen Jennings (fluffy)
- Re: [rtcweb] Fwd: New Version Notification for dr… Iñaki Baz Castillo