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

Emil Ivov <> Mon, 13 May 2013 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72E0621F8F4D for <>; Mon, 13 May 2013 07:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JkFQ2ADjWZYu for <>; Mon, 13 May 2013 07:33:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4008:c01::234]) by (Postfix) with ESMTP id DCCF521F9409 for <>; Mon, 13 May 2013 07:33:13 -0700 (PDT)
Received: by with SMTP id mz1so300327bkb.39 for <>; Mon, 13 May 2013 07:33:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=O+H+EnDlhjUOxj75ZXxXaXvVaUNvPaq91A4bL0Mv7eA=; b=kUjHOSQuX7cek8jw9hGJkojju/frK7A8FNswSwQYV2uREaNjrWsyss67emw7iLjnkg KwuOcTvkooNY38Svwmq8Z8+S32djaViXC526StEGRlpq4K3SJY0PmXTYTUT5JtlQ7jbd mc3h7l/9S6KRZZR/67oW+pfXCyGu7GX9A5t96YQ2AsAq0wdT3OfMm/s9GKq2AitwuIVk 5IxQevCESerSGYLcBdvqjzrxr31d6uXLuVWutJgPH3NuU5EzrOopVRkrZ7yyw8asGsmK Gs3BGJ+dHmu3piZ11kNtI3vUI/dBfF0npmMyEjsrUwAzkFA3Pwz0V6BP5R7//DbvVqOB lFHg==
X-Received: by with SMTP id tj3mr5590960bkb.67.1368455592347; Mon, 13 May 2013 07:33:12 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id j8sm2298660bky.17.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 07:33:11 -0700 (PDT)
Message-ID: <>
Date: Mon, 13 May 2013 17:33:10 +0300
From: Emil Ivov <>
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: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkJdHDVBgz20JOwJyQiKhT07/0k04iU8UTegJRYwPRdBrEgqaSHRpVCfxyju/whU4DFHwHF
Cc: "" <>, "" <>, Paul Kyzivat <>
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:33:16 -0000

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.