Subject: Re: [rtcweb] JSEP/WebRTC API Datachannel question

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 17 May 2014 21:08:43 +0000

On Apr 15, 2014, at 12:13 AM, Christian Groves <[email-masked]> 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.

---

From: Justin Uberti <[email-masked]>
Date: Sun, 18 May 2014 21:17:27 -0700

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)
<[email-masked]>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.
> >
> >   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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 May 2014 02:33:55 -0400

On 5/19/2014 12:17 AM, Justin Uberti wrote:
> 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.

Agree.  And agree we should specify the first createDataChannel() can 
cause a negotiationneeded event.

>
> 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.

Agree

> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     On Apr 15, 2014, at 12:13 AM, Christian Groves
>     <[email-masked]
>     <mailto:[email-masked]>> 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.
>     >
>     >   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
>     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:
>     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.
>

-- 
Randell Jesup -- rjesup a t mozilla d o t com