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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 29 August 2019 09:07 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 C6B3A1200FF for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 02:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 9eC5Weq1Q5Ym for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 02:07:38 -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 EA5DB1200D8 for <mmusic@ietf.org>; Thu, 29 Aug 2019 02:07:37 -0700 (PDT)
X-Halon-ID: 6e7c7f1c-ca3c-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 6e7c7f1c-ca3c-11e9-903a-005056917f90; Thu, 29 Aug 2019 11:07:32 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <3a2b4d58-7643-af3f-dda3-ea18fe65a0df@omnitor.se> <4A020B23-0BFE-4658-8A1C-2F05F960CED2@ericsson.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <fb97da6c-4ca0-c6c7-101f-802d9b38ba20@omnitor.se>
Date: Thu, 29 Aug 2019 11:07:31 +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: <4A020B23-0BFE-4658-8A1C-2F05F960CED2@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/IeZ-sga0rMcl_e3nodexcIfTVCQ>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel-gateway considerations
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, 29 Aug 2019 09:07:41 -0000

Hi Christer,

Den 2019-08-29 kl. 10:37, skrev Christer Holmberg:
> Hi Gunnar,
>      
>>     1. Keep-alive.
>>     
>>     In the gateway considerations section, there were a few sentences about
>>     keep-alive. It was stated that RFC 4103 does not specify any need for
>>     keep-alive. That is true, but because RFC 4103 specifies that
>>     transmission occurs only when there is text to transmit, there will be a
>>     need for keep-alive traffic in many network configurations. On the data
>>     channel side, this is implied in the WebRTC data channel, but on the RTP
>>     side, the need for keep-alive must be considered. This is mentioned in
>>     RFC 6263, where RTCP multiplexing is recommended as the preferred
>>     option. Most current RFC 4103 implementations however send keep-alive by
>>     sending the Unicode BOM character at suitable intervals, and these
>>     should be extracted and deleted by a gateway on the way from RTP to the
>>     data channel.
>>     
>>     Even if we have said that we cannot have all gateway considerations
>>     documented here, I suggest that a couple of words about RFC6263
>>     mentioning the possible need for keep-alive on the RTP side are inserted.
>    
> The text in -01 says that the gateway may have to extract keep-alives from, and MAY add keep-alives to, the RTP stream.
>
> We can for sure reference mechanisms normally used to implement 4103 keep-alives.
>
> But, if you want to define *generic* recommendations/guidance regarding keep-alives on 4103 streams I think that shall be done in an update to 4103. There is nothing data channel gateway specific about that.
Yes, -01 does not say anymore that RFC 4103 does not specify keep-alive. 
So, by that, mentioning that stripping and inserting it might be needed 
on the RTP side as done in -01 is sufficient. Fine.
>
> ---
>    
>>     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.

Regards

Gunnar

>
> Regards,
>
> Christer
>      
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic