Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-18.txt

From: [email-masked]
Date: Tue, 01 May 2018 07:27:49 -0700

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-18.txt
	Pages           : 41
	Date            : 2018-05-01

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-18
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-18

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/

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 May 2018 13:41:21 +0000

Hi Roni,

The text seems to assume that all data channels will be opened in the same
offer, called the initial offer.

However, we need to keep in mind that one can open data channel X in one
offer, and data channel Y in another offer, which means that a given offer
can be initial for one data channel, but subsequent for another data
channel (that was previously established).

Therefore, you need to say that the O/A procedures are for any given data
channel (identified by its dcmap-stream-id value), and that ³initial²
refers to when that given data channel is created.

So, for example, in section 6.3 you would only talk about the data channel
that is created.

Something like:

----

6.3.  Generating Initial Offer

When an offerer sends in initial offer, in order to create a new data
channel,
it shall include the following information in the m= section used for the
data channels:

- Include an SDP dcmap-strem-id attribute, with an attribute value
associated with the data channel; and

- Include SDP decamp and dcsa attributes for the data channel.

...

Regards,

Christer

On 01/05/18 17:27, "mmusic on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bo Burman <[email-masked]>
Date: Wed, 2 May 2018 15:46:12 +0000

Hi,

I basically agree with Christer that it would be good to make this distinction in what qualifies as "initial".
There's however no "dcmap-stream-id" attribute. That is rather the ABNF name of the first parameter on the "a=dcmap:" line. So, I instead suggest to change the text to:

----

When an offerer sends in initial offer, in order to create a new data channel, it SHALL include the following information in
the m= section used for the data channels:

- Include an SDP dcmap attribute for the new data channel, with a new, associated dcmap-stream-id attribute value
- In addition, it MAY include SDP dcsa attributes for the new data channel, using a stream-id attribute value identical to the dcmap-stream-id value used for the corresponding SDP dcmap attribute

....

/Bo (as individual)

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: den 2 maj 2018 15:41
> To: Roni Even <[email-masked]>; [email-masked]
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-18.txt
> 
> Hi Roni,
> 
> The text seems to assume that all data channels will be opened in the same offer, called the initial offer.
> 
> However, we need to keep in mind that one can open data channel X in one offer, and data channel Y in another offer,
> which means that a given offer can be initial for one data channel, but subsequent for another data channel (that was
> previously established).
> 
> Therefore, you need to say that the O/A procedures are for any given data channel (identified by its dcmap-stream-id
> value), and that ³initial² refers to when that given data channel is created.
> 
> So, for example, in section 6.3 you would only talk about the data channel that is created.
> 
> Something like:
> 
> ----
> 
> When an offerer sends in initial offer, in order to create a new data channel, it shall include the following information in
> the m= section used for the data channels:
> 
> - Include an SDP dcmap-strem-id attribute, with an attribute value associated with the data channel; and
> 
> ....
> >https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sd
> >pne
> >g-18
> >
> >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.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 May 2018 18:43:50 +0000

Hi,

> There's however no "dcmap-stream-id" attribute. That is rather the ABNF name of the first parameter on 
> the "a=dcmap:" line. So, I instead suggest to change the text to:
>
> ----
>
> When an offerer sends in initial offer, in order to create a new data channel, it SHALL include the following information in the m= section used for the data channels:
>

I don't think we should have SHALL, followed by MAY. So, perhaps:

When an offerer sends in initial offer, in order to add a new data channel to an m= section used for the data channels, it: 

- SHALL include an SDP dcmap attribute for the new data channel, with a new, associated dcmap-stream-id attribute value; and
- MAY include one or more SDP dcsa attributes for the new data channel, using a stream-id attribute value identical to the dcmap-stream-id value used for the 
  corresponding SDP dcmap attribute
...

This also means that section 6.6.1 can be removed.

Regarding section 6.6, I suggest to rename it (to be consistent with the O/A procedures in other specs), and then say something like:

---

6.6.  Modifying The Session

   When an offer sends a subsequent offer, that includes information for a previously created data channel, unless the offerer 
   intends to close the data channel (Section 6.6.1), the offerer SHALL include the previously negotiated SDP attributes and values
   associated with the data channel.

