IETF Logo Mail Archive

Re: [rtcweb] DataChannels API and external negotiation

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 01 April 2013 09:38 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 04AA221F88D6 for <rtcweb@ietfa.amsl.com>; Mon, 1 Apr 2013 02:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Rn6Oyp7JAdf6 for <rtcweb@ietfa.amsl.com>; Mon, 1 Apr 2013 02:38:36 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DB3F121F8700 for <rtcweb@ietf.org>; Mon, 1 Apr 2013 02:38:30 -0700 (PDT)
Received: from [192.168.1.102] (p5481843E.dip0.t-ipconnect.de [84.129.132.62]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7FB921C0C069B; Mon, 1 Apr 2013 11:38:27 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CAKfGGh1kBajiFFNknf5HtV2GF=wi7pGm6sbwiJhLFsmwhLecuQ@mail.gmail.com>
Date: Mon, 01 Apr 2013 11:38:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E629AF4F-FA49-46FE-A677-684F4CC80454@lurchi.franken.de>
References: <5158F0FC.3070104@jesup.org> <CAKfGGh1kBajiFFNknf5HtV2GF=wi7pGm6sbwiJhLFsmwhLecuQ@mail.gmail.com>
To: piranna@gmail.com
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] DataChannels API and external negotiation
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: Mon, 01 Apr 2013 09:38:37 -0000

On Apr 1, 2013, at 10:15 AM, piranna@gmail.com wrote:

>> /* If either maxRetransmitTime or maxRetransmitNum are set, it's
>>   unreliable, else it's a reliable channel.  If both are set it's an
>>   error.
> 
> I don't think so (except if it's a limitation of SCTP that I didn't
> know, so this message is useless). I think it would make sense to be
> able to set both maxRetransmitTime and maxRetransmitNum at the same
> time, only that since they are maximus limits it would be effective
> the first to be reached.
SCTP allows setting a single PR-SCTP policy packet. Supported ones are
limiting the number of retransmissions and time to live. Not a combination
of both. That is why you are only providing a single PR-SCTP value.

If you want to limit both, you need to define a new PR-SCTP policy. That
policy would also require two parameters (the number of retransmissions and
the time to live in ms) as parameters, not only one as we have currently.

So without defining a new PR-SCTP policy, the above text is correct.

Best regards
Michael
> 
> 
> 
> --
> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
> monton de sitios diferentes, simplemente escribe un sistema operativo
> Unix."
> – Linus Tordvals, creador del sistema operativo Linux
> 
>

v2.23.0 | Report a Bug | By Email