Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - glare question

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Dec 2017 13:50:44 +0000

Hi,

Section says:

 "If a peer receives an SDP offer before starting to send a new SDP offer
 with data channels that are to be SDP offer/answer negotiated, or
 loses an SDP offer glare resolution procedure in this case, it MUST
 wait until the ongoing SDP offer/answer completes before resuming the
 SDP offer/answer negotiation procedure."

Now, assuming I understand the text correctly, it simply repeats generic
O/A glare procedures.

Or, is there supposed to be something data channel specific?

Regards,

Christer

On 04/12/17 08:07, "mmusic on behalf of Roni Even"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi,
>
>This new revision addresses all nits pointed out by the idnits tool.
>As a new editor, I looked at the MMUSIC mail archive and as far as I can
>tell there were no open issues from the list.
>
>Thanks
>Roni Even
>
>
>-----Original Message-----
>From: mmusic [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: יום א 03 דצמבר 2017 18:28
>To: [email-masked]
>Cc: [email-masked]
>Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Multiparty Multimedia Session Control WG
>of the IETF.
>
>        Title           : SDP-based Data Channel Negotiation
>        Authors         : Keith Drage
>                          Maridi R. Makaraju
>                          Juergen Stoetzer-Bradler
>                          Richard Ejzak
>                          Jerome Marcon
>                          Roni Even
>	Filename        : draft-ietf-mmusic-data-channel-sdpneg-14.txt
>	Pages           : 41
>	Date            : 2017-12-03
>
>Abstract:
>   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
>   charged to provide protocols to support direct interactive rich
>   communications using audio, video, and data between two peers' web-
>   browsers.  For the support of data communication, the RTCWeb working
>   group has in particular defined the concept of bi-directional data
>   channels over SCTP (Stream Control Transmission Protocol), where each
>   data channel might be used to transport other protocols, called
>   subprotocols.  Data channel setup can be done using either the in-
>   band Data Channel Establishment Protocol (DCEP) or using some out-of-
>   band non-DCEP protocol.  This document specifies how the SDP (Session
>   Description Protocol) offer/answer exchange can be used to achieve
>   such an out-of-band non-DCEP negotiation.  Even though data channels
>   are designed for RTCWeb use initially, they may be used by other
>   protocols like, but not limited to, the CLUE protocol (which is
>   defined by the IETF "ControLling mUltiple streams for tElepresence"
>   working group).  This document is intended to be used wherever data
>   channels are used.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-14
>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpne
>g-14
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-14
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roni Even <[email-masked]>
Date: Mon, 4 Dec 2017 13:56:22 +0000

Hi Christer,
This looks to me like redundant text. 
Roni

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: יום ב 04 דצמבר 2017 15:51
> To: Roni Even; [email-masked]
> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-
> sdpneg-14.txt - glare question
> 
> Hi,
> 
> Section says:
> 
>  "If a peer receives an SDP offer before starting to send a new SDP offer  with
> data channels that are to be SDP offer/answer negotiated, or  loses an SDP
> offer glare resolution procedure in this case, it MUST  wait until the ongoing
> SDP offer/answer completes before resuming the  SDP offer/answer
> negotiation procedure."
> 
> 
> Now, assuming I understand the text correctly, it simply repeats generic O/A
> glare procedures.
> 
> >As a new editor, I looked at the MMUSIC mail archive and as far as I
> >can tell there were no open issues from the list.
> >
> >Thanks
> >Roni Even
> >
> >
> >Subject: [MMUSIC] I-D Action:
> >draft-ietf-mmusic-data-channel-sdpneg-14.txt
> >
> >
> >This draft is a work item of the Multiparty Multimedia Session Control
> >WG of the IETF.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Dec 2017 13:59:27 +0000

Hi,

The draft also repeats “data channel with Offer/Answer” many times. I
think it is enough to say once that the procedures are for negotiating
data channels using offer/answer. No need to keep repeating it…

Regards,

Christer