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

Flemming Andreasen <fandreas@cisco.com> Mon, 02 July 2007 22:05 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 1I5U1d-0000XH-Gq; Mon, 02 Jul 2007 18:05:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5U1b-0000Pc-Ni for mmusic@ietf.org; Mon, 02 Jul 2007 18:05:39 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5U1W-0007D4-VB for mmusic@ietf.org; Mon, 02 Jul 2007 18:05:39 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2007 15:05:34 -0700
X-IronPort-AV: i="4.16,489,1175497200"; d="scan'208,217"; a="175756232:sNHT91404513"
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 l62M5YIr028004; Mon, 2 Jul 2007 15:05:34 -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 l62M5Jl8005777; Mon, 2 Jul 2007 22:05:34 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 15:05:25 -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 15:05:25 -0700
Message-ID: <468976A5.1060608@cisco.com>
Date: Mon, 02 Jul 2007 18:05:25 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: "Even, Roni" <roni.even@polycom.co.il>
Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes
References: <144ED8561CE90C41A3E5908EDECE315C04AFCE9B@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04AFCE9B@IsrExch01.israel.polycom.com>
X-OriginalArrivalTime: 02 Jul 2007 22:05:25.0401 (UTC) FILETIME=[17B3B090:01C7BCF5]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9706; t=1183413934; x=1184277934; 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=iGe7OQUXgZCSKGCIG7YV6/NdMx6tYF6uSK5cPovqfgc=; b=weWhxTr/mfM1koINnbuNxJ6bEqzliCduLprzzVG1/mRqdz/9TAE1ycjQIWBXRBEJFlhc3YR8 O+ZHczG2ofieNGK6g2cd/6v2+LbuGRl3wDJHZiB2IALlBzO0mvf9J+md;
Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
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>
Content-Type: multipart/mixed; boundary="===============0579339902=="
Errors-To: mmusic-bounces@ietf.org


Even, Roni wrote:
> Flemming,
> I reviewed the draft and from the option I think I prefer B but am not sure what it will mean. My preference is described here.
>
> My view is that the replace problem can be solved by implied behavior. The delete cases are more problematic.
>
> The replace - if you have in the potential configuration the same payload type in the fmpt or rtpmap as in the SDP than if using an actual configuration from the potential configuration it implies that it replaces the fmtp and rtpmap from the SDP. 
> This means that if in the SDP there is fmtp and rtpmap while in the actual configuration there is only rtpmap for the same payload type than both attributes from the SDP are replaced by only rtpmap.
>   
Doing so requires logic and processing that is really outside the scope 
of core capability negotiation framework, which I believe is why we have 
seen pushback on these kinds of features. It may be more sensible to 
adopt what you describe above as an enhancement that can be used by the 
media capabilities extension.

> The general case is that same attribute in the SDP and in the actual configuration are implicitly replaced.
>   
The problem is that "same attribute" is too vague and also doesn't quite 
do what you want some times. For example, you are not replacing all 
"rtpmap" attributes in your example above, only the ones with the same 
payload type and you then furthermore couple if with corresponding 
"fmtp" attributes. We have other potential examples with different 
attribute names (think about direction attributes, comedia, etc.).

> In the case of delete, your example shows the difficult part when the attributes do not have the same name or a using the same payload type. The duplication is based on similar semantics. It may be enough to leave it as you suggest in section 4 of your contribution but I would not object to real delete.
>   
Me neither, but we don't seem to have consensus to go that far in the 
core document.
>  
>
> As for the point about if both should be addressed in the core document. I suggest yes since we will need it and I think that the replace problem is easier based on my description.
>   
See above - again, I think we need to address these as part of a more 
sophisticated extension (e.g. media capabilities).

Thanks

-- Flemming

> Roni
>
>   
>> -----Original Message-----
>> From: Flemming Andreasen [mailto:fandreas@cisco.com]
>> Sent: Monday, June 25, 2007 8:13 PM
>> To: mmusic
>> Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace
>> Attributes
>>
>> 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