6.6.1.  Closing a Data Channel

   In order to close a data channel, the data channel stack performs an
   SCTP SSN reset [RFC6525] for the channel. The SCTP SSN resets
   The Stream Sequence Number of the associated stream back to zero.

   It is specific to the subprotocol whether this data channel will be
   closed or will be re-used by a new Offer/Answer Exchange exchange.
   [Christer: What does the sentence above mean? Is it whether the *stream* will be re-used?]

   Before the SCTP SSN reset is sent, in order to signal the intention to 
   close the the data channel, the offerer sends a subsequent offer, in which
   the offerer SHALL exclude the SDP dcmap attribute, and any SDP dcsa attributes, 
   associated with the data channel. The offerer SHOULD NOT close the data
   channel until it receives a successful answer to the subsequent offer.

   NOTE: The reason for waiting for a successful answer before the data channel is closed is 
   in order to handle cases where a successful SDP answer is not received, in which case the state
   of the data channel can be kept unchanged.

   NOTE: Setting the port value of the m= section to zero would disable the 
   SCTP association used to implement each data channel.

   If a client receives a data channel close indication from the peer (e.g., a  SCTP SSN reset,
   or by other means) without associated subsequent offer, then the client SHOULD 
   generate a subsequent offer in order to close the data channel, following the procedures 
   in this section.

   If an offerer sends a subsequent offer that contains the SDP dcmap attribute, and any SDP dcsa attributes,
   associated with a data channel, and if the attributes are not present in the associated answer, then the offerer
   SHOULD generate a subsequent offer in order to close the data channel, following the procedures 
   in this section.
   [Christer: I think this case is currently not covered in the draft]

   If a client receives a data channel close indication from the peer (e.g., a  SCTP SSN reset,
   or by other means) without associated subsequent offer, then the client SHOULD 
   generate a subsequent offer in order to close the data channel, following the procedures 
   in this section.

   If the answerer accepts the SDP
   offer then the answerer MUST close those data channels whose
   "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the
   received SDP offer, unless those data channels were already closed,
   and the answerer MUST also exclude the corresponding attribute lines
   in the answer.  In addition to that, the SDP answerer MAY exclude
   other data channels which were closed but not yet communicated to the
   peer.  So, the offerer MUST inspect the answer to see if it has to
   close other data channels that are now not included in the answer.
   [Christer: The paragraph above belongs to the 'Generating' answer section]

   The application MUST also close any data channel that was negotiated
   via SDP offer/answer, for which the stream identifiers are not listed
   in an incoming SDP offer.
   [Christer: Not sure why this text is needed?]

   A closed data channel using local close (SCTP SSN reset), without an
   additional SDP offer/answer to close it, may be reused for a new data
   channel.  This MUST be done via new SDP offer/answer, describing the
   new subprotocol and its attributes, only after the corresponding data
   channel close acknowledgment is received from the peer (i.e.  SCTP
   SSN reset of both incoming and outgoing streams is completed).  This
   restriction is to avoid the race conditions between arrival of "SDP
   offer which reuses stream" with "SCTP SSN reset which closes outgoing
   stream" at the peer. 
   [Christer: I don't understand this. Prior the text says that an SCTP SSN
   reset without an associated offer SHOULD trigger an offer to close
   the data channel.

   If the offer or the answer do not include any "a=dcmap" attributes
   all the SDP offer/answer negotiated data channels are expected to be
   closed now.  The DTLS/SCTP association remains open for new SDP
   offer/answer or DCEP negotiation of data channels.
   [Christer: Not sure why this is needed.]

Finally, as I commented earlier, we don't need statements like "sends the answer","applies the answer" etc. That is implicit. You don't generate an offer or answer unless you intend to send it :)

Regards,

Christer

> Subject: Re: [MMUSIC] I-D Action: 
> draft-ietf-mmusic-data-channel-sdpneg-18.txt
> 
> Hi Roni,
> 
> However, we need to keep in mind that one can open data channel X in 
> one offer, and data channel Y in another offer, which means that a 
> given offer can be initial for one data channel, but subsequent for another data channel (that was previously established).
> 
> Therefore, you need to say that the O/A procedures are for any given 
> data channel (identified by its dcmap-stream-id value), and that ³initial² refers to when that given data channel is created.
> 
> channel, it shall include the following information in the m= section used for the data channels:
> 
> >https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpn
> >eg
> >-18
> >
> >

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 3 May 2018 05:11:58 +0000

Hi guys,
I am OK with your proposal. I was going to comment that 6.6.1 talks about adding a data channel.

