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:fandreas <at> 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 <at> 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 <at> ietf.org

https://www1.ietf.org/mailman/listinfo/mmusic