Re: [MMUSIC] SDPNEG: How to disable DCEP

Paul Kyzivat <> Fri, 26 April 2019 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AE201205CB for <>; Fri, 26 Apr 2019 08:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WHKlydyHFlMb for <>; Fri, 26 Apr 2019 08:16:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 968731204B2 for <>; Fri, 26 Apr 2019 08:15:56 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain ( []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x3QFFq4t014355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Apr 2019 11:15:52 -0400
To: Christer Holmberg <>, "" <>
References: <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Fri, 26 Apr 2019 11:15:52 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Apr 2019 15:16:37 -0000

On 4/26/19 5:37 AM, Christer Holmberg wrote:
> Hi Paul,
> So, what is your suggestion? __

It looks to me like the 2nd paragraph of Appendix A is the right place 
for this:

    A WebRTC application creates a data channel by providing a number of
    setup parameters (subprotocol, label, maximal number of
    retransmissions, maximal retransmission time, order of delivery,
    priority).  The application also specifies if it wants to make use of
    the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if
    the application intends to negotiate data channels using the SDP
    offer/answer protocol.

I'm inclined to tweak the above as follows:

    the application intends to negotiate data channels using the SDP
    offer/answer protocol, or both.

And then, the note at the end of the section can be augmented:

    Note: The above SDP media description does not contain any channel-
    specific information. If data channels are to be negotiated using
    SDP, then the above will be supplemented as specified in Sections
    6.3 and 6.4.

But I'm not sure about "The application also specifies...". Is this 
referring to something specific in the webrtc API? If so, does it permit 
both? The presence of dcmap in the SDP will indicate the intent to use 
SDP negotiation, but must this first be enabled in the API?


> Regards,
> Christer
> ´╗┐On 25/04/2019, 1.25, "mmusic on behalf of Paul Kyzivat" < on behalf of> wrote:
>      The distribution of specs across multiple documents makes it really
>      fuzzy what is normative for what.
>      Perhaps something should be said about the validity of using a
>      webrtc-datachannel media stream for establishing data channels via SDP
>      with dcmap and/or DCEP. I don't think this is said anywhere else.