Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel-gateway considerations - direction attributes

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 16:44:14 +0000

Hi,

>>> The data channel itself is always bi-directional. Now, if you want to 
>>> allow usage of direction attributes for T.140 data I guess we would 
>>> have to define usage of them inside a 'dcsa' attribute.
>> 
>> If it is common to use these attributes for muting etc in conferencing 
>> scenarios for other media, I think they should be mentioned and 
>> registered. The action on the T.140 data channel needs then be on 
>> application level. That provides an opportunity to indicate in the 
>> user interface that what the user types is not transmitted in case of muted.
>> If other mechanisms are usually used for other media, we could ignore 
>> these attributes.
>
> I think it may make sense to use sendonly/recvonly here. Doing so will require *some* document to specify 
> that and update the registration of those attributes to indicate it.
>
> But I don't think it is sufficient to simply add IANA considerations to update the registry. The use of sendrecv/sendonly/recvonly/inactive, 
> as specified in rfc4566bis, is strongly linked (at least implicitly) to how RTP works. To use them in this new context I think there needs to 
> be a document that discusses the details.

The pull request contains both IANA registry update- and procedure text.

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

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Aug 2019 13:32:57 -0400

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

That simply references RFC3264. If I read that and try to apply it to 
this usage I have to apply a lot of interpretation and judgement. For 
instance, I need to consider this to be unicast. And there are lots of 
references to things that don't fit.

I think it would be better to restate the parts of 3264 that apply, 
using the terms relevant to this usage. Once it is stripped down to just 
the parts that pertain to directionality I don't think it will be a lot.

That will eliminate differences of interpretation.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 17:45:22 +0000

Hi,

>>>>> The data channel itself is always bi-directional. Now, if you want 
>>>>> to allow usage of direction attributes for T.140 data I guess we 
>>>>> would have to define usage of them inside a 'dcsa' attribute.
>>>>
>>>> If it is common to use these attributes for muting etc in 
>>>> conferencing scenarios for other media, I think they should be 
>>>> mentioned and registered. The action on the T.140 data channel needs 
>>>> then be on application level. That provides an opportunity to 
>>>> indicate in the user interface that what the user types is not transmitted in case of muted.
>>>> If other mechanisms are usually used for other media, we could 
>>>> ignore these attributes.
>>>
>>> I think it may make sense to use sendonly/recvonly here. Doing so 
>>> will require *some* document to specify that and update the registration of those attributes to indicate it.
>>>
>>> But I don't think it is sufficient to simply add IANA considerations 
>>> to update the registry. The use of  sendrecv/sendonly/recvonly/inactive,
>>> as specified in rfc4566bis, is strongly linked (at least implicitly) 
>>> to how RTP works. To use them in this new context I think there needs to be a document that discusses the details.
>> 
>> https://protect2.fireeye.com/url?k=b884c745-e40d688c-b88487de-0cc47ad9
>> 3e1c-bbb30ee7a292c674&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-d
>> atachannel-t140%2Fpull%2F6
>
> That simply references RFC3264. 
>For instance, I need to consider this to be unicast. And there are lots of references to things that don't fit.
>
>I think it would be better to restate the parts of 3264 that apply, using the terms relevant to this usage. 
>Once it is stripped down to just the parts that pertain to directionality I don't think it will be a lot.
>

It seems like I didn't include everything that I was planning to. The idea is to reference 3264 *only for the offer/answer rules. E.g, if I offer X, than you must answer Y or Z.

The draft then defines the semantics when used for a T.140 data channel: the attribute indicates in what direction text can be transmitted.

If someone thinks we need more than that, feel free to suggest :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Aug 2019 14:48:19 -0400

> If someone thinks we need more than that, feel free to suggest :)

*At least* specify that the rules for *unicast* are to be followed.

But even that leaves a lot to interpretation. I think it would be better 
to copy the relevant text and reword it to fit with data channel usage.

For example, I trimmed section 5.1 of 3264 of all the stuff that doesn't 
apply, otherwise leaving it alone:

