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