Re: [MMUSIC] SDP Capabilities Negotiation : Delete attributes

[Bob Gilman <[e-mail]>]

Flemming, Ingemar-
We tried to minimize the need for the deletion option in the
media capabilities draft (ID-ietf-mmusic-sdp-media-capabilities-03)
with specific rules for mcap/rtpmap, mfcap/fmtp and mscap (attributes
that are tied to <fmt>) or for bandwidth types.  That still doesn't
avoid the types of cases Flemming points out where one attribute
applies to the base configuration and an incompatible one applies
to a potential configuration.  The only way to avoid deletion
completely is to make the base configuration a "throwaway" with no
attributes (other than the implied defaults), and put all the
attributes into potential configurations.  That's not very attractive
at a time when most endpoints don't recognize the capabilities
attributes, but one would hope capability negotiation will be
ubiquitous in the near future.  This really points out that we have
two ways of expressing a potential configuration: the base way
with the m-line, and the a=pcfg way, and we have no good way of
selectively referring to a base-level attribute from a potential
configuration attribute.

One could use the delete option always, and then duplicate any needed
base attributes in acap lines.  At worst, this means the base level
attributes appear twice: once in an "a=<attr>" line, and once in
an "a=acap <attr>" line.  Look at the second example in section 4.1
of the media-capabilities draft: if we had to duplicate attributes,
we'd have to duplicate all the a=candidate lines.

This hasn't been an easy problem to solve in a way that maintains
optimum compactness.  Perhaps we need more discussion on the rules
for addition, deletion, or replacement.
-Bob
-------------------------------------------------------------
Bob Gilman        [e-mail]      [phone]

Flemming Andreasen wrote:
> 
> 
> Ingemar Johansson S wrote:
>>
>> Hi
>>
>> I have some questions regarding the delete attributes mentioned 
>> section 3.5.1 (page 24) as I still after reading through the same text 
>> a few times may have misunderstood:
>>
>> The example
>>   a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5]
>> My interpretation is : delete all the attributes on media level and 
>> specify the new attributes. Is this correct ?
>>
> That's correct.
> 
>> When is this needed ?, is the projected use case that one send a 
>> reinvite with a new SDP. I miss some text that actually motivates the 
>> use of the delete attributes option.
>>
> The motivation is provided in Section 3.6.2. Section 3.76 and 3.13.1 
> provide additional specific use cases. Briefly, the use case is when you 
> have SDP attributes in the actual configuration SDP that may conflict or 
> interfere with SDP attributes from a potential configuration SDP. For 
> example, my actual configuration may include an rtpmap attribute that 
> maps payload type 96 to codec A, but another potential configuration 
> maps it to payload type B. Another example is that I propose use of 
> MIKEY as the keying method (using a=kmgmt) for an SRTP stream as the 
> actual configuration, however my potential configuration uses 
> sdescriptions, or perhaps vanilla RTP instead; to be on the case side, 
> we remove the kmgmt attribute using delete-attributes.
> 
> -- Flemming
> 
> 
>> /Ingemar
>> *******************************************
>> Ingemar Johansson
>> Senior Research Engineer, IETF "nethead"
>> EAB/TVP - Multimedia Technologies
>>   Ericsson Research Ericsson AB
>>   Box 920 S-971 28 Luleå, Sweden
>> Tel: [phone]
>> ECN: 850-43042
>> ECC: 850-43074
>> Mobile: [phone]
>> *******************************************
>>  
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>   
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic