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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 29 August 2019 08:13 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 29D3B12080F for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 01:13:19 -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 JVzWMZWGc_cN for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 01:13:15 -0700 (PDT)
Received: from bin-mail-out-06.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 2D16A1200E0 for <mmusic@ietf.org>; Thu, 29 Aug 2019 01:13:14 -0700 (PDT)
X-Halon-ID: d59439d5-ca34-11e9-837a-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id d59439d5-ca34-11e9-837a-0050569116f7; Thu, 29 Aug 2019 10:13:08 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <3a2b4d58-7643-af3f-dda3-ea18fe65a0df@omnitor.se>
Date: Thu, 29 Aug 2019 10:13:09 +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: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/7Kz6r7hasS0sh3EGzwcHz42UqiY>
Subject: [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 08:13:28 -0000

Hi,

Yesterday, I reviewed and commented in GitHub a good set of modification 
proposals from Christer.

I was a bit vague in a few of them, so I want to straighten up and be 
more clear about what I said in a few comments. I also have some further 
thoughts.

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.

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.

Regards

Gunnar

Den 2019-08-09 kl. 19:41, skrev Christer Holmberg:
> Hi,
>
> Once upon a time in MMUSIC, there was work on a draft named draft-schwarz-mmusic-t140-usage-data-channel.
>
> Then, the authors stopped working on it, and nobody has been willing to take over.
>
> The draft is a 3GPP dependency, so there is a need to get it finalized.
>
> Some time ago I decided to take a close look at the draft, so see how much work it would take to finalize. One thing led ted to another, and I ended up re-writing the draft. Say hello to draft-holmberg-mmusic-t140-usage-data channel:
>
> https://www.ietf.org/id/draft-holmberg-mmusic-t140-usage-data-channel-00.txt
>
> The holmberg draft is based on the schwarz draft (also mentioned in the Acknowledgements), and much of the content is still the same. However, I have done editorial changes, and some re-structuring in order to better separate between the SDP considerations and the T.140 considerations.
>
> The NEW technical stuff is describing how the T.140 abstract service functions map to T.140 data channels established with SDP O/A.
>
> I have removed much of the Gateway text, because that's where most of the open issues were. That way, I also got rid of the dependency on draft-ietf-rtcweb-gateways, a draft I doubt is ever going to get finalized. If needed, gateway functions can be specified elsewhere, and 3GPP has already defined the H.248 parts for interworking between T.140 data channel and RFC 4103.
>
> There are currently no open issues in the draft.
>
> Regards,
>
> Christer
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-