Re: [rtcweb] JSEP/WebRTC API Datachannel question
Justin Uberti <juberti@google.com> Mon, 19 May 2014 04:17 UTC
Return-Path: <juberti@google.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 616351A022D for <rtcweb@ietfa.amsl.com>; Sun, 18 May 2014 21:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.829
X-Spam-Level:
X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
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 YUL6D4DTXmvU for <rtcweb@ietfa.amsl.com>; Sun, 18 May 2014 21:17:48 -0700 (PDT)
Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10F31A0008 for <rtcweb@ietf.org>; Sun, 18 May 2014 21:17:47 -0700 (PDT)
Received: by mail-ve0-f179.google.com with SMTP id oy12so5897440veb.10 for <rtcweb@ietf.org>; Sun, 18 May 2014 21:17:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IYI9rgbnlNLTjSloyTHOGg/GDqHelkgQZJX1twSzoiU=; b=b7tFNCyHjsmY8b6Mt2/Mx73lTSnZ/QZ6RE8Uhbr6ifFmdEJCURvKvQbk+ILHUuC1q5 wqDjXQeIHw7Os2WzwqcnVyZ99Lplym/i+rZXKpQXvyR18m690CZvvg68AOo0wJSEjUIP Q8dyltT57sJHlwPJEym8Q/EI3/72gtfDUX7uzV6WV8MixRLHGljdswH3H/Cc1KB8zsy6 zNlGdumZMt2X8CHpFK/vlge0Uw/QCUAIfwv90uaNigMsf972J5YVmHV9WEOEKAUTn+A2 OYYCJ1+eue0VwERDZWNscjvI+h1d5sQomXEUcto/AvsUoTTLBzCASLLNuoyNh39oUDbT Z/gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IYI9rgbnlNLTjSloyTHOGg/GDqHelkgQZJX1twSzoiU=; b=GvL9ZQ+gShO3I1QLkzUSt+MBYna2O+tC+AEzDnSl4hBlcLv728mq/kpKcqVtwk204a /n1LorWa7faCjAl42lRXJCa+VFGF5pY0cYZ1rVNFOHn2VW0bNNhf6Kc1r62z47TrFiC4 UqHfT6KqKNBWa23+aBohubo8CzB8x2IQSBbMQhtalYYfAM8AlO2rx/7VR+EbZ+Mw99e0 iwJU8N3abqfYw6fDc0uqGOMtnJdfcb5r8TLjcCOB3eyGUZXptaXAB5R6ntBV0Q6WOasD 75pYN68kmlQEC6ktnP6vPBs0rejEQsiUzCFJjjqqMBZ1M/GPU3Htkz3qYiHvSKkKG9XG aOLQ==
X-Gm-Message-State: ALoCoQl0vuQU3HId7TtYROvOEfKXM4l/Q3JrkTBwi9O6L8KgJnKXRkPqXDJQG7UO3DZ5BnTJ+Po6
X-Received: by 10.58.211.229 with SMTP id nf5mr28894876vec.19.1400473067295; Sun, 18 May 2014 21:17:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.145.105 with HTTP; Sun, 18 May 2014 21:17:27 -0700 (PDT)
In-Reply-To: <A20898FE-B144-482D-BEF4-AC8AEBE90F9C@cisco.com>
References: <534616DC.7090800@nteczone.com> <534CC016.3020901@nteczone.com> <A20898FE-B144-482D-BEF4-AC8AEBE90F9C@cisco.com>
From: Justin Uberti <juberti@google.com>
Date: Sun, 18 May 2014 21:17:27 -0700
Message-ID: <CAOJ7v-2YTyOQGd0=V-K=awx+XoMAVvO4ZQA2yNwg7AZSyFRz9A@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary="047d7bdc1824b1b96904f9b90baa"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TeDpfVpLwsM55aFRJJnozuElgZI
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: Mon, 19 May 2014 04:17:49 -0000
Agree it would be good to make it clear that there is only ever one m=data section; the text you suggest is a good start. I don't think we want to add a=recvonly on the data line; it's not clear that that attribute is well-defined for non-RTP media sections. On Sat, May 17, 2014 at 2:08 PM, Cullen Jennings (fluffy) <fluffy@cisco.com>wrote: > > 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. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] JSEP/WebRTC API Datachannel question Christian Groves
- Re: [rtcweb] JSEP/WebRTC API Datachannel question Christian Groves
- Re: [rtcweb] JSEP/WebRTC API Datachannel question Cullen Jennings (fluffy)
- Re: [rtcweb] JSEP/WebRTC API Datachannel question Justin Uberti
- Re: [rtcweb] JSEP/WebRTC API Datachannel question Randell Jesup