Subject: [MMUSIC] Draft new version: t140-data-channel-usage-02

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Sep 2019 19:21:03 +0000

Hi,

Based on Gunnar’s comments, I have submitted a new version (-02) of the t.140 data channel usage draft.

The following pull requests have been merged and included in the new version:

https://github.com/cdh4u/draft-datachannel-t140/pull/29
https://github.com/cdh4u/draft-datachannel-t140/pull/28

Are we now ready for WGLC?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Sep 2019 15:39:16 -0400

> Are we now ready for WGLC?

It would be "nice" to have an example of the use of the direction 
attributes in DCSA.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Sep 2019 23:15:46 +0000

Hi,

> It would be "nice" to have an example of the use of the direction 

The second SDP examples shows the direction attribute in dcsa.

Or, do you mean in the offer/answer example?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Sep 2019 05:39:51 +0000

Hi,

I have created a pull request that adds an O/A example with direction attributes in dcsa:

https://github.com/cdh4u/draft-datachannel-t140/pull/30

Regards,

Christer

On 13/09/2019, 16.16, "Christer Holmberg" <christer.holmberg=[email-masked]> wrote:

    Hi,

    
    
    Regards,
    
    Christer

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

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 14 Sep 2019 21:23:46 +0000

Hi,

A couple of days ago, I tried to propose that we remove the requirement that the T.140 data channel is established through SDP interaction.

I suggest that we specify the WebRTC data channel parameters to use, and then how that and the specific SDP attribute values can be achieved by SDP.

Proposal:

A. In 1. Introduction, change the following paragraph:

"In this document, a T.140 data channel refers to a WebRTC data
   channel for which the instantiated sub-protocol is "t140", and where
   the channel is negotiated using the SDP-based external negotiation
   method [I-D.ietf-mmusic-data-channel-sdpneg]."

To:

"In this document, a T.140 data channel refers to a WebRTC data

   channel for which the instantiated sub-protocol is "t140", and where
   the channel can be negotiated using the SDP-based external negotiation
   method [I-D.ietf-mmusic-data-channel-sdpneg]."

B. Before 3., insert a new section 3. and increase the section numbers by 1.

"

3. T.140 data channel characteristics

The T.140 data channel shall be established as a WebRTC data channel

[I-D.ietf-rtcweb-data-channel] with the following characteristics:

Sub-protocol "t140".

Reliable ordered delivery.

Label optionally indicating party taking the initiative to the session.

"

C. In currect section 3, that becomes 4. Change the following sentence

"

This section defines the SDP
   considerations that are specific to a T.140 data channel."

To

"

This section defines the SDP
   considerations that are specific to a T.140 data channel, when
it is established or modified by SDP.

"

Regards

Gunnar

________________________________
Från: mmusic <[email-masked]> för Christer Holmberg <christer.holmberg=[email-masked]>
Skickat: den 14 september 2019 07:39
Till: Paul Kyzivat <[email-masked]>; [email-masked] <[email-masked]>
Ämne: Re: [MMUSIC] Draft new version: t140-data-channel-usage-02

Hi,

Regards,

Christer

    Hi,

    Regards,

    Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 Sep 2019 21:44:00 -0400

> https://github.com/cdh4u/draft-datachannel-t140/pull/30

Looks good.

	Thanks!
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 15 Sep 2019 11:32:26 +0000

Hi,

> A couple of days ago, I tried to propose that we remove the requirement that the
> T.140 data channel is established through SDP interaction.

There is no generic requirement to use SDP for establishing a T.140 data channel. This draft defines how to do it using SDP, using the mechanism defined in draft-data-channel-sdpneg (SDPNEG).

The text in SDPNEG says:

   "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 an out-of-band
   non-DCEP negotiation for establishing a data channel."

One has to put the draft into context: it defines a SDPNEG usage, so the scope of SDPNEG applies. Again, nothing prevents using other mechanisms, but those are outside the scope of SDPNEG, and hence this draft.

Also, Section 5 of SDPNEG defines generically how the SDP dcmap attribute sub-protocol, label etc parameters map to DCEP.

Having said that, based on the fact that the generic T.140 considerations in sections 4 and 5 can also be applied to other mechanisms, so we could say something like:

"Section X defines the generic data channel properties for a T.140 data channel, and Section 3 defines how they are conveyed in an SDP dcmap attribute. While this document defines how to establish a T.140 data channel using the mechanism defined in SDPNEG, the generic T.140 and gateway considerations defined in Sections 4 and 5 can also be applied when a T.140 data channel is established using other mechanisms (e.g., the mechanism defined in DCEP). Section 5 of SDPNEG defines the mapping between the SDP dcmap attribute parameters and DCEP parameters."

>   method [I-D.ietf-mmusic-data-channel-sdpneg]."

I think the suggested text with "can" is confusing, as the document describes how to establish a T.140 data channel using the SDPNEG mechanism.

But, does the note I suggested above address your issue? 

---

>Label optionally indicating party taking the initiative to the session.

Section 1 says:

   "In this document, a T.140 data channel refers to a WebRTC data
   channel for which the instantiated sub-protocol is "t140""

Section 3.1 says:

   "If the ordered attribute parameter is included in the 'dcmap'
   attribute, it MUST be assigned the value 'true'."

For the label, there is text in Sections 3.1 and 4.5.

But, perhaps we could all that in one place, by adding the following table to a new Section: "Data Channel Properties".

