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

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Sep 2019 19:11:08 +0000

Hi,

Based on Gunnar’s comment, I have merged the following pull request:

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

…and submitted a new version (-01) of the t140-data-channel draft.

There are currently no open issue, and my question to the community is: are we ready for WGLC?

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 10 Sep 2019 21:52:25 +0000

Hi,

My view is that we are very close to a state suitable for WGLC. When reading version -01, I saw a couple of issues I think need to be discussed before going to WGLC:

1. Hard to mix support and non-support of SDP direction attributes.
We realized that the current W3C WebRTC API does not support the direction attributes. Therefore it can be expected that non-support of the direction attributes will be common.

Neither RFC 3264 section 6, nor the t140-usage draft section "3.2.3.1.2.  Generating an Answer" tells what happens if the offerer includes a sendonly, recvonly or incactive direction attribute and the answerer does not support the direction attributes. Instead RFC 3264 section 6, and the t140-usage draft section "3.2.3.1.2 have statements like " If a stream is offered as sendonly, the corresponding stream MUST be marked as recvonly or inactive in the answer."

What happens if the answerer does not support the direction attributes? We may need to introduce some wording to ease the coexistence of devices with and without support of the direction attributes.

2. Introduce an example in 3.3 without hlang- and direction attributes. Since it will be common with no support of the hlang- and direction attributes, I think that section 3.3 should have one example without such attributes.

Regards

Gunnar

________________________________________
Från: mmusic <[email-masked]> för Christer Holmberg <[email-masked]>
Skickat: den 10 september 2019 21:11
Till: [email-masked]
Kopia: [email-masked]
Ämne: [MMUSIC] Draft new version: t140-data-channel-01

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Sep 2019 22:09:19 +0000

Hi,
    
>    We realized that the current W3C WebRTC API does not support the direction attributes. Therefore it 
>    can be expected that non-support of the direction attributes will be common.
>    
>    Neither RFC 3264 section 6, nor the t140-usage draft section "3.2.3.1.2.  Generating an Answer" tells what happens if the 
>    offerer includes a sendonly, recvonly or incactive direction attribute and the answerer does not support the direction attributes. 
>    Instead RFC 3264 section 6, and the t140-usage draft section "3.2.3.1.2 have statements like " If a stream is offered as sendonly, 
>    the corresponding stream MUST be marked as recvonly or inactive in the answer."
>    
>    What happens if the answerer does not support the direction attributes? We may need to introduce some wording to ease the
>    coexistence of devices with and without support of the direction attributes.
    
I think we can extend the note by saying that if an answer does not contain a direction attribute in accordance with to the procedures, the offerer needs to assume that the answerer might both send and receive text.

>    2. Introduce an example in 3.3 without hlang- and direction attributes. Since it will be common with no support of the hlang- and direction attributes, 
>    I think that section 3.3 should have one example  without such attributes.

I can add such example, eventhough one is not supposed to implement examples.

Regards,

Christer

    Hi,

    https://protect2.fireeye.com/url?k=bd43a9f9-e197a48b-bd43e962-86859b2931b3-201f76904126d29c&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F27

    
    Regards,
    
    Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 11 Sep 2019 10:47:39 +0000

Hi,

________________________________________
Från: Christer Holmberg <[email-masked]>
Skickat: den 11 september 2019 00:09
Till: Gunnar Hellström; [email-masked]
Ämne: Re: Draft new version: t140-data-channel-01

Hi,

[GH] That sounds to be a good and natural default action. Can you tell me where that can be concluded from RFC 3264 or RFC 4566 or sdpneg. If not, it should be stated in a proper section and not in a NOTE.

[GH]Right, but if most early implementations will not be able to use DCSA attributes, I think it is good to show the most common case in an example. 
Regards
Gunnar

Regards,

Christer

    Hi,

    Regards,

    Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 11 Sep 2019 13:31:44 +0000

Hi,

Hi,

