Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun)
Emil Ivov <emcho@jitsi.org> Wed, 15 May 2013 16:06 UTC
Return-Path: <emil@sip-communicator.org>
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 F399F11E80D1 for <rtcweb@ietfa.amsl.com>; Wed, 15 May 2013 09:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.537
X-Spam-Level:
X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-1.837, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899]
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 YTYn291uyQDp for <rtcweb@ietfa.amsl.com>; Wed, 15 May 2013 09:06:34 -0700 (PDT)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id B0A6621F8FF2 for <rtcweb@ietf.org>; Wed, 15 May 2013 09:06:33 -0700 (PDT)
Received: by mail-bk0-f52.google.com with SMTP id mz10so311471bkb.39 for <rtcweb@ietf.org>; Wed, 15 May 2013 09:06:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=xGJiwM5eYX0uygob38j+IyVhcISod6g55BuTaoNoOfQ=; b=mbwcZxxvBmM5bc1uyqVhvWj8adN1/NiymE2x538LIfNlLfrZe4UnAUB58ju/jYGZzV gpImEYN6F0lPC4lIOUjfBeOmVU6e9/U0tH8z1uYrMNVvmYywxMEOVKI4n10YciOFMFwV EAyTK9td8FETvdb0IWZ/RfpR6Zif0cwa5lXT06Yv5bFYY6TCKlYyuIiyH4xkElsDdZmd GywmddDRdShQGkGaEmKXVKDqyrZNCGhE84hdRzjUURWWauXd7VK/8aG2PpTLxrjVJEcs LGKpW8xvmynnHhQb4GhtmqZfFcAlm4iRMVQFO2ho7Qug0ojWna+8OflKPZ6m3t3Z2lHw FdfQ==
X-Received: by 10.204.186.143 with SMTP id cs15mr842200bkb.104.1368633992486; Wed, 15 May 2013 09:06:32 -0700 (PDT)
Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id j8sm1035255bky.17.2013.05.15.09.06.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 09:06:31 -0700 (PDT)
Message-ID: <5193B285.8090604@jitsi.org>
Date: Wed, 15 May 2013 19:06:29 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <CAPvvaaK1bQ+0DwAWwjN2P1RQOAY2cGC0Hf88od2ZnFA0gu6s4g@mail.gmail.com> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org> <5191FCFB.3090704@jitsi.org> <51922959.3070708@alvestrand.no> <51931EF3.7080108@jitsi.org> <51932A2B.1080700@alvestrand.no>
In-Reply-To: <51932A2B.1080700@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQn6Lq+IfTEGMgDGNjJ+xWSMSAB0Mvxk+BltR0Ur/jD4Qma4bM1wAjsEHNXsO4PDW/7KwsXm
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun)
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, 15 May 2013 16:06:35 -0000
On 15.05.13, 09:24, Harald Alvestrand wrote: > On 05/15/2013 07:36 AM, Emil Ivov wrote: >> >> On 14.05.13, 15:08, Harald Alvestrand wrote: >>> On 05/14/2013 10:59 AM, Emil Ivov wrote: >>>> On 14.05.13, 09:16, Emil Ivov wrote: >>>>> Hey Harald, >>>>> >>>>> On 12.05.13, 22:55, Harald Alvestrand wrote: >>>>>> On 05/12/2013 06:03 PM, Emil Ivov wrote: >>>>>>>> Or you could signal none of them and depend on the fallback case in >>>>>>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and >>>>>>>> use other methods to figure out how to handle them... >>>>>>> If you are referring to section 4.1 that you also pasted earlier in >>>>>>> this thread, it only talks about one track, per stream, per m= line. >>>>>>> This doesn't cover the conferencing case I described in my previous >>>>>>> mail (quoted above). >>>>>>> >>>>>> Changing subject as I'm replying to a subtopic, and because I was >>>>>> misunderstanding what Emil was arguing in favour of..... >>>>>> >>>>>> when I wrote that text, I didn't intend it to cover only one SSRC per >>>>>> stream. >>>>>> What I intended to say was that when, in an RTP session, a browser gets >>>>>> several SSRCs that were not mentioned in signalling, it will send >>>>>> several onaddstream signals to the application, each indicating a new >>>>>> stream being added, which has exactly one track. >>>>> Aha! OK, I understand and it sounds better now that I do. >>>> Oh, just thought of something else while reading Stefan's mail: is it >>>> really necessary that this should only happen in case no SSRCs have been >>>> defined? Why not apply that to any unknown SSRC regardless of whether or >>>> not others exist in SDP? >>>> >>>> The second bullet there talks about a possible race condition but I am >>>> not sure I see how this could occur with valid use of O/A. >>> The worrying case is: >>> >>> A sends offer >>> B sends answer (either with or without MSID) >>> B starts sending data on some SSRCs >>> A receives the data, but has not yet seen the answer >>> >>> The two cases are: >>> >>> - B sends with MSID. In this case, he expects those specific IDs to be >>> signalled in onaddstream. >>> - B sends without MSID. In this case, he expects that A will announce a >>> locally generated ID in onaddstream. >>> >>> A can't know the difference between those two before he sees the answer >>> from B. >>> In this spec, I've "solved" it by saying that we don't signal >>> onaddstream before we see the answer. >>> >>> After the first answer has been seen, either party knows that new SSRCs >>> always will be signalled, so any data on an unknown SSRC can be held >>> until the negotiation announcing it is complete - or discarded as "bad >>> data" if signalling doesn't happen in a reasonable time. >>> >>> If we were to permit unknown SSRCs when there are some MSIDs, the >>> decision to announce as "Unsignalled MediaStream" or wait for the >>> offer/answer announcing the MSID it should be announced with has to >>> depend on some other resolution mechanism. I don't like timers, and >>> haven't found a better way to do it. >> I didn't get this part. While I see the race condition that occurs >> during offer/answer, I am not sure I understand why a new SSRC received >> mid-session by either side is ambiguous. If the application had any >> intent to announce it, then presumably it would be on the verge of >> initiating a new offer/answer. If that were the case, sending the new >> stream/track could have been held off until completion of that >> offer/answer. > Exactly - IF the party sending the SSRC is able to see when the > offer/answer completes. > The offerer is the only party that can actually know if the offer/answer > exchange is complete. OK, got it. Then, going back to your second bullet, we could apply the same buffering as the one you currently describe there. Only this time, once we are done with the offer/answer things could go either way: we could end up either signalling a new track or determining that packets actually belong to some specific stream. If this makes sense, I'd be happy to propose text if it helps. > So the ambiguity only applies if the answerer is able to announce new > SSRCs in an answer. > Is it reasonable to remove this functionality (and thereby mandating > Plan B's double offer/answer) in order to achieve this functionality? > >> >> This way one would be able to only announce SSRCs for things such as FEC >> and simulcasting (where available) while simple streams could be >> delivered immediately. > > As long as you don't need any information not carried in the RTP packet > in order to announce the stream correctly, this would work. I suppose we'll get there eventually. RTCP is one option here but what I am personally hoping is that we'll agree that the APIs can also start providing that information so that web apps can exchange it any way they wish. Before, with, or after the SDP O/A has taken place. Cheers, Emil -- https://jitsi.org
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Harald Alvestrand
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Jonathan Lennox
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Harald Alvestrand
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Dale R. Worley
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Martin Thomson
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Jonathan Lennox
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Emil Ivov
- [rtcweb] MSID fallback for non-MSID case (Re: Pla… Harald Alvestrand
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Kevin Dempsey
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Christer Holmberg
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Bernard Aboba
- Re: [rtcweb] Plan A, respun Cullen Jennings (fluffy)