====

X. Data Channel Properties

The following data channel property values (ref-to-rtcweb-data-channel) apply to a T.140 data channel:

Property		Value
----------------------------------------------------------------
Sub-protocol		"t140"		
Transmission reliability	reliable
Transmission order	in-order
Label			See Sections 3.1 and 4.5

===

---

>"This section defines the SDP considerations that are specific to a T.140 data channel."
>To
>"This section defines the SDP considerations that are specific to a T.140 data channel, when 
>it is established or modified by SDP."

See my comment on A.

Regards,

Christer

Hi,

https://protect2.fireeye.com/url?k=06303512-5ab9ee1d-06307589-0cc47ad93e1a-e56ab671939020a8&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F30

Regards,

Christer

On 13/09/2019, 16.16, "Christer Holmberg" <mailto:christer.holmberg=[email-masked]> wrote:

    Hi,
    
    >> Are we now ready for WGLC?
    >    
    > It would be "nice" to have an example of the use of the direction 
    > attributes in DCSA.

    
    Regards,
    
    Christer

    mailto:[email-masked]

mailto:[email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 15 Sep 2019 13:00:14 +0000

[gh] I like your section X and the introduction text about X and 3 and 4. I think section X should be placed before the current 3. 

You do not need to view the scope of the draft to be only related to sdpneg. Section X and current 4 are general. So we do not need to keep the scope limited to sdpneg usage. Please look at the changes from that view.

My change proposals for section 3 aimed at resolving some statements that seemed to require that sdp must be used  for establishing the T.140 data channel. 

I agree that "can" was not a good word in my proposal A.

Regards
/Gunnar

Hi,

The text in SDPNEG says:

---

Section 1 says:

Section 3.1 says:

====

Property                Value

===

---

See my comment on A.

Regards,

Christer

Hi,

Regards,

Christer

    Hi,

    Regards,

    Christer

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 15 Sep 2019 14:35:00 +0000

Hi,

>[gh] I like your section X and the introduction text about X and 3 and 4. I think section X should be placed before the current 3. 

Yes, that was my idea. I should have made it clear.

>You do not need to view the scope of the draft to be only related to sdpneg. Section X and current 4 are general. So we do not need to
>keep the scope limited to sdpneg usage. Please look at the changes from that view.

The scope IS SDPNEG, but if there are procedures that can also be applied to DCEP that's good.

>I agree that "can" was not a good word in my proposal A.

I think the text I suggested above clarifies that a T.140 data channel can also be established using other mechanisms.

Regards,

Christer

Hi,

The text in SDPNEG says:

---

Section 1 says:

Section 3.1 says:

====

Property                Value

===

---

>"This section defines the SDP considerations that are specific to a 
>T.140 data channel, when it is established or modified by SDP."

See my comment on A.

Regards,

Christer

Hi,

Regards,

Christer

    Hi,

    Regards,

    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 15 Sep 2019 15:11:45 +0000

The pull request:

https://github.com/cdh4u/draft-datachannel-t140/pull/31

Regards,

Christer

On 15/09/2019, 17.35, "Christer Holmberg" <christer.holmberg=[email-masked]> wrote:

    Hi,

    

    
    
    Regards,
    
    Christer

    
    Hi,

    
    The text in SDPNEG says:

    

    

    
    ---

    Section 1 says:

    Section 3.1 says:

    
    
    ====

    
    Property                Value
    
    ===
    
    ---

    See my comment on A.
    
    Regards,
    
    Christer

    
    Hi,

    
    Regards,
    
    Christer

        Hi,

    
    
        Regards,
    
        Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 16 Sep 2019 12:05:15 +0000

Hi,
I think your latest change proposals are good. After they are done, I think we should be ready for WGLC.

Regards
Gunnar

----------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 20 42 88
________________________________
Från: Christer Holmberg <[email-masked]>
Skickat: den 15 september 2019 17:11:45
Till: Gunnar Hellström <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked] <[email-masked]>
Ämne: Re: [MMUSIC] Draft new version: t140-data-channel-usage-02

The pull request:

Regards,

Christer

    Hi,

    Regards,

    Christer

    Hi,

    The text in SDPNEG says:

    ---

    Section 1 says:

    Section 3.1 says:

    ====

    Property                Value

    ===

    ---

    See my comment on A.

    Regards,

    Christer

    Hi,

    Regards,

    Christer

        Hi,

        Regards,

        Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Sep 2019 12:28:27 +0000

Hi,

Unless someone raises any issues, I plan to merge the 2 open pull requests and submit a new version of the draft tomorrow.

Regards,

Christer

From: Gunnar Hellstrom <[email-masked]>
Date: Monday, 16 September 2019 at 15.05
To: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: SV: [MMUSIC] Draft new version: t140-data-channel-usage-02

Hi,

Regards
Gunnar

The pull request:

https://github.com/cdh4u/draft-datachannel-t140/pull/31<https://protect2.fireeye.com/url?k=28b620ab-74622c5a-28b66030-864685b2085c-c5393655a6cdf32c&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F31>

Regards,

Christer

    Hi,

    Regards,

    Christer

    Hi,

    The text in SDPNEG says:

    ---

    Section 1 says:

    Section 3.1 says:

    ====

    Property                Value

    ===

    ---

    See my comment on A.

    Regards,

    Christer

    Hi,

    Regards,

    Christer

        Hi,

        Regards,

        Christer