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

[Christer Holmberg <[e-mail]>]

Hi,

(I am currently in US on a business trip, which is the reason it may take a while for me to reply)

> 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.

Ok. I can remove the mentioning in the 1st paragraph, as you suggest below.

> 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.

Ok. I can remove it. 

If someone things it needs to be mentioned, perhaps a generic note can be added to section 3.2 instead.

> 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."

I think readers surely understand that :)

Instead, I'd suggest to add a note specifically mentioning that the current version of the W3C API does not support it.

> 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. 

I will clarify it.

Regards,

Christer



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
mailto:[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic