Re: [MMUSIC] [mmusic-t140-usage-data-channel]: "a=dcsa" for T.140 cps parameter
Gunnar Hellström <gunnar.hellstrom@omnitor.se> Tue, 06 October 2015 17:00 UTC
Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6567D1ACEE5 for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 10:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 h9YBNlA77Zeg for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 09:59:58 -0700 (PDT)
Received: from bin-vsp-out-04.atm.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 9C7A81ACEE0 for <mmusic@ietf.org>; Tue, 6 Oct 2015 09:59:57 -0700 (PDT)
X-Halon-ID: a7fb6fd9-6c4b-11e5-bfe4-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 6 Oct 2015 18:59:50 +0200 (CEST)
To: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <786615F3A85DF44AA2A76164A71FE1ACDF796701@FR711WXCHMBA01.zeu.alcatel-lucent.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <5613FE05.90900@omnitor.se>
Date: Tue, 06 Oct 2015 18:59:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACDF796701@FR711WXCHMBA01.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/PlnAkN9blK6cQ8G1Kn6DTLEWpg0>
Subject: Re: [MMUSIC] [mmusic-t140-usage-data-channel]: "a=dcsa" for T.140 cps parameter
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 06 Oct 2015 17:00:00 -0000
Den 2015-10-06 kl. 10:15, skrev Schwarz, Albrecht (Albrecht): > Dear All, > > the discussion about "SDP limitations" at SLIM (see > https://mailarchive.ietf.org/arch/msg/slim/C-82-NRgfR50mVTkM_wklrKw0SY ) > spotted an issue in draft-schwarz-mmusic-t140-usage-data-channel-02.txt > related dcsa usage: > > We've used (in clause 5.1.1.3. Example SDP Negotiation) > a=dcsa:1 cps=30 > which misses the fmtp parameter (see RFC 4103). > > It was proposed to use instead e.g. > a=dcsa:1 fmtp:- cps=30 > > The reason why we omitted the fmtp parameter is the fact that the binding is already provided by the dcsa stream-id value, hence fmtp is not required, just introduces redundancy. > > However, we will update the example as suggested by Christian due to consistency reasons with draft-ietf-mmusic-data-channel-sdpneg: > Syntax: > dcsa-value = stream-id SP attribute > attribute = <from-RFC4566> Is this really a sufficient way to describe the attribute? When used directly in sdp, fmtp: is supposed to have a format number as parameter, then followed by format specific parameters specified in RFC 4102 and RFC 4103. The format specific parameters can be the redundancy format list and the cps= parameter. Questions: 1. Is it specified somewhere that the dash - can be used to represent one or more parameter(s) that can be ignored? 2. Is it sufficient to describe as above that the attribute has its syntax from RFC 4566? Or would RFC 4102 and RFC 4103 also need to be mentioned to explain the structure of the fmtp: parameters for this codec? 3. If it is problems to specify a direct mapping of this fmtp attribute, can instead an attribute native to the subprotocol be specified and its mapping to the fmtp parameter be specified in the gatewaying specification? /Gunnar > > Any further comments? > Albrecht > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] [mmusic-t140-usage-data-channel]: "a=dcs… Schwarz, Albrecht (Albrecht)
- Re: [MMUSIC] [mmusic-t140-usage-data-channel]: "a… Gunnar Hellström