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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sun, 08 September 2019 06:57 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 72B041200B3 for <mmusic@ietfa.amsl.com>; Sat, 7 Sep 2019 23:57:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 JG94U1Iut2-c for <mmusic@ietfa.amsl.com>; Sat, 7 Sep 2019 23:57:24 -0700 (PDT)
Received: from bin-mail-out-05.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 3FB0D120018 for <mmusic@ietf.org>; Sat, 7 Sep 2019 23:57:24 -0700 (PDT)
X-Halon-ID: e351a690-d205-11e9-903a-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id e351a690-d205-11e9-903a-005056917f90; Sun, 08 Sep 2019 08:57:14 +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> <2349bd04-4430-14fe-569d-507b4e8f7b5d@omnitor.se> <26B042B8-9D9B-4463-81D2-59F681C162BD@ericsson.com> <0bbb474c-e2a3-f0bc-1da9-1cfda88deb7e@omnitor.se> <26342749-5CD6-4C54-8FE6-70669179DF67@ericsson.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <b74913b2-21e1-cef5-3dbd-fbb715d562ea@omnitor.se>
Date: Sun, 08 Sep 2019 08:57:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <26342749-5CD6-4C54-8FE6-70669179DF67@ericsson.com>
Content-Type: multipart/alternative; boundary="------------3774672E9FD7D462BE745671"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/_LN8D3P-aDoHj-ccIruN05JEZ2E>
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: Sun, 08 Sep 2019 06:57:29 -0000

Hi,

1. I can accept to not use the direction attributes on session level 
since you think it is messy, and I think it is right to specify that it 
is not used, as now last in section 3.2.3.

2. I can accept to mention that the o/a procedures are based on RFC 3264 
, but I think the first mentioning of RFC 3264 in section 3.2.3 first 
paragraph is too strong and should be deleted. The mentioning of RFC 
3264 in the third paragraph can be kept and would be sufficient.

3. I think the second note in section 3.2.3 is not needed. Readers 
surely understand that the dcsa attribute only apply to the data channel 
it is included in.

4. Since there seems not to be any way to convey the specified dcsa 
attributes fmtp, hlang-send, hlang-recv and the directions through the 
currently specified W3C API, I suggest that a warning about this 
condition is inserted in section 3.2 in a way so that we do not get a 
strict dependency on the W3C document. An initial proposal can be: 
"NOTE: In order for the dcsa attributes to be useful in an application, 
the application needs to have means for setting and interrogating them."

5. In 3.2.1, first paragraph, about fmtp, it is said that 'fmtp' can be 
used to set 'cps'. By the end it says "The 'format' attribute parameter 
is not used with T.140 data channels, and MUST be set to "-".  Do you 
think it is clear enough that this MUST is only valid when an 'fmtp' 
attribute is used. If you don't, then that should be explicitly stated.


If you accept 1,2,3 above, section 3.2.3 could be modified to:

"

3.2.3.  Real-time Text Direction

    'dcsa' attributes can contain the SDP 'sendonly', 'recvonly',
    'sendrecv' and 'inactive' attributes [RFC4566] to negotite the
    direction in which text can be transmitted in a real-time text
    conversation.

    NOTE: A WebRTC data channel is always bi-directional.  The usage of
    the 'dcsa' attribute only affects the direction in which
    implementations are allowed to transmit text on a T.140 data channel.

    The offer/answer rules for the direction attributes are based on the
    rules for unicast streams defined in [RFC3264], as described below.
    Note that the rules only apply to the direction attributes.

    Session level direction attributes [RFC4566] have no impact on a
    T.140 data channel.  An offerer and answerer MUST mark the direction
    of the text by sending a direction attribute inside aEUR~dcsa-
    attribute.
"

Regards

Gunnar

Den 2019-09-07 kl. 07:24, skrev Christer Holmberg:
> Hi,
>
> ...
>
>>> Section 9.2 of raft-ietf-mmusic-sctp-sdp (that defines the generic O/A procedures for negotiating SCTP associations) says:
>>>
>>> "9.2.  SDP sendrecv/sendonly/recvonly/inactive Attribute
>>>
>>>    This specification does not define semantics for the SDP direction
>>>    attributes [RFC4566].  Unless semantics of these attributes for an
>>>    SCTP association usage have been defined, SDP direction attributes
>>>    MUST be ignored if present."
>> That contradicts sdpneg 5.2, saying:
>> "
>> 5.2.  SDP DCSA Attribute
>>
>>    In the SDP media description, each data channel declaration MAY also
>>    be followed by other media level SDP attributes, which are either
>>    specifically defined for or applied to the subprotocol in use.
>> "
>>
>> We are discussing a general media level attribute, which we also have specified the use of.  So it is good for both cases mentioned in the last line.
> As far as I understand, the text talks about including attributes in the dcsa attribute, and such attribute could be a generic attribute applies to the data channel, or an attribute defined for the data channel. But, in both cases they are included in the dcsa attribute.
>
>>> draft-ietf-rtcweb-data-channel defines such SCTP usage (the RTCWEB data channel), and draft-ietf-mmusic-data-channel-sdpneg
>>> defines the O/A procedures for negotiating such data channels.
>>>
>>> *Neither* of those drafts defines semantics for the SDP direction attributes (please correct me if I'm wrong).
>>>
>>> Therefore, I don't think we can then in the T.140 data channel draft can define such semantics for session/media level direction attributes.
>>    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.
>>>   
>>> The purpose of dcsa is to apply attributes to a specific data channel.
>>>   
>>>>    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.
>>>   
>>> I think the text I copy/pasted above provide such explanation: the SCTP association usage needs to define the semantics
>>> of the direction attributes, and the draft defining the RTCWEB data channel association usage do not define such semantics.
>>>
>>> So, it is not only about what I like and don't like - I don't think it's permitted :)
>> If it is not permitted, we should discuss with the authors of draft-ietf-mmusic-msrp-usage-data-channel-13
>>
>> In https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-13#section-5.1.1.2.  Use of the
>> dcsa Attribute, it is said:
>> ...
>> An offerer and answerer MAY include a dcsa attribute for the
>> following MSRP-specific SDP attributes, following the procedures
>>   defined for each attributes:
>>
>>    o  defined in [https://tools.ietf.org/html/rfc4975]: "accept-types", "accept-wrapped-types" and
>>       "max-size"
>>
>>    o  defined in [https://tools.ietf.org/html/rfc4566]: "sendonly", "recvonly", "inactive" and
>>       "sendrecv"
>>
>> -----------------------------------------
>> If it is not permitted, the last bullet point would not be allowed.
> Why not? That text is also about including attributes in a dcsa attribute.
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic