Re: [MMUSIC] SDPNEG: How to disable DCEP

"Roni Even (A)" <> Sun, 28 April 2019 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87A0C120123 for <>; Sun, 28 Apr 2019 07:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tsz3qDGfkyPb for <>; Sun, 28 Apr 2019 07:09:42 -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 2DB8E1200CC for <>; Sun, 28 Apr 2019 07:09:42 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id E23127F75936A2B7A367; Sun, 28 Apr 2019 15:09:39 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 28 Apr 2019 15:09:39 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sun, 28 Apr 2019 15:09:39 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Sun, 28 Apr 2019 15:09:38 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Sun, 28 Apr 2019 22:09:33 +0800
From: "Roni Even (A)" <>
To: Christer Holmberg <>, Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZLXhAAgAJOQoCAAF5/AIADFOtg///YYoCAAKhswA==
Date: Sun, 28 Apr 2019 14:09:33 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Sun, 28 Apr 2019 14:09:45 -0000


-----Original Message-----
From: Christer Holmberg [] 
Sent: Sunday, April 28, 2019 2:58 PM
To: Roni Even (A); Paul Kyzivat;
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP


> I think that sections 6.3 and 6.4 that discuss offer/answer say that dcmap is the indication of ruing non dcep.

Section 6.3 and 6.4 describe how to use dcmap.

I think it would be useful to e.g., have an Applicability section in the beginning of the document, that explicitly indicates that the procedures in the document apply when a data channel is negotiated using the dcmap attribute, and that DCEP is then not used.

RE: section 5 "This section defines two new SDP media-level attributes that can be
   used together with the SDP Offer/Answer mechanism to negotiate data
   channel-specific and subprotocol-specific parameters without the
   usage of DCEP".  if dcmap is rejected in the answer, the offerer can try dcep ( see my answer bellow)

But, what if an offerer wants to negotiate a data channel, before deciding what exactly it is going to be used for, but still wants to indicate usage of SDPNEG. Including an empty dcmap attribute?

RE: I do not see what is the use case, it does not help with the decision about whether out of band case is supported or not.

>    The example in section 7 say that if dcmap is rejected dcep may be negotiated.
>    Maybe this line form section 7 should be in section 6.4?

Normative text should definitely not be in Section 7.

RE: yes make sense to have it in section 6.5

However, if the answerer does not want to use SDPNEG, I think it's up to the offerer to decide whether to continue the session establishment, or fallback to DCEP. 



    -----Original Message-----
    From: mmusic [] On Behalf Of Paul Kyzivat
    Sent: Friday, April 26, 2019 6:16 PM
    To: Christer Holmberg;
    Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
    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.
    mmusic mailing list