[GH]  I found in RFC 4566 for a=sendrecv, the following statement that can be interpreted to the same as you propose: That the session gets sendrecv status if no direction is included in the answer:
-------------------------from RFC 4566 ---------------------------

         If none of the attributes "sendonly", "recvonly", "inactive",
         and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
         default for sessions that are not of the conference type
         "broadcast" or "H332" (see below).

------------------------------------------------------------------------
However RFC 3264 has a number of MUSTs for including a direction attribute in the answer if the offer had one, and no indication that it would be possible to not support the direction attributes. What is supposed to happen if you violate these MUSTs in RFC 3264?

Gunnar

>    2. Introduce an example in 3.3 without hlang- and direction attributes.. Since it will be common with no support of the hlang- and direction attributes,

Regards,

Christer

    Hi,

    Regards,

    Christer

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Sep 2019 13:40:58 +0000

Hi,

>>>    My view is that we are very close to a state suitable for WGLC. When reading version -01, I saw a
>>>     couple of issues I think need to be discussed before going to WGLC:
>>>
>> I think we can extend the note by saying that if an answer does not contain a direction attribute in accordance with to the
>> procedures, the offerer needs to assume that the answerer might both send and receive text.
>
> [GH] That sounds to be a good and natural default action. Can you tell me where that can be concluded from RFC 3264 or
> RFC 4566 or sdpneg. If not, it should be stated in a proper section and not in a NOTE.
>
> [GH]  I found in RFC 4566 for a=sendrecv, the following statement that can be interpreted to the same as you propose:
> That the session gets sendrecv status if no direction is included in the answer:

> However RFC 3264 has a number of MUSTs for including a direction attribute in the answer if the offer had one,
> and no indication that it would be possible to not support the direction attributes. What is supposed to happen if
> you violate these MUSTs in RFC 3264?

I think the assumption in RFC 3264 is that every endpoint support the direction attributes, and if an endpoint doesn’t use them in accordance with a spec it is considered error behavior.

But, in our case, you want to say that it is a “normal” situation for an endpoint to not use the direction attributes as specified, since there are cases (W3C API) where endpoints are not able to.

Regards,

Christer

Regards,

Christer

    Hi,

    Regards,

    Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Sep 2019 11:07:26 -0400

On 9/11/19 9:31 AM, Gunnar Hellström wrote:

> [GH]  I found in RFC 4566 for a=sendrecv, the following statement that 
> can be interpreted to the same as you propose: That the session gets 
> sendrecv status if no direction is included in the answer:
> However RFC 3264 has a number of MUSTs for including a direction 
> attribute in the answer if the offer had one, and no indication that it 
> would be possible to not support the direction attributes. What is 
> supposed to happen if you violate these MUSTs in RFC 3264?

1) I think we can assume anyone who supports SIP supports RFC3261. (I 
doubt there are any 2543 implementations out there any longer.)

2) RFCs 3261 and 3264 require support for SDP via RFC2327. That has been 
replaced by RFC4566 (and soon RFC4566bis). Both of those include the 
definitions of the direction attributes.

Hence, anyone who claims to support SIP and/or 3264 O/A must support the 
direction attributes. Doing anything that implies not understanding them 
would be non-compliant.

We don't normally bother to specify what action to take in the face of 
non-compliance. We leave it as implementor's choice.

In the case of data channels, they are defined as bi-directional, so it 
makes sense to take that as the default in the case of not not 
understanding per-data-channel direction attributes.

But in the context of using T140 with data channels this document will 
rule. If it is written correctly then supporting it will require also 
supporting the direction attributes for it.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 11 Sep 2019 19:46:05 +0000

[GH] Thanks for the clarification that support of the direction attributes is mandatory for SDP.
Then we need to decide if there is any hope that an implementation of the T.140 data channel used through the W3C WebRTC API will ever be able to convey the result of the negotiation through the API. If not, we might have better withdraw the support of other than sendrecv for T.140 in the draft.

--Or the opposite, talk with W3C about support for various attributes through the API.

Regards

Gunnar

        Thanks,
        Paul

