Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes
Flemming Andreasen <fandreas@cisco.com> Mon, 02 July 2007 21:58 UTC
Return-path: <mmusic-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TuG-0000Hy-MW; Mon, 02 Jul 2007 17:58:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TuF-0000Ht-H6 for mmusic@ietf.org; Mon, 02 Jul 2007 17:58:03 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Tu2-00041n-81 for mmusic@ietf.org; Mon, 02 Jul 2007 17:58:03 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2007 14:57:49 -0700
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AusRABYRiUarR7O6/2dsb2JhbACIV6Mc
X-IronPort-AV: i="4.16,489,1175497200"; d="scan'208"; a="499535054:sNHT31560200"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l62LvnCW015779; Mon, 2 Jul 2007 14:57:49 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l62Lvnka000391; Mon, 2 Jul 2007 21:57:49 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 14:57:48 -0700
Received: from [10.21.83.42] ([10.21.83.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 14:57:48 -0700
Message-ID: <468974DC.10801@cisco.com>
Date: Mon, 02 Jul 2007 17:57:48 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Matt Lepinski <mlepinski@bbn.com>
Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes
References: <467FF7A8.6040303@cisco.com> <4682A2A7.8000606@bbn.com>
In-Reply-To: <4682A2A7.8000606@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Jul 2007 21:57:48.0626 (UTC) FILETIME=[07715B20:01C7BCF4]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3091; t=1183413469; x=1184277469; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20<fandreas@cisco.com> |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#1=3A=20To=20Add, =20De lete=20and=20Replace=20Attributes |Sender:=20; bh=nWiLwNJ2aXuAqj7X1Lu3y1A4JmrRohcmFrK0OywteyY=; b=lA3Oh4vy5DUVgiiaMp6ASZaMqzcG+tFA8S56sZNXZfcOjQfqvPml8KpauWiiwVxeIiE4N8nS aVWz1QQ5X282b47WENYYjfX2sGDLw8NUe38aVU7pa2WyIYcbYzD9fI/+;
Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: mmusic <mmusic@ietf.org>
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org
Matt Lepinski wrote: > Flemming, > > Thanks for producing a draft that captures the motivation for deletion > of attributes in capability negotiation. > > I also think that Option (B) is a good comprise that solves the > problem without the perception of unnecessary complexity which seems > to burden Option (A). > > The only downside of Option (B) seems to be that, unlike in Option > (C), if deletion is used then one needs an a=acap line for attribute > for every attribute, even those present in all potential configurations. Right. > > For example: > > v=0 > o=alice 2890844526 2890842807 IN IP4 10.0.0.1 > s=Example SDP > t=0 0 > c=IN IP4 10.0.0.1 > m=audio 51000 RTP/SAVP 0 99 > a=crypto:1 AES_CM_128_HMAC_SHA1_32... > a=ptime:30 > a=rtpmap:99 L16/8000 > a=tcap:1 RTP/AVP > a=acap:1 a=ptime:30 > a=acap:2 a=rtpmap:99 L16/8000 > a=pcfg:1 t=1 a=-m:1,2 > > The above is an offer indicating a preference for RTP, and a > willingness to accept an S-RTP audio stream. Since we need to delete > the crypto attribute from the potential RTP configuration (and since > in Option B we have only clean-slate delete-all-attributes available) > we need to add a=acap lines for the a=ptime and a=rtpmap attributes. > > Adding these additional lines is a bit inefficient, but it doesn't > seem like a serious problem to me. However, if someone has a use-case > where deletion is required and yet the inefficiency of option (B) is > unacceptable, then I'd be willing to support Option (C). OK - thanks -- Flemming > > - Matt Lepinski :-> > > Flemming Andreasen wrote: > >> Probably the biggest open issue we have in the SDP Capability >> Negotiation Framework at this point is the ability to replace and >> delete attributes from an actual configuration SDP when generating a >> potential configuration. At the Prague IETF, people asked for some >> more motiviation and use cases for this feature before deciding >> whether we should include it in the core capability negotiation >> framework or not. I have written a short I-D in the subject, which >> you can find at: >> >> >> http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att-del-00.txt >> >> >> Please take a look at this and let me know how you think we should >> resolve this issue. Options include: >> >> A) Remove the ability to delete and replace attributes completely. >> B) Remove the ability to delete and replace individual attributes, >> but allow for complete removal of all attributes (clean slate) >> C) Keep the current ability to delete and remove individual and all >> attributes. >> >> My personal preference is for option A, however in the interest of >> moving forward and making a reasonable compromise between >> functionality and complexity, my recommendation is option B. >> >> Thanks >> >> -- Flemming >> >> >> >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and R… Flemming Andreasen
- Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete a… Matt Lepinski
- RE: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete a… Elwell, John
- RE: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete a… Even, Roni
- Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete a… Flemming Andreasen
- Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete a… Flemming Andreasen
- RE: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete a… Even, Roni
- Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete a… Flemming Andreasen