Roni

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, May 02, 2018 9:44 PM
To: Bo Burman; Roni Even; [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-18.txt

Hi,

> There's however no "dcmap-stream-id" attribute. That is rather the 
> ABNF name of the first parameter on the "a=dcmap:" line. So, I instead suggest to change the text to:
>
> ----
>
> - Include an SDP dcmap attribute for the new data channel, with a new, 
> associated dcmap-stream-id attribute value

---

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 May 2018 07:11:21 +0000

Hi Roni,

Not that we proposal did not cover the whole O/A section. The answerer
procedures also need to be modified.

Also note that I included some questions ([Christer: <question text>]) in
the text below.

I would suggest that you provide the updated text (in an e-mail, or using
a pull request), before submitting a new version of the draft.

Regards,

Christer

On 03/05/18 08:11, "Roni Even (A)" <[email-masked]> wrote:

>> I basically agree with Christer that it would be good to make this
>>distinction in what qualifies as "initial".
>>
>>channel, it SHALL include the following information in the m= section
>>used for the data channels:
>>
>> - In addition, it MAY include SDP dcsa attributes for the new data
>>channel, using a stream-id attribute value identical to the
>>dcmap-stream-id value used for the
>When an offerer sends in initial offer, in order to add a new data
>channel to an m= section used for the data channels, it:
>
>- SHALL include an SDP dcmap attribute for the new data channel, with a
>new, associated dcmap-stream-id attribute value; and
>- MAY include one or more SDP dcsa attributes for the new data channel,
>using a stream-id attribute value identical to the dcmap-stream-id value
>used for the
>Regarding section 6.6, I suggest to rename it (to be consistent with the
>O/A procedures in other specs), and then say something like:
>
>---
>
>   When an offer sends a subsequent offer, that includes information for
>a previously created data channel, unless the offerer
>   intends to close the data channel (Section 6.6.1), the offerer SHALL
>include the previously negotiated SDP attributes and values
>   associated with a data channel, and if the attributes are not present
>in the associated answer, then the offerer
>Finally, as I commented earlier, we don't need statements like "sends the
>answer","applies the answer" etc. That is implicit. You don't generate an
>offer or answer unless you intend to send it :)
>
>Regards,
>
>Christer
>
>> given offer can be initial for one data channel, but subsequent for
>>another data channel (that was previously established).
>> 
>> data channel (identified by its dcmap-stream-id value), and that
>>³initial² refers to when that given data channel is created.
>>

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 3 May 2018 08:31:06 +0000

Hi Christer,
See inline on section 6.3 and 6.6

As for closing the data channel or re-using I am not sure we are clear on the process.   In draft-ietf-rtcweb-data-channel-13 the data channel is closed by the "SCTP SSN reset" (one side sends and waits to receive SCTP SSN reset from the other side)  this resets the SSN to zero and it can be re-used by sending a new DATA_CHANNEL_OPEN Message in the channel with the stream ID that was reset.

Here we have SCTP SSN reset and SDP . So we need to be clear what is a channel close when the signaling is out of band. I assume that we will need both the SCTP SSN reset and an SDP offer/answer exchange which  will either remove the dcmap with the relevant dcmap-stream-id or have it with new subprotocol. I think that in order for it to work the process should be that to close the channel a SCTP SSN reset MUST be sent and the client sending the reset MUST stop sending data in this data channel and wait for SCTP SSN reset from the other side on the same dcmap-stream-id. Now the data channel will not be used for sending data.  After receiving the SCTP SSN reset the side who originated the close MUST send a new SDP offer removing the dcmap with the dcmap-stream-id or change the subprotocol in the existing SDP. The decision if to re-use or close is application dependent. (I assume that the re-use can be by any side of the data channel (section 6.1) and not only the side that originally created it since there is no issue with collision.)

Does this make sense?

