Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling

Stefan Håkansson <> Wed, 19 October 2011 07:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F09021F8678 for <>; Wed, 19 Oct 2011 00:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1YzLl1UIPQDf for <>; Wed, 19 Oct 2011 00:41:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5FA1A21F8677 for <>; Wed, 19 Oct 2011 00:41:27 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-ba-4e9e7f26ce1c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F7.6A.20773.62F7E9E4; Wed, 19 Oct 2011 09:41:26 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 19 Oct 2011 09:41:25 +0200
Message-ID: <>
Date: Wed, 19 Oct 2011 09:41:24 +0200
From: Stefan Håkansson <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
References: <> <> <> <> <AAE428925197FE46A5F94ED6643478FEA92569D512@HE111644.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <AAE428925197FE46A5F94ED6643478FEA92569D512@HE111644.EMEA1.CDS.T-INTERNAL.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Oct 2011 07:41:28 -0000

Speaking strictly as an individual (I'm in the same organization as 
Magnus, so if that means that this input has less weight so be it):

I think this discussion got a bit off track.

In the ROAP draft glaring is resolved by backing off and waiting in the 
order of seconds.

Magnus proposes another solution that resolves glaring immediately (no 
need to wait). I think this is a really good idea, especially in the 
light of that the current API proposal allows each endpoint to 
asynchronously add streams (for transmission to the other endpoint) at 
any time. This means that glaring conditions could be quite common.

Why should we design something that delays the start of those streams 
quite some time when it easily can be avoided?

Then there could (or not) be situations where the back-off resolution 
does not work at all, but I think a more efficient glaring resolution 
mechanism makes sense regardless.

(NB: If there are other ways to resolve glaring without delay I'm all 
for it, I just want to avoid that glaring would delay steam set up 


On 10/18/2011 05:56 PM, wrote:
> Ekr wrote:
>> I'm not sure I agree with this. 2-5 seconds isn't really that long to
>> wait for the interval between the caller starting the call and the callee being alerted.
> I consider 2-5 s a quite horrible call setup time, and I can tell that customers really care about it. Of course it's acceptable if such a long setup delay only occurs occasionally.
> Wolfgang Beck
> Deutsche Telekom Netzproduktion GmbH
> Fixed Mobile Engineering Deutschland
> Wolfgang Beck
> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
> +49 6151 628 2832 (Tel.)
> Erleben, was verbindet.
> Deutsche Telekom Netzproduktion GmbH
> Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
> Handelsregister: Amtsgericht Bonn HRB 14190
> Sitz der Gesellschaft Bonn
> USt-IdNr. DE 814645262
> Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.
> _______________________________________________
> rtcweb mailing list