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

From: "Even, Roni" <[email-masked]>
Date: Mon, 2 Jul 2007 09:33:12 +0300

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.
The general case is that same attribute in the SDP and in the actual configuration are implicitly replaced.

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.

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.

Roni

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 02 Jul 2007 17:57:48 -0400

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:
>
>> 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 
>>
>>
>> B) Remove the ability to delete and replace individual attributes, 
>> but allow for complete removal of all attributes (clean slate)
>> moving forward and making a reasonable compromise between 
>> functionality and complexity, my recommendation is option B.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>
>>
>>
>>
>>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 02 Jul 2007 18:05:25 -0400

> 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…
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

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 3 Jul 2007 10:09:54 +0300

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. 

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.

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.

Roni

________________________________

From: Flemming Andreasen [mailto:[email-masked]] 
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,

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

Me neither, but we don't seem to have consensus to go that far in the core document. 

 

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:[email-masked]]
	Sent: Monday, June 25, 2007 8:13 PM
	To: mmusic
	Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace
	Attributes

	 

	 
	Thanks
	 
	-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 03 Jul 2007 15:18:42 -0400

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.
>
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:[email-masked]]
> *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,
> 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 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.).
>
>
>> [email-masked] <mailto:[email-masked]>