Regards
Roni

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, May 03, 2018 10:11 AM
To: Roni Even (A); Bo Burman; Roni Even; [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-18.txt

Hi Roni,

Not that we proposal did not cover the whole O/A section. The answerer procedures also need to be modified.

Also note that I included some questions ([Christer: <question text>]) in the text below.

I would suggest that you provide the updated text (in an e-mail, or using a pull request), before submitting a new version of the draft.

Regards,

Christer

<RE>I will put the above text as section 6.3 and add reference to section 5 and 6.1 and 6.2 where relevent and remove 6.6.1 my proposed text for section 6.3

"When an offerer sends in initial offer, in order to add a new data channel to an m= section used for the data channels, it: 
- SHALL include an SDP dcmap attribute (section 5 and section 6.2) for the new data channel, with a new, associated dcmap-stream-id attribute value using stream identifiers from the owned set (see Section 6.1).  Note that the UDP/DTLS/SCTP association may have been negotiated previously; and
- MAY include one or more SDP dcsa attributes (section 5) for the new data channel, using a stream-id attribute value identical to the dcmap-stream-id value used for the
  corresponding SDP dcmap attribute"

---

<RE> OK

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 May 2018 09:19:43 +0000

Hi,

> As for closing the data channel or re-using I am not sure we are clear
>on the process. In draft-ietf-rtcweb-data-channel-13 the data channel is
> closed by the "SCTP SSN reset" (one side sends and waits to receive SCTP
>SSN reset from the other side) this resets the SSN to zero and it can<
> be re-used by sending a new DATA_CHANNEL_OPEN Message in the channel
>with the stream ID that was reset.

Correct.

> Here we have SCTP SSN reset and SDP. So we need to be clear what is a
>channel close when the signaling is out of band. I assume that we will
>need
> both the SCTP SSN reset and an SDP offer/answer exchange which will
>either remove the dcmap with the relevant dcmap-stream-id or have it with
>new 
> subprotocol. I think that in order for it to work the process should be
>that to close the channel a SCTP SSN reset MUST be sent and the client
>sending 
> the reset MUST stop sending data in this data channel and wait for SCTP
>SSN reset from the other side on the same dcmap-stream-id. Now the data
>channel
> will not be used for sending data. After receiving the SCTP SSN reset
>the side who originated the close MUST send a new SDP offer removing the
>decamp with
> the dcmap-stream-id or change the subprotocol in the existing SDP. The
>decision if to re-use or close is application dependent. (I assume that
>the re-use 
> can be by any side of the data channel (section 6.1) and not only the
>side that originally created it since there is no issue with collision.)
>
> Does this make sense?

My suggestion would be (perhaps it¹s what you also have in mind :)

- When the channel is closed, you FIRST send an O/A excluding the dcmap
attribute associated with the data channel.
- If you later want to open a new data channel, with the same stream ID,
that¹s ok. Then you send ANOTHER offer to do that.
- BUT, I don¹t think we should allow the case where you in a single offer
change the sub-protocol from one thing to another. I think there shall be
separate offers for closing the data channel and opening a new one - even
if the stream ID is the same.

Regards,

Christer

><RE>I will put the above text as section 6.3 and add reference to section
>5 and 6.1 and 6.2 where relevent and remove 6.6.1 my proposed text for
>section 6.3
>
>"When an offerer sends in initial offer, in order to add a new data
>- SHALL include an SDP dcmap attribute (section 5 and section 6.2) for
>the new data channel, with a new, associated dcmap-stream-id attribute
>value using stream identifiers from the owned set (see Section 6.1).
>Note that the UDP/DTLS/SCTP association may have been negotiated
>previously; and
>- MAY include one or more SDP dcsa attributes (section 5) for the new
>data channel, using a stream-id attribute value identical to the

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 3 May 2018 09:26:10 +0000

Hi,

Hi,

>on the process. In draft-ietf-rtcweb-data-channel-13 the data channel 
>is  closed by the "SCTP SSN reset" (one side sends and waits to receive 
>SCTP SSN reset from the other side) this resets the SSN to zero and it 
>can<  be re-used by sending a new DATA_CHANNEL_OPEN Message in the 
>channel with the stream ID that was reset.

Correct.

>need  both the SCTP SSN reset and an SDP offer/answer exchange which 
>will either remove the dcmap with the relevant dcmap-stream-id or have 
>it with new  subprotocol. I think that in order for it to work the 
>process should be that to close the channel a SCTP SSN reset MUST be 
>sent and the client sending  the reset MUST stop sending data in this 
>data channel and wait for SCTP SSN reset from the other side on the 
>same dcmap-stream-id. Now the data channel  will not be used for 
>sending data. After receiving the SCTP SSN reset the side who 
>originated the close MUST send a new SDP offer removing the decamp with  
>the re-use  can be by any side of the data channel (section 6.1) and 
>not only the side that originally created it since there is no issue 
>with collision.)
>
> Does this make sense?

- When the channel is closed, you FIRST send an O/A excluding the dcmap attribute associated with the data channel.
- If you later want to open a new data channel, with the same stream ID, that¹s ok. Then you send ANOTHER offer to do that.
- BUT, I don¹t think we should allow the case where you in a single offer change the sub-protocol from one thing to another. I think there shall be separate offers for closing the data channel and opening a new one - even if the stream ID is the same.

<RE> Since after the SCTP SSN reset exchange the channel is idle I assumed that we do not need to do two offer answers to re-use but I do not have a strong view here. 
Basically if both direction of the channels are reset you can change the subprotocol in the first offer. 
If you think it is better to do a full close SCTP SSN reset and offer answer removing the stream-id before reuse I am OK

Regards,

Christer

>I would suggest that you provide the updated text (in an e-mail, or 
>using a pull request), before submitting a new version of the draft.
>
>Regards,
>
>Christer
>
>
>
>using a stream-id attribute value identical to the dcmap-stream-id 
>value used for the
>Regarding section 6.6, I suggest to rename it (to be consistent with 
>the O/A procedures in other specs), and then say something like:
>
>---
>
>   When an offer sends a subsequent offer, that includes information 
>for a previously created data channel, unless the offerer
>Finally, as I commented earlier, we don't need statements like "sends 
>the answer","applies the answer" etc. That is implicit. You don't 
>generate an offer or answer unless you intend to send it :)

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 May 2018 09:33:55 +0000

