Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

Paul Kyzivat <> Mon, 13 May 2013 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DE6721F869C for <>; Mon, 13 May 2013 07:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.287
X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LJVcpAsUbBzH for <>; Mon, 13 May 2013 07:44:20 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:40]) by (Postfix) with ESMTP id 7D53F21F86CE for <>; Mon, 13 May 2013 07:44:20 -0700 (PDT)
Received: from ([]) by with comcast id bQHD1l0020ldTLk54SkK4z; Mon, 13 May 2013 14:44:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id bSkK1l00w3ZTu2S3QSkK2w; Mon, 13 May 2013 14:44:19 +0000
Message-ID: <>
Date: Mon, 13 May 2013 10:44:18 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1368456260; bh=cbpM5QaklGOgGcoNbFjVC3Vbc1/oG38IWOpPgwn9vfE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LFr2zSEwSRJVIjDQ3Fni80XXykmJdI1Tvqm8WSf9ozSTG+rNZB3so6bc9g66ng5MA Qzx85EbVHkVsdjXichJ0TkEGAxKRurRKoyj7W/ffDglIXn1Bz28tMUkvK4jdvSf8X9 5usXRph8ZObURZEjJIWh0/OdrTnWn57i0qsgLnPxteo4pXXM9o8Eniq3pGs42voHyT g4VJfbfgt0+gtFTIE47u8rVpu9W8OzUJg/1ZqWfjKG/WaMogGuZJB+cXQnLA6+Ch3B 3RagZdGtp0+kur+yA0rzG50S4OS4KZzZ2DpuksNKSe4QMFTQJ9p6wDpFgkTArILCVf VB5+5TwHBqsLA==
Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 May 2013 14:44:25 -0000

I'm not going to comment further on the specifics here, since they have 
been well flogged already. But the point of this particular discussion 
was about the likelihood of glare. Stefan's assertion was that O/As 
initiated by one end due to rapid changes in which streams it wants to 
receive will drive up the possibility of glare when the other end wants 
to do an O/A.

I'll just say that if the number of O/As has gone up that much, then 
that was a bad choice of mechanism.


On 5/13/13 10:33 AM, Emil Ivov wrote:
> Hey Stefan,
> On 13.05.13, 10:21, Stefan Håkansson LK wrote:
>>> Well the way I remember it SDP O/A was chosen for session negotiation
>>> and that other forms of signalling were explicitly left out of the
>>> charter.
>> I took the result of the discussion and poll at the IETF-84
>> ( as
>> an indication of that SDP O/A should be used for this kind of in-session
>> changes as well.
> True, I am not sure we all realized the number of use cases this would
> end up encompassing and how we would end up implementing signalling
> features into SDP.
>>>> In this case either to transmit a new imageattr value
>>> imageattr is great as a declarative parameter indicating capabilities:
>>> "I can't show more than 720p so there's no point to send me more than
>>> that". Using it as a way to switch between thumbnail and HQ videos is
>>> not entire impossible but is not particularly efficient either.
>> To me it looks like a solution that people might feel inclined towards
>> using.
>> But there are others that want to use simulcast, and then pause/resume
>> sending of high and low resolution streams, and that problem is more or
>> less the same when it comes to signaling.
>> And even if we omitted the possibility for a receiver to indicate to the
>> sender (via standardized signaling) that it should pause or resume
>> sending, and instead left that up to an API (at sender side) and
>> proprietary signaling, we still have to have some kind of signaling IMO:
>> the sender can not just stop sending RTP packets, there need to be a
>> signal to the receiver so it understands this
> I never implied there should be no signalling. Just that implementing it
> all over SDP O/A leads to unforeseen complexities.
> RTCP BYE and/or SSRC expiration would be one option here. Custom
> signalling another.
> Cheers,
> Emil