Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes

Matt Lepinski <mlepinski@bbn.com> Wed, 27 June 2007 17:47 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 1I3bcM-0004uu-F3; Wed, 27 Jun 2007 13:47:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bcL-0004tZ-36 for mmusic@ietf.org; Wed, 27 Jun 2007 13:47:49 -0400
Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3bbr-0006Kr-R4 for mmusic@ietf.org; Wed, 27 Jun 2007 13:47:49 -0400
Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <mlepinski@bbn.com>) id 1I3bbr-0004zC-51; Wed, 27 Jun 2007 13:47:19 -0400
Message-ID: <4682A2A7.8000606@bbn.com>
Date: Wed, 27 Jun 2007 13:47:19 -0400
From: Matt Lepinski <mlepinski@bbn.com>
Organization: BBN
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes
References: <467FF7A8.6040303@cisco.com>
In-Reply-To: <467FF7A8.6040303@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
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

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.

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).

- 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