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

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

(I changed the subject)

Hi,

>>>     2. Sendonly, recvonly, etc
>>>     
>>>     On the RTP side, there is a possibility to express directions in SDP by
>>>     the sendonly etc. attributes. I think I have seen them used in RFC 4103
>>>     implementations.
>>>     
>>>     Will these attributes automatically be possible to use in the T.140 data
>>>     channel? I guess not, because it is not really said that the T.140 data
>>>     channel tries to be a replica of the RFC 4103 RTP transport with all its
>>>     possible attributes. Some of the attributes enabled for RFC 4103 may be
>>>     of application interest for the T.140 data channel application, while
>>>     others are of little or no interest or irrelevant. I am afraid that we
>>>     need to go through possible attributes and mention the relevant ones in
>>>     a general section on attributes, and then IANA-register the use. (this
>>>     relates also to the current discussion in another thread about IANA
>>>     registration of attributes for data channels).  The msrp-data-channel
>>>     draft has a section on sendonly etc. I suggest that we also include one.
>>    
>> 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.
  
So, we will add dcsa usage for "sendonly", "recvonly", "sendrecv" and "inactive" in the next version.

And, to the gateway section we will add a statement saying that the gateway MUST NOT change the values from one side to another.

Regards,

Christer