Hi,

><RE> Since after the SCTP SSN reset exchange the channel is idle I
>assumed that we do not need to do two offer answers to re-use but I do
>not have a strong view here.
>If you think it is better to do a full close SCTP SSN reset and offer
>answer removing the stream-id before reuse I am OK

I don’t have any strong feeling. If people want to immediately send a new
offer with a new sub-protocol we can do that - as long as we document it
properly.

But, I do NOT think it should be sub-protocol specific (as indicated in
the second paragraph of section 6.6.2) whether it’s allowed or not -
whatever approach we take it should be a generic feature.

Regards,

Christer

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 3 May 2018 09:40:47 +0000

Hi,

>> As for closing the data channel or re-using I am not sure we are 
>>clear on the process. In draft-ietf-rtcweb-data-channel-13 the data 
>>channel is  closed by the "SCTP SSN reset" (one side sends and waits 
>>to receive SCTP SSN reset from the other side) this resets the SSN to 
>>zero and it can<  be re-used by sending a new DATA_CHANNEL_OPEN 
>>Message in the channel with the stream ID that was reset.
>
>Correct.
>
>>originated the close MUST send a new SDP offer removing the decamp 
>>with the dcmap-stream-id or change the subprotocol in the existing 
>>SDP. The decision if to re-use or close is application dependent. (I 
>>assume that the re-use  can be by any side of the data channel 
>>(section 6.1) and not only the side that originally created it since 
>>there is no issue with collision.)
>>
>> Does this make sense?
>
>- If you later want to open a new data channel, with the same stream 
>ID, that¹s ok. Then you send ANOTHER offer to do that.
>- BUT, I don¹t think we should allow the case where you in a single 
>offer change the sub-protocol from one thing to another. I think there 
>shall be separate offers for closing the data channel and opening a new 
>one - even if the stream ID is the same.
>

I don't have any strong feeling. If people want to immediately send a new offer with a new sub-protocol we can do that - as long as we document it properly.

But, I do NOT think it should be sub-protocol specific (as indicated in the second paragraph of section 6.6.2) whether it's allowed or not - whatever approach we take it should be a generic feature.
<RE> I agree, the new offer after the SCTP SSN reset exchange is a reset to the channel and the new offer re-open it with any new parameters but with SSN=0. If this is OK with you I will draft new text for section 6.6.2

Regards,

Christer

>>- SHALL include an SDP dcmap attribute for the new data channel, with 
>>a new, associated dcmap-stream-id attribute value; and
>>- MAY include one or more SDP dcsa attributes for the new data 
>>   intends to close the data channel (Section 6.6.1), the offerer 
>>SHALL include the previously negotiated SDP attributes and values

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 May 2018 10:23:18 +0000

Hi,

>>>zero and it can  be re-used by sending a new DATA_CHANNEL_OPEN 
>>>it with new  sub protocol. I think that in order for it to work the 
>> I don't have any strong feeling. If people want to immediately send a new offer with
>> a new sub-protocol we can do that - as long as we document it properly.
>>
>> But, I do NOT think it should be sub-protocol specific (as indicated in the second paragraph of 
>> section 6.6.2) whether it's allowed or not - whatever approach we take it should be a generic feature.
>
> <RE> I agree, the new offer after the SCTP SSN reset exchange is a reset to the channel and the new 
> offer re-open it with any new parameters but with SSN=0. If this is OK with you I will draft new text for section 6.6.2

A little more on this:

According to the procedures, the subsequent offer used to indicate that the channel will be closed is sent BEFORE the SCTP SSN. So, in my opinion it would be weird to indicate a new sub protocol in this offer, as the data channel is still active.

So, in my opinion a new sub protocol should not be indicated until the SCTP SSN has been received - which means it would be in a separate offer.

Example:

A                                                   B

<----- data channel sID=1 ------>

<----- O/A close channel ------->

<----- SCTP SSN ------------------->

< ----- O/A add channel -------->

< ----- data channel sID=1 -----> 

Regards,

Christer

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 3 May 2018 10:38:18 +0000

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, May 03, 2018 1:23 PM
To: Roni Even (A); Bo Burman; Roni Even; [email-masked]
Subject: RE: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-18.txt

Hi,

