Re: [MMUSIC] Draft new version: T140-data-channel -02 - Use direction attributes on dcsa level

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 05 September 2019 12:28 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CFF120059 for <mmusic@ietfa.amsl.com>; Thu, 5 Sep 2019 05:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ildA5gqv5o6t for <mmusic@ietfa.amsl.com>; Thu, 5 Sep 2019 05:28:37 -0700 (PDT)
Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1FE120026 for <mmusic@ietf.org>; Thu, 5 Sep 2019 05:28:36 -0700 (PDT)
X-Halon-ID: a2531102-cfd8-11e9-bdc3-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id a2531102-cfd8-11e9-bdc3-005056917a89; Thu, 05 Sep 2019 14:28:16 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <74EDF323-AE38-4D58-8006-D50B89348CFA@ericsson.com> <a0d1110e-5be2-6e69-dbc4-9fd9f2995a47@omnitor.se> <204ae1d2-0b26-f711-5828-51a058735e3b@omnitor.se> <1d1717a2-e6f7-11bf-1735-d23984304eba@omnitor.se> <HE1PR07MB31616A9C3FA710049D0B557893BB0@HE1PR07MB3161.eurprd07.prod.outlook.com> <0d8903e5-d449-d6db-8e43-de4288e83e6b@omnitor.se> <26FA637B-9590-4CE5-A4BB-CAA27327626F@ericsson.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <2349bd04-4430-14fe-569d-507b4e8f7b5d@omnitor.se>
Date: Thu, 05 Sep 2019 14:28:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <26FA637B-9590-4CE5-A4BB-CAA27327626F@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/dvhLpQtLcoUztuVFrB0mtNVp1wo>
Subject: Re: [MMUSIC] Draft new version: T140-data-channel -02 - Use direction attributes on dcsa level
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 12:28:40 -0000

Hi,

Den 2019-09-05 kl. 10:55, skrev Christer Holmberg:
> Hi,
>
>> The issue here was my view:
>>
>> I think that session level direction attributes should work on T.140 data channels where
>> no direction attribute is set on the dcsa(t140) level.
> My view is still that session level attributes do not impact data channels.
>
> Also, IF we would session level attributes to impact data channels, I think it should be specified on a more generic level. I don't think it is a good idea to define rules for specific attributes (the direction attributes) for a specific data channel (the T.140 data channels). People could then define other rules for other session level attributes and/or data channels, and it could become very messy.

Right,

The logic I explain below is for the general case, deducted from wording 
in sdpneg and RFC4566bis and would be valid for any attribute that has 
both session and media level use and for any data channel that is an 
implementation of a subprotocol already specified for traditional SDP 
negotiated streams. The ambition when specifying sdpneg would naturally 
be to make life as simple as possible for authors of new data channel 
specifications so that already existing general sdp attributes can be 
reused without registration. The idea seems to be that a dcmap and its 
dcsa declarations together shall be treated similar to earlier media 
declarations for single media.

If you do not like the idea of a session level attribute influencing the 
data channel, I think you need to write an explanation that limits this 
interpretation of sdpneg and RFC4566bis.

Please see the logic below.

I am not especially eager for the T.140 data channel to be possible to 
influence by session level attributes, but I see a risk that it gets 
messy for implementers when they find that for some media (audio, video 
?), the session level attributes work, but not for others (T.140 data 
channel). Brian also asked for having equal influence for audio, video 
and real-time text.


>
> But, I'd also like to hear what others think :)
Yes.
>
> Regards.
>
> Christer

Regards

Gunnar