5.1 Unicast Streams

    If the offerer wishes to only send media on a stream to its peer, it
    MUST mark the stream as sendonly with the "a=sendonly" attribute.  We
    refer to a stream as being marked with a certain direction if a
    direction attribute was present as either a media stream attribute or
    a session attribute.  If the offerer wishes to only receive media
    from its peer, it MUST mark the stream as recvonly.  If the offerer
    wishes to communicate, but wishes to neither send nor receive media
    at this time, it MUST mark the stream with an "a=inactive" attribute.
    The inactive direction attribute is specified in RFC 3108 [3].
    If the offerer wishes to both send and
    receive media with its peer, it MAY include an "a=sendrecv"
    attribute, or it MAY omit it, since sendrecv is the default.

    Once the offerer has sent the offer, it MUST be prepared to receive
    media for any recvonly streams described by that offer.  It MUST be
    prepared to send and receive media for any sendrecv streams in the
    offer, and send media for any sendonly streams in the offer (of
    course, it cannot actually send until the peer provides an answer
    with the needed address and port information).  In the case of RTP,
    even though it may receive media before the answer arrives, it will
    not be able to send RTCP receiver reports until the answer arrives.

I removed the following:

    As per RFC 2327, fmtp parameters MAY be present to provide additional
    parameters of the media format.

You already enumerate specific uses of fmtp, so I think it is not 
needed. But I'm not certain if you intended to exclude other fmtp 
parameters.

What is left isn't too bad as is, but probably the "a=..." should be 
"a=dcsa:n ...".

I *didn't* remove the following:

    ... We
    refer to a stream as being marked with a certain direction if a
    direction attribute was present as either a media stream attribute or
    a session attribute.

That raises a question of whether a session-level directionality 
attribute applies to T140 data channels. I'm guessing that session level 
directionality does not apply so that the default is always sendrecv. If 
so, the above should be removed or modified.

Something similar would need to be done for sections 6.1, 7, and 8.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 19:23:45 +0000

Hi,

...

>>>> 3e1c-bbb30ee7a292c674&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F6
>>>
> But even that leaves a lot to interpretation. I think it would be better to copy the relevant text and reword it to fit with data channel usage.
>
> For example, I trimmed section 5.1 of 3264 of all the stuff that doesn't apply, otherwise leaving it alone:
>
> 5.1 Unicast Streams
>

I think the second paragraph would have to be modified. The offerer cannot receive or send any data until the data channel has been established, so there is no reason to be prepared for that prior.

And, we obviously don't need the text about RTP and RTCP.

> You already enumerate specific uses of fmtp, so I think it is not needed. But I'm not certain if you intended to exclude other fmtp parameters.

At the moment there is no need for anything else. 

> What is left isn't too bad as is, but probably the "a=..." should be "a=dcsa:n ...".
>
> That raises a question of whether a session-level directionality attribute applies to T140 data channels. 
> I'm guessing that session level directionality does not apply so that the default is always sendrecv. If so, 
> the above should be removed or modified.

At data channel is always bidirectional, so the only way to impact the directionality of a T140 data channel is by using the dcsa attribute.

> Something similar would need to be done for sections 6.1, 7, and 8.

I will take a look.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Aug 2019 15:48:27 -0400

On 8/29/19 3:23 PM, Christer Holmberg wrote:
> ....

Yeah, I screwed up. But you get the gist of what I'm suggesting.

> At data channel is always bidirectional, so the only way to impact the directionality of a T140 data channel is by using the dcsa attribute.

If we *wanted* to make the session level setting apply we could. It only 
affects how the two sides *use* the channel, not how it is set up.

I think the document should explicitly specify whether it does or does 
not apply.

>> Something similar would need to be done for sections 6.1, 7, and 8.

Thanks!

	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 29 Aug 2019 22:07:34 +0200

Hi,