>>> Here we have SCTP SSN reset and SDP. So we need to be clear what is 
>>>a channel close when the signaling is out of band. I assume that we 
>>>will need  both the SCTP SSN reset and an SDP offer/answer exchange 
>>>which will either remove the dcmap with the relevant dcmap-stream-id 
>>>or have it with new  sub protocol. I think that in order for it to 
>>>work the process should be that to close the channel a SCTP SSN reset 
>>>MUST be sent and the client sending  the reset MUST stop sending data 
>>>in this data channel and wait for SCTP SSN reset from the other side 
>>>on the same dcmap-stream-id. Now the data channel  will not be used 
>>>for sending data. After receiving the SCTP SSN reset the side who 
>>- When the channel is closed, you FIRST send an O/A excluding the 
>>dcmap attribute associated with the data channel.
>>shall be separate offers for closing the data channel and opening a 
>>new one - even if the stream ID is the same.
>>
>>>assumed that we do not need to do two offer answers to re-use but I 
>>>do not have a strong view here.
>> I don't have any strong feeling. If people want to immediately send a 
>> new offer with a new sub-protocol we can do that - as long as we document it properly.
>>
>> But, I do NOT think it should be sub-protocol specific (as indicated 
>> in the second paragraph of section 6.6.2) whether it's allowed or not - whatever approach we take it should be a generic feature.
>
> <RE> I agree, the new offer after the SCTP SSN reset exchange is a 
> reset to the channel and the new offer re-open it with any new 
> parameters but with SSN=0. If this is OK with you I will draft new 
> text for section 6.6.2

A little more on this:

Example:

A                                                   B

<RE>
I was thinking more on this call flow, SCTP SSN reset first like rtcweb document , will be the same as  dcep.  If we allow immediate channel add there is no problem with glare (section 6.1 ) since the ID is still in offer/answer use while if we close with SDP MUST obey section 6.1 odd/even rule since the ID is free to use by DCEP also. I am not sure if it is important to continue using the same ID.

A                                                   B

<----- SCTP SSN reset--------------->

Data channel sID= 1 is idle and SSN=0

<----- O/A close/add channel ------->

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 May 2018 11:06:16 +0000

Hi,

>> According to the procedures, the subsequent offer used to indicate that the channel 
>> will be closed is sent BEFORE the SCTP SSN. So, in my opinion it would be weird to 
>> indicate a new sub protocol in this offer, as the data channel is still active.
>>
>> So, in my opinion a new sub protocol should not be indicated until the SCTP SSN has been 
>> received - which means it would be in a separate offer.
>>
>>Example:
>>
>>A                                                   B
>>
> I was thinking more on this call flow, SCTP SSN reset first like rtcweb document , will be the same as  dcep.  
> If we allow immediate channel add there is no problem with glare (section 6.1 ) since the ID is still in offer/answer 
> use while if we close with SDP MUST obey section 6.1 odd/even rule since the ID is free to use by DCEP also. I am 
> not sure if it is important to continue using the same ID.
>
>A                                                   B
>

Ok, my assumption was that there is an O/A before the SCTP SSN, as it is a MUST in the document.

In the case above, I think there could be a glare. Because, the spec says that if an endpoint receives SCTP SSN, without an associated offer, the endpoint sends an offer itself. What if both endpoint sends an offer at the same time?

Would it be more clear to say that the endpoint that sends SCTP SSN is responsible for sending the close offer? That way there would be no glare.

Even if the other endpoint never receives the close offer (error case), when it receives the SCTP SSN it will consider the data channel closed, but it does not send a close offer itself.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 May 2018 12:34:32 -0400

I'm going to top post because the thread is now deep and this pertains 
to most of the discussion.

With normal O/A it is permissible to reuse an m-line for a new stream 
(even a different media type such as switching for audio to video) 
without first doing an O/A to terminate the old usage. ISTM the same 
should be true for individual data channels.

Regarding ordering of the SCTP SSN reset and the O/A:

ISTM that it should be permissible to do the SCTP SSN reset at any time, 
and then follow it up with the O/A that confirms it was intentional. The 
limitation here is obviously that you then cannot use the data stream 
until after an O/A that defines a new usage for it.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 May 2018 21:11:59 +0000

Hi,

>I'm going to top post because the thread is now deep and this pertains to most of the discussion.
>
>With normal O/A it is permissible to reuse an m-line for a new stream (even a different media type 
>such as switching for audio to video) without first doing an O/A to terminate the old usage. ISTM the same should be true for individual data channels.
>
>ISTM that it should be permissible to do the SCTP SSN reset at any time, and then follow it up with the O/A that confirms 
>it was intentional. The limitation here is obviously that you then cannot use the data stream until after an O/A that defines a new usage for it.

One question is whether the "confirmation" and definition of a new usage can be done in one single O/A.

Regards,

Christer