---

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

Hi,

> [GH] Thanks for the clarification that support of the direction attribute
> is mandatory for SDP.
> Then we need to decide if there is any hope that an implementation of the T.140 data channel
> used through the W3C WebRTC API will ever be able to convey the result of the negotiation
> through the API. If not, we might have better withdraw the support of other than sendrecv
> for T.140 in the draft.
>

My suggestion would be to point out that some implementations may not set the direction attributes in accordance with the procedures, and that it is recommended that one does not declare an error in such cases, but rather assume that such endpoints might both send and receive text. That makes the mechanism “future proof”, and the W3C can then be asked to take support of the direction attributes (or, dcsa attributes in general) into consideration for future versions of the API.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 11 Sep 2019 20:59:23 +0000

Hi Christer,
I like your proposal,

Regards
Gunnar

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Sep 2019 17:11:01 -0400

On 9/11/19 4:45 PM, Christer Holmberg wrote:

> My suggestion would be to point out that some implementations may not 
> set the direction attributes in accordance with the procedures, and that 
> it is recommended that one does not declare an error in such cases, but 
> rather assume that such endpoints might both send and receive text. That 
> makes the mechanism “future proof”, and the W3C can then be asked to 
> take support of the direction attributes (or, dcsa attributes in 
> general) into consideration for future versions of the API.

I think this is fine. But doesn't WebRTC generally assume that channels 
will b dynamically assigned without use of SDP O/A? None of this will 
apply to those.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Sep 2019 14:14:20 -0700

Christer said:

"the W3C can then be asked to take support of the direction attributes (or,
dcsa attributes in general) into consideration for future versions of the
API."

[BA] While the WebRTC 1.0 API supports the direction attribute for
transceivers
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtptransceiver-direction>,
there is no support for unidirectional data channels. For example, there is
no direction member in the RTCDataChannelInit dictionary that is passed as
a second (optional) argument in RTCPeerConnection.createDataChannel(). This
is because the data channel API is modeled on WebSockets which are also
assumed to be bi-directional.

The WebTransport API <https://wicg.github.io/web-transport/> does support
both unidirectional and bidirectional transport.