>
>
> Den 2019-09-05 kl. 03:20, skrev Christer Holmberg:
> Hi,
>   
> What part sdpneg-23 do you think is trying to say that?
> It is in sdpneg-28 and RFC4566bis
> It requires some steps of logic that you may find weak:
> 1. sdpneg talks a lot about a "subprotocol" concept as if it exists also outside of the data channels. I assume that we can see "t140" as the subprotocol in our case, and that it was defined in RFC 4103 that is RTP transport of the t140 subprotocol and MIME media declared as text/t140.
> 2. In section 5.2 and 5.2.1, there is a lot of wording trying to describe how already specified general attributes that are used for the subprotocol on media level are automatically accepted with the same semantics when used on dsca(subprotocol) level. No IANA registration would be needed.
> It is for example section 5.2.1 "DCSA Syntax" in draft-ietf-mmusic-data-channel-sdpneg
> saying:
> "
> It is assumed that in general the usages of subprotocol related media
>     level attributes are independent from the subprotocol's transport
>     protocol.  Such transport protocol independent subprotocol related
>     attributes are used in the same way as defined in the original
>     subprotocol specification, also if the subprotocol is transported
>     over a data channel and if the attribute is correspondingly embedded
>     in a "a=dcsa" attribute.
>
> "
> 3. RFC 4566bis, section 6.7 moves the direction attributes from session level to be applied to the media description if no direction attribute was declared on media level.
> 6.7.  Media Direction Attributes
>
>     At most one occurrence of recvonly, sendrecv, sendonly, or inactive
>     MAY appear at session level, and at most one MAY appear in each media
>     description.
>
>     If any one of these appears in a media description then it applies
>     for that media description.  If none appear in a media description
>     then the one from session level, if any, applies to that media
>     description.
> 4. Combining 2. and 3. results in the session level attributes are applied automatically on the dsca(subprotocol) level, e.g. the direction attributes on the t140 subprotocol.
>
> 5. This deduction also has the side effect that we do not need to IANA specify all usage of general SDP attributes which already were possible on the RTP/TEXT/t140 subprotocol, as long as it is used without change in semantics.
>
> Regards
> Gunnar
>   
> Regards,
>   
> Christer
>   
> Lähettäjä: Gunnar Hellström mailto:gunnar.hellstrom@omnitor.se
> Lähetetty: torstai 5. syyskuuta 2019 0.23
> Vastaanottaja: Christer Holmberg mailto:christer.holmberg@ericsson.com; mailto:mmusic@ietf.org
> Aihe: Re: [MMUSIC] Draft new version: T140-data-channel -02 - Use direction attributes on dcsa level
>   
> (sorry, I forgot to change topic)
> Den 2019-09-04 kl. 23:20, skrev Gunnar Hellström:
> Hi,
> This is another topic for discussion:
> I think that session level direction attributes should work on T.140 data channels where no direction attribute is set on the dcsa(t140) level.
> RFC 4566bis seems to expect that. It is written as if it was defining that session level attributes if specified should govern in the whole session.
> And I think that the sdpneg-23 draft tries to say that attributes defined for general session and media level use should be allowed to work on DCSA level for any subprotocol without further specification or registration.
> Regards
>   
> Gunnar
>   
>   
>   
> It should be discussed what happens if there is a direction attribute on media level in the media declaration for the SCTP declaration.. Probably a similar statement as for session level is needed.
> Den 2019-09-04 kl. 23:03, skrev Gunnar Hellström:
> Hi,
> I have created a number of pull requests to the GitHub repository for  draft-holmberg-mmusic-t140-usage-data-channel-02
> Many are editorial. A few require discussion in the list.
>   
> Regards
> Gunnar
>   
> Den 2019-09-03 kl. 14:10, skrev Christer Holmberg:
> Hi,
>   
> I have mereged the following PR:
>   
> https://protect2.fireeye.com/url?k=bb2745e9-e7b548b5-bb270572-0cc47ad93d46-f9e326b54116c066&q=1&u=https://github.com/cdh4u/draft-datachannel-t140/pull/6
>   
> …and submitted a new version (-02) of draft-holmberg-mmusic-t140-usage-data-channel.
>   
> The main changes are:
>   
> - IANA registry update for SDP attributes that can be included in dcsa attributes
> - Detailed procedures on usage of the direction attributes inside dcsa attributes
>   
> Regards,
>   
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> mailto:mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288