Re: [rtcweb] JSEP/WebRTC API Datachannel question

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Sat, 17 May 2014 21:09 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14001A0066 for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 14:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.152
X-Spam-Level:
X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEkb0KQGYfjm for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 14:09:01 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647901A0225 for <rtcweb@ietf.org>; Sat, 17 May 2014 14:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2658; q=dns/txt; s=iport; t=1400360941; x=1401570541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bwcH3k9HdFP/Tgyc1OLC2Mbm6slxuGDoNYFuGcITQ8U=; b=c9NdbWjYrspI+V/gQD15t64pjc2C0SkCiR1DyjpdHvbfNnaV0Dtz6jpb VfErbfT+x96TvX1f3Gew/oo5BBgAk/gS/gcOn4uRGiY81Wq4G+YzS+de2 PxFpiSX3JIJLy5liTEB8ibb4SKiXOybQpH9lA77q9jh4HOlJg2qw1eKc7 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkHALfPd1OtJA2J/2dsb2JhbABZgwZPWKlECwEFBQGaKwGBCxZ0giUBAQEDATo4BwULAgEINhAyJQIEDgWIOQgN0QoXhVWISDMHgyuBFQSVXoN8gT2RXYM3bQGBQg
X-IronPort-AV: E=Sophos;i="4.98,859,1392163200"; d="scan'208";a="44745467"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 17 May 2014 21:08:45 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4HL8j7s002888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 May 2014 21:08:45 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Sat, 17 May 2014 16:08:45 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Christian Groves <Christian.Groves@nteczone.com>
Thread-Topic: [rtcweb] JSEP/WebRTC API Datachannel question
Thread-Index: AQHPchQv6jMSmyeTPU2ewK3QQ7DAKw==
Date: Sat, 17 May 2014 21:08:43 +0000
Message-ID: <A20898FE-B144-482D-BEF4-AC8AEBE90F9C@cisco.com>
References: <534616DC.7090800@nteczone.com> <534CC016.3020901@nteczone.com>
In-Reply-To: <534CC016.3020901@nteczone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.144.167]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0D31533E0331A744B3AE37BC4071B5EF@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sBmQOBWtuowGQaMSOKpweCgN6Sc
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP/WebRTC API Datachannel question
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 17 May 2014 21:09:09 -0000

On Apr 15, 2014, at 12:13 AM, Christian Groves <Christian.Groves@nteczone.com> wrote:

> I'll take a punt that people were thinking about 2 below when data channel was added. In order to clarify that I propose to add the following text to the JSEP draft to clarify this.
> 
> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1
> Replace:
> "Lastly, if a data channel has been created, a m= section MUST be
>   generated for data. The <media> field MUST be set to "application" and the <proto> field MUST be set to "DTLS/SCTP", as specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1."
> 
> With:
> /  "Lastly, if createDataChannel has been called a m= section MUST be generated for data. In the case of multiple createDataChannel calls only one m= section is generated. The <media> field MUST be set to "application" and the <proto> field MUST be set to "DTLS/SCTP", as specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1."/
> 
> New text in http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.2:
> (above last paragraph)
> / "If createDataChannel has been called and a m= section has not previously been generated, a m= section MUST be generated for data. In the case of multiple createDataChannel calls only one m= section is generated. The <media> field MUST be set to "application" and the <proto> field MUST be set to "DTLS/SCTP", as specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.//
> //
> //If all data channels have been closed, the m= section related to the data channels MUST be marked as recvonly by changing the value of the [RFC3264] directional attribute to "a=recvonly".//"/
> 
> It would also be good to add some text regarding the relationship between a createDataChannel and DCEP DATA_CHANNEL_OPEN I'm not sure if the JSEP draft is the place?
> 
> Also the W3C draft could be updated to indicate the interaction of a createDataChannel with the negotiationneeded event in section 5.2 something along the lines of:
> /7. For the first creation of a RTCDataChannel object fire a negotiationneeded event at connection./
> 
> 
> Regards,
> Christian

I probably need to think about this more but I think that sounds like a pretty reasonable change. One way or another, JSEP needs to be clear about what needs to happen here.