dictionary RTCDataChannelInit
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit>
{
  boolean <https://heycam.github.io/webidl/#idl-boolean> ordered
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-ordered>
= true;
  [EnforceRange <https://heycam.github.io/webidl/#EnforceRange>]
unsigned short <https://heycam.github.io/webidl/#idl-unsigned-short>
maxPacketLifeTime
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-maxpacketlifetime>;
  [EnforceRange <https://heycam.github.io/webidl/#EnforceRange>]
unsigned short <https://heycam.github.io/webidl/#idl-unsigned-short>
maxRetransmits <https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-maxretransmits>;
  USVString <https://heycam.github.io/webidl/#idl-USVString> protocol
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-protocol>
= "";
  boolean <https://heycam.github.io/webidl/#idl-boolean> negotiated
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-negotiated>
= false;
  [EnforceRange <https://heycam.github.io/webidl/#EnforceRange>]
unsigned short <https://heycam.github.io/webidl/#idl-unsigned-short>
id <https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-id>;
  RTCPriorityType
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype>
priority <https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-priority>
= "low";
};

partial interface RTCPeerConnection
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcpeerconnection>
{
  readonly attribute RTCSctpTransport
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcsctptransport>?
sctp <https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcpeerconnection-sctp>;
  RTCDataChannel
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannel>
createDataChannel
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-peerconnection-createdatachannel>(USVString
<https://heycam.github.io/webidl/#idl-USVString> label,
                                   optional RTCDataChannelInit
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit>
dataChannelDict);
  attribute EventHandler
<https://html.spec.whatwg.org/multipage/#eventhandler> ondatachannel
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcpeerconnection-ondatachannel>;
};

On Wed, Sep 11, 2019 at 1:45 PM Christer Holmberg <
[email-masked]> wrote:

> My suggestion would be to point out that some implementations may not set
> the direction attributes in accordance with the procedures, and that it is
> recommended that one does not declare an error in such cases, but rather
> assume that such endpoints might both send and receive text. That makes the
> mechanism “future proof”, and the W3C can then be asked to take support of
> the direction attributes (or, dcsa attributes in general) into
> consideration for future versions of the API.
>
>
>
> Regards,
>
>
>
> Christer
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Sep 2019 21:16:01 +0000

Hi,
    
>    will b dynamically assigned without use of SDP O/A? None of this will 
  
I assume you refer to the usage of DCEP instead of SDP O/A? 

The usage of DCEP is optional - I am aware of browser clients using SDP O/A.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Sep 2019 21:17:50 +0000

Hi Bernard,

As you said, data channels are always considered to be bi-directional. In the case of T.140, the direction attributes are more for the applications to indicate whether they want to send and/or receive text on such bi-directional data channel.

Regards,

Christer

From: Bernard Aboba <[email-masked]>
Date: Wednesday, 11 September 2019 at 14.14
To: Christer Holmberg <[email-masked]>
Cc: Gunnar Hellstrom <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Harald Alvestrand <[email-masked]>
Subject: Re: [MMUSIC] Draft new version: t140-data-channel-01

Christer said:

"the W3C can then be asked to take support of the direction attributes (or, dcsa attributes in general) into consideration for future versions of the API."

[BA] While the WebRTC 1.0 API supports the direction attribute for transceivers<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtptransceiver-direction>,  there is no support for unidirectional data channels. For example, there is no direction member in the RTCDataChannelInit dictionary that is passed as a second (optional) argument in RTCPeerConnection.createDataChannel(). This is because the data channel API is modeled on WebSockets which are also assumed to be bi-directional.

The WebTransport API<https://protect2.fireeye.com/url?k=cda7b049-912e1fc4-cda7f0d2-0cc47ad93de2-a4b7d477df0bba76&q=1&u=https%3A%2F%2Fwicg.github.io%2Fweb-transport%2F> does support both unidirectional and bidirectional transport.

dictionary RTCDataChannelInit<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit> {

  boolean<https://protect2.fireeye.com/url?k=ba4355ac-e6cafa21-ba431537-0cc47ad93de2-55b6b697c499562b&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23idl-boolean> ordered<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-ordered> = true;

  [EnforceRange<https://protect2.fireeye.com/url?k=f4e14777-a868e8fa-f4e107ec-0cc47ad93de2-5f4fbabfec6b525e&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23EnforceRange>] unsigned short<https://protect2.fireeye.com/url?k=00572969-5cde86e4-005769f2-0cc47ad93de2-2e9abcb7818d2aac&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23idl-unsigned-short> maxPacketLifeTime<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-maxpacketlifetime>;

  [EnforceRange<https://protect2.fireeye.com/url?k=e088dccd-bc017340-e0889c56-0cc47ad93de2-fa71688d8d024bf9&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23EnforceRange>] unsigned short<https://protect2.fireeye.com/url?k=f61b6037-aa92cfba-f61b20ac-0cc47ad93de2-aae15a7fd354a93e&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23idl-unsigned-short> maxRetransmits<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-maxretransmits>;

  USVString<https://protect2.fireeye.com/url?k=f628e044-aaa14fc9-f628a0df-0cc47ad93de2-2e1da345b360cc1c&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23idl-USVString> protocol<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-protocol> = "";

  boolean<https://protect2.fireeye.com/url?k=7cc47037-204ddfba-7cc430ac-0cc47ad93de2-1f7c896da79218fd&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23idl-boolean> negotiated<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-negotiated> = false;

  [EnforceRange<https://protect2.fireeye.com/url?k=cf4e3c77-93c793fa-cf4e7cec-0cc47ad93de2-5f9210a2ae47dbba&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23EnforceRange>] unsigned short<https://protect2.fireeye.com/url?k=ff7921bf-a3f08e32-ff796124-0cc47ad93de2-2632da73f892129e&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23idl-unsigned-short> id<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-id>;

  RTCPriorityType<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcprioritytype> priority<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit-priority> = "low";

};

partial interface RTCPeerConnection<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcpeerconnection> {

  readonly attribute RTCSctpTransport<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcsctptransport>? sctp<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcpeerconnection-sctp>;

  RTCDataChannel<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannel> createDataChannel<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-peerconnection-createdatachannel>(USVString<https://protect2.fireeye.com/url?k=72c242b9-2e4bed34-72c20222-0cc47ad93de2-607d2ab370107c20&q=1&u=https%3A%2F%2Fheycam.github.io%2Fwebidl%2F%23idl-USVString> label,

                                   optional RTCDataChannelInit<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannelinit> dataChannelDict);

  attribute EventHandler<https://html.spec.whatwg.org/multipage/#eventhandler> ondatachannel<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcpeerconnection-ondatachannel>;

};

On Wed, Sep 11, 2019 at 1:45 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

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

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 12 Sep 2019 14:44:17 +0000

The latest findings indicate that most implementations of the T.140 data channel (via Web browser and W3C API) will not be able to use the attributes we have specified ( cps = characters per second, hlang-send and hlang-recv for human language, and sendonly, recvonly, inactive). For the direction attributes, there can also be problems with implementations being non-compliant with RFC 4566. It can cause complications at least in gateway situations.  The remark that some implementations may want to handle the data channel through the RTCWEB DCEP protocol without SDP makes it possibly desirable to change the draft so that use of SDP is optional.

Looking at what others have done is usually good for inspiration to get things right. The msrp data channel draft has some dcsa attributes and will apparently handle their use in some way, while the CLUE data channel draft is very explicit on that no dcsa attributes are used. I think the CLUE approach looks wise.

I suggest that we keep the descriptions of dcsa attributes but make it very clear that use through SDP is optional and use of the dcsa attributes are also optional.

Sorry for finding more issues when we thought we could recommend WGLC.

Regards
Gunnar

Hi Bernard,

Regards,

Christer

Christer said:

};

};

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Sep 2019 12:15:38 -0400

> I assume you refer to the usage of DCEP instead of SDP O/A?

Yes.

> The usage of DCEP is optional - I am aware of browser clients using SDP O/A.

Right.

I don't have any personal knowledge of webrtc/sip gateways. I imagine 
there are many ways of building them. I guess *this* draft is simply 
aiming to make it possible to use explicit O/A in webrtc and achieve 
interop with sip.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Sep 2019 16:15:56 +0000

Hi,

>The latest findings indicate that most implementations of the T.140 data channel (via Web browser and W3C API) will not be able to >use the attributes we have specified ( cps = characters per second, hlang-send and hlang-recv for human language, and sendonly, >recvonly, inactive). For the direction attributes, there can also be problems with implementations being non-compliant with RFC 4566. >It can cause complications at least in gateway situations.  The remark that some implementations may want to handle the data channel >through the RTCWEB DCEP protocol without SDP makes it possibly desirable to change the draft so that use of SDP is optional.
>
> Looking at what others have done is usually good for inspiration to get things right. The msrp data channel draft
> has some dcsa attributes and will >apparently handle their use in some way, while the CLUE data channel draft is
> very explicit on that no dcsa attributes are used. I think the CLUE >approach looks wise.
>
> I suggest that we keep the descriptions of dcsa attributes but make it very clear that use through SDP is optional
> and use of the dcsa attributes are also optional.

Not sure I understand. The use of SDP for establishing a data channel usage is already optional.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Sep 2019 16:19:52 +0000

Hi,

>    aiming to make it possible to use explicit O/A in webrtc and achieve 
  
Correct.

(There are cases, however, where people use O/A in WebRTC even if there is no SIP interop involved)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Sep 2019 17:26:05 +0000

Hi,

I have created a pull request:

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

Regards,

Christer

On 12/09/2019, 9.20, "mmusic on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Correct.

    Regards,
    
    Christer