On 5/3/18 7:06 AM, Christer Holmberg wrote:
>>>>> clear on the process. In draft-ietf-rtcweb-data-channel-13 the 
>>>>> data channel is  closed by the "SCTP SSN reset" (one side sends 
>>>>> and waits to receive SCTP SSN reset from the other side) this 
>>>>> resets the SSN to zero and it can  be re-used by sending a new 
>>>>> DATA_CHANNEL_OPEN Message in the channel with the stream ID that was reset.
>>>>
>>>> Correct.
>>>>
>>>>> Here we have SCTP SSN reset and SDP. So we need to be clear what 
>>>>> is a channel close when the signaling is out of band. I assume 
>>>>> that we will need  both the SCTP SSN reset and an SDP offer/answer 
>>>>> exchange which will either remove the dcmap with the relevant 
>>>>> dcmap-stream-id or have it with new  sub protocol. I think that in 
>>>>> order for it to work the process should be that to close the 
>>>>> channel a SCTP SSN reset MUST be sent and the client sending  the 
>>>>> reset MUST stop sending data in this data channel and wait for 
>>>>> SCTP SSN reset from the other side on the same dcmap-stream-id. 
>>>>> Now the data channel  will not be used for sending data. After 
>>>>> receiving the SCTP SSN reset the side who originated the close 
>>>>> MUST send a new SDP offer removing the decamp with the 
>>>>> dcmap-stream-id or change the subprotocol in the existing SDP. The 
>>>>> decision if to re-use or close is application dependent. (I assume 
>>>>> that the re-use  can be by any side of the data channel (section 
>>>>> 6.1) and not only the side that originally created it since there 
>>>>> is no issue with collision.)
>>>>>
>>>>> Does this make sense?
>>>>
>>>> - If you later want to open a new data channel, with the same 
>>>> stream ID, that¹s ok. Then you send ANOTHER offer to do that.
>>>> offer change the sub-protocol from one thing to another. I think 
>>>> there shall be separate offers for closing the data channel and 
>>>> opening a new one - even if the stream ID is the same.
>>>>
>>>>> assumed that we do not need to do two offer answers to re-use but 
>>>>> I do not have a strong view here.
>>>>> Basically if both direction of the channels are reset you can 
>>>>> change the subprotocol in the first offer.
>>>>> If you think it is better to do a full close SCTP SSN reset and 
>>>>> offer answer removing the stream-id before reuse I am OK
>>>>
>>>> I don't have any strong feeling. If people want to immediately send 
>>>> a new offer with a new sub-protocol we can do that - as long as we document it properly.
>>>>
>>>> But, I do NOT think it should be sub-protocol specific (as 
>>>> indicated in the second paragraph of section 6.6.2) whether it's allowed or not - whatever approach we take it should be a generic feature.
>>>
>>> According to the procedures, the subsequent offer used to indicate 
>>> that the channel will be closed is sent BEFORE the SCTP SSN. So, in 
>>> my opinion it would be weird to indicate a new sub protocol in this offer, as the data channel is still active.
>>>
>>> So, in my opinion a new sub protocol should not be indicated until 
>>> the SCTP SSN has been received - which means it would be in a separate offer.
>>>
>>> Example:
>>>
>>> A                                                   B
>>>
>> If we allow immediate channel add there is no problem with glare 
>> (section 6.1 ) since the ID is still in offer/answer use while if we 
>> close with SDP MUST obey section 6.1 odd/even rule since the ID is free to use by DCEP also. I am not sure if it is important to continue using the same ID.
>>
>> A                                                   B
>>
>>> Not that we proposal did not cover the whole O/A section. The 
>>> answerer procedures also need to be modified.
>>>
>>> - SHALL include an SDP dcmap attribute for the new data channel, 
>>> with a new, associated dcmap-stream-id attribute value; and
>>> 5 and 6.1 and 6.2 where relevent and remove 6.6.1 my proposed text 
>>> for section 6.3
>>>
>>> - SHALL include an SDP dcmap attribute (section 5 and section 6.2) 
>>> for the new data channel, with a new, associated dcmap-stream-id 
>>> attribute value using stream identifiers from the owned set (see Section 6.1).
>>> - MAY include one or more SDP dcsa attributes (section 5) for the 
>>> new data channel, using a stream-id attribute value identical to the 
>>> Finally, as I commented earlier, we don't need statements like 
>>> "sends the answer","applies the answer" etc. That is implicit. You 
>>> don't generate an offer or answer unless you intend to send it :)
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 May 2018 17:18:52 -0400

> One question is whether the "confirmation" and definition of a new usage can be done in one single O/A.

Why not? I see no ambiguity as long as there is *some* change.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 May 2018 21:24:40 +0000

Hi,