Den 2019-08-29 kl. 21:48, skrev Paul Kyzivat:
>>>>> For instance, I need to consider this to be unicast. And there are 
>>>>> lots of references to things that don't fit.
>>>>>
>>>>> I think it would be better to restate the parts of 3264 that 
>>>>> apply, using the terms relevant to this usage.
>>>>> Once it is stripped down to just the parts that pertain to 
>>>>> directionality I don't think it will be a lot.
>>>>>
>>>> It seems like I didn't include everything that I was planning to. 
>>>> The idea is to reference 3264 *only for the offer/answer rules. 
>>>> E.g, if I offer X, than you must answer Y or Z.
>>>>
>>>> The draft then defines the semantics when used for a T.140 data 
>>>> channel: the attribute indicates in what direction text can be 
>>>> transmitted.
>>>>
>>> But even that leaves a lot to interpretation. I think it would be 
>>> better to copy the relevant text and reword it to fit with data 
>>> channel usage.
>>>
>>> For example, I trimmed section 5.1 of 3264 of all the stuff that 
>>> doesn't apply, otherwise leaving it alone:
>>>
>>> 5.1 Unicast Streams
>>>
>> I think the second paragraph would have to be modified. The offerer 
>> cannot receive or send any data until the data channel has been 
>> established, so there is no reason to be prepared for that prior.
>>
>>> attribute applies to T140 data channels.
>>> I'm guessing that session level directionality does not apply so 
>>> that the default is always sendrecv. If so,
>> At data channel is always bidirectional, so the only way to impact 
>> the directionality of a T140 data channel is by using the dcsa 
>> attribute.
>
> If we *wanted* to make the session level setting apply we could. It 
> only affects how the two sides *use* the channel, not how it is set up.
>

I initially got the inspiration to include the directional attributes 
from draft-ietf-mmusic-msrp-usage-data-channel-13

It defines use of them, and refers to RFC 4566 and RFC 4975 (MSRP) for 
the definition on how they are used for MSRP and the MSRP data channel.

It does not specify anything special for the session level use of the 
attribute.

It seems that you are on the way to do something similar for the T.140 
data channel. I intended to say that we can skip the direction 
attributes for the T.140 case, but now when I realize that they may 
appear on session level, I think it is important that we specify them 
and also say that they apply also when used on session level.

Gunnar

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 20:13:40 +0000

Hi,

Since session level direction has no impact on the SCTP association used to realize the data channels, in my opinion the session level direction should have no impact on those data channels either.

Instead, if one wants to use the direction attributes within a data channel, one MUST use include them in dcsa attributes.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic <[email-masked]> Puolesta Gunnar Hellström
Lähetetty: torstai 29. elokuuta 2019 23.08
Vastaanottaja: Paul Kyzivat <[email-masked]>; [email-masked]
Aihe: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel-gateway considerations - direction attributes

Hi,

Den 2019-08-29 kl. 21:48, skrev Paul Kyzivat:
>>> that the default is always sendrecv. If so, the above should be 
>>> removed or modified.
>>

I initially got the inspiration to include the directional attributes from draft-ietf-mmusic-msrp-usage-data-channel-13

It defines use of them, and refers to RFC 4566 and RFC 4975 (MSRP) for the definition on how they are used for MSRP and the MSRP data channel.

It does not specify anything special for the session level use of the attribute.

It seems that you are on the way to do something similar for the T.140 data channel. I intended to say that we can skip the direction attributes for the T.140 case, but now when I realize that they may appear on session level, I think it is important that we specify them and also say that they apply also when used on session level.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 29 Aug 2019 22:29:05 +0200

Hi,

I think you should look at the intention of the use of the attributes 
(as MSRP has done ) and not on their technical effect on RTP or SCTP.

The intention seems to be to have a way to mute participants.

If an application tries to mute the whole session, the expected function 
is that all media from that participant stops to flow regardless of what 
technology is used for the transport. It would look strange if RTT is 
still possible when other media are muted by the session level command.

Now, a question is if this is a way that is commonly used for the muting 
and unmuting function. I think it is, and thereby we should specify its 
function on application level, similar to what is done for the 
msrp-data-channel.

Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288