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

Even, Roni wrote:
>
> Flemming,
>
> I see no problem in describing the behavior of rtpmap and fmtp in the 
> media draft but it will require that the core document will not define 
> any policy that is contradictory.
>
Right.
>
> That will mean that the core document will explicitly leave potential 
> m-line support for the media document. This is true if option A is 
> selected.
>
>  
>
> If the consensus will be to option B for full delete it will mean that 
> you will have to repeat the rtpmap and fmtp in potential configuration 
> like Matt mentioned in his email so it is not even a question of replace.
>
Right.
>
>  
>
> My personal view is to use option A for delete based on your 
> suggestion in section 4 of your draft and to leave the replace option 
> to the media document.
>
> It looks to me that this is also your view.
>
My suggestion in the draft is for option B, which is what I suggested in 
the e-mail thread here as well, i.e. a global delete. As you note, 
replace will be left for extensions.

Thanks

-- Flemming

PS:  In the original e-mail below, I incorrectly said that my personal 
preference was for for option A, however I meant option C (which is also 
what the draft suggests). It doesn't change my recommendation for option 
B though, which seems to be where consensus is at this point as well 
(based on the other responses, it seems people understood what I meant). 
Sorry for the confusion.

>  
>
> Roni
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Flemming Andreasen [mailto:fandreas@cisco.com]
> *Sent:* Tuesday, July 03, 2007 1:05 AM
> *To:* Even, Roni
> *Cc:* mmusic
> *Subject:* Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace 
> Attributes
>
>  
>
>
>
> 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 <mailto:mmusic@ietf.org>
>> https://www1.ietf.org/mailman/listinfo/mmusic
>>     
>  
>   