>>> (even a different media type such as switching for audio to video) without first doing an O/A to terminate the 
>>> old usage. ISTM the same should be true for individual data channels.
>>>
>>> ISTM that it should be permissible to do the SCTP SSN reset at any 
>>> time, and then follow it up with the O/A that confirms it was intentional. The limitation here is obviously that 
>>> you then cannot use the data stream until after an O/A that defines a new usage for it.
>> 

In this case I guess it's fine, because the O/A is sent AFTER the SCTP SSN.

However, if an endpoint sends an offer, in order to indicate the intention of removing a data channel, BEFORE it sends SCTP SSN, I don't think the new usage can be done in that same O/A, because the previous data channel is still active - and won't be closed until the SCTP SSN has been sent (the offer does not close the data channel).

Regards,

Christer

>>>>>> that we will need  both the SCTP SSN reset and an SDP 
>>>>>> offer/answer exchange which will either remove the dcmap with the 
>>>>>> relevant dcmap-stream-id or have it with new  sub protocol. I 
>>>>>> think that in order for it to work the process should be that to 
>>>>>> close the channel a SCTP SSN reset MUST be sent and the client 
>>>>>> sending  the reset MUST stop sending data in this data channel 
>>>>>> and wait for SCTP SSN reset from the other side on the same dcmap-stream-id.
>>>>>> dcmap-stream-id or change the subprotocol in the existing SDP. 
>>>>>> The decision if to re-use or close is application dependent. (I 
>>>>>> (section
>>>>> - BUT, I don¹t think we should allow the case where you in a 
>>>>> single offer change the sub-protocol from one thing to another. I 
>>>>> think there shall be separate offers for closing the data channel 
>>>>> and opening a new one - even if the stream ID is the same.
>>>>>
>>>>>> <RE> Since after the SCTP SSN reset exchange the channel is idle 
>>>>>> I assumed that we do not need to do two offer answers to re-use 
>>>>>> but I do not have a strong view here.
>>>>> I don't have any strong feeling. If people want to immediately 
>>>>> send a new offer with a new sub-protocol we can do that - as long as we document it properly.
>>>>>
>>>>    corresponding SDP dcmap attribute ....
>>>>
>>>> new data channel, using a stream-id attribute value identical to 
>>>> the dcmap-stream-id value used for the
>>>> Regarding section 6.6, I suggest to rename it (to be consistent 
>>>> with the O/A procedures in other specs), and then say something like:
>>>>
>>>> ---
>>>>
>>>>     When an offer sends a subsequent offer, that includes 
>>>> information for a previously created data channel, unless the offerer

---

From: "Roni Even (A)" <[email-masked]>
Date: Sat, 5 May 2018 14:12:57 +0000

Hi Paul,
I think that the major issue is that in an SCTP association there may be both in band (DCEP) and out of band (SDP) negotiated data channel.
the SCTP SSN reset is the close signal for DCEP and if a client receives SCTP SSN reset it needs to evaluate if there is an SDP tied to this stream-id. If there is an SDP stream-id it should do a new offer removing the m-line with the stream-id or it can re-use the stream-id in an offer. One question is if we want mandate that first the stream must be removed and using a second offer re-used.  At least for DCEP it can be re-used once both sides received an SCTP SSN reset
Roni

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, May 04, 2018 7:35 PM
To: [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-18.txt

With normal O/A it is permissible to reuse an m-line for a new stream (even a different media type such as switching for audio to video) without first doing an O/A to terminate the old usage. ISTM the same should be true for individual data channels.

ISTM that it should be permissible to do the SCTP SSN reset at any time, and then follow it up with the O/A that confirms it was intentional. The limitation here is obviously that you then cannot use the data stream until after an O/A that defines a new usage for it.

	Thanks,
	Paul

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 6 May 2018 05:12:36 +0000

Inline

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Saturday, May 05, 2018 12:25 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-18.txt

Hi,

>>> With normal O/A it is permissible to reuse an m-line for a new 
>>> stream (even a different media type such as switching for audio to 
>>> video) without first doing an O/A to terminate the old usage. ISTM the same should be true for individual data channels.
>>>
>>> time, and then follow it up with the O/A that confirms it was 
>>> intentional. The limitation here is obviously that you then cannot use the data stream until after an O/A that defines a new usage for it.
>> 

However, if an endpoint sends an offer, in order to indicate the intention of removing a data channel, BEFORE it sends SCTP SSN, I don't think the new usage can be done in that same O/A, because the previous data channel is still active - and won't be closed until the SCTP SSN has been sent (the offer does not close the data channel).
<RE> This is correct, this is why I think that the first step should be SCTP SSN reset, this is the lower layer.

Regards,

Christer