Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

Richard Ejzak <> Mon, 24 February 2014 14:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1A1E61A002D for <>; Mon, 24 Feb 2014 06:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3_iJwRZ0PQOB for <>; Mon, 24 Feb 2014 06:58:32 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::235]) by (Postfix) with ESMTP id B8BD01A0011 for <>; Mon, 24 Feb 2014 06:58:31 -0800 (PST)
Received: by with SMTP id e16so5821446lan.40 for <>; Mon, 24 Feb 2014 06:58:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5uRILwZ/Zwf4ZKN24PqAcs7M/ew+e8oQlCJrWVN2c3M=; b=xSROo0UAFJ5zjUC7/WZU9yPGYWgcSGgdJw0xf0qiUHPZziyDDRKASJyTKNr1ZowHZB HZYBX6p5kc6xSkMB04Xq8a3Ihp+vp8nYdLBq1EuIzzLszdCtOE19XVAHPsf4uf7Jj/qT e2RqwpZU+/fh23zte1mN0nxdXm54JXKRT2vs4evj25Fv1H0sfyZHeAoyLKKbxcMOov30 N8uZTysivEBiHrddCYyV8uJeZNrVuQfIUfBTyDslKqmDs6zYbrhWCC0aYFVdVCGSE+z9 Pw1NSya5YuLmGk3gZWkFQr2+WfGNQp+qFnEshN/JwyHNmQp5DTkFnjYNhkL3v2lg/fkx WphQ==
MIME-Version: 1.0
X-Received: by with SMTP id 3mr12497831lai.58.1393253910506; Mon, 24 Feb 2014 06:58:30 -0800 (PST)
Received: by with HTTP; Mon, 24 Feb 2014 06:58:30 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 24 Feb 2014 08:58:30 -0600
Message-ID: <>
From: Richard Ejzak <>
To: Christer Holmberg <>
Content-Type: multipart/alternative; boundary="089e013c6ae46aef8f04f32834ed"
Cc: "" <>
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
X-Mailman-Version: 2.1.15
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: Mon, 24 Feb 2014 14:58:34 -0000

On Mon, Feb 24, 2014 at 8:18 AM, Christer Holmberg <> wrote:

> Hi,
> >> Q2:
> >>
> >> Would it be possible, for subprotocol values, use the same IANA
> registry/values as for the WebRTC Data Channel Protocol?
> >
> > This is really more a question for the data channel design itself.  A
> decision has been made to use the PPID for framing rather than protocol
> identification.  There is some discussion of this in another thread.
> I am not talking about the PPID - I am talking about the Protocol field in
> the DATA_CHANNEL_OPEN message, which (afaik) specifies the same thing as
> the subprotocol parameter in your draft.

This issue did come up in another thread, and the answer is yes.  It should
probably be documented in the core data channel specs and just referenced

> >> Q3:
> >>
> >> It would be good to clarify, if only one data channel is requested (or,
> even required), that the stream value must be the same in the Offer and
> Answer.
> >
> > I thought this also came up in an earlier thread and that it is
> documented (or should be documented) in the core data channel docs.  My
> understanding is that the stream id is always the same in both directions
> for a particular data channel.
> Correct. But, there should be an Offer/Answer procedure section in your
> draft, which shall say that the stream number must be the same. You can
> then reference to the data channel doc for justification.

Since there is no disagreement over how it should work, we can clarify as
necessary in a subsequent draft.

> >> Q4:
> >>
> >> I have issues with the max_retr, max_time and unordered parameters.
> >>
> >> First, they seem to specify SENDING capabilities, rather than RECEIVING
> capabilities.
> >>
> >> Second, they seem to describe characteristics associated with the
> subprotocol, in which case they could be specified in the associated
> subprotocol specification.
> >
> > This should be a topic for discussion in London.  As it is currently
> written, these parameters are of the "take it or leave it" variety, i.e.,
> the answerer either accepts the options listed
> > in the offer or rejects the data channel outright.  This is true for the
> in-band control protocol (please correct me if I am wrong on this), so we
> adopted the same approach for the
> > SDP-negotiated case.  Some have suggested that we should allow more
> flexibility in negotiation of these parameters when using SDP.  If there is
> general agreement that it should be
> > done this way, I see no problem with defining parameter negotiation
> rules for SDP in the next version of the draft.
> The difference is that your draft is based on Offer/Answer, which is about
> indicating receiving capabilities (yes, I know we have broken that rule in
> the past).

There are many examples of attributes that use different negotiation models
than this.  The only requirement is that the semantics of the negotiation
be defined in the document defining the attribute.

BR, Richard