Except in closed situations like 3GPP, how would the UA know whether to insert this new attribute? John > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Ingemar Johansson S > Sent: 07 October 2008 13:38 > To: ietf@xxxxxxxx > Cc: Flemming Andreasen; Ingemar Johansson S; mmusic@xxxxxxxx; > Christer Holmberg > Subject: RE: [MMUSIC] Last Call: > draft-ietf-mmusic-sdp-capability-negotiation(SDP Capability > Negotiation) to Proposed Standard > > Hi > > In draft-ietf-mmusic-sdp-capability-negotiation it is > proposed that the > transport in the m-line is modified in the SDP answer. While this is a > good idea in order to reduce the number of offer/answer > exchanges it can > in fact cause problems with intermediaries that for instance compare > offer and answer SDP's. The problem may be exacerbated > further with the > addition of extensions to the framework. > > Section 3.12 in the draft says: > "The solution to this problem is to upgrade the intermediary > to support > the SDP Capability Negotiation framework". > We find the conclusion unsatisfactory as the problem is that such > upgrades are not done overnight and there will therefore, for a > foreseeable future, exist middleboxes in the network that does not > understand the SDP Capability Negotiation Framework. > > Our proposal to solve this issue is to introduce an indicator > in the SDP > that tells that the actual configuration MUST only be indicated on the > a=acfg line. A proposed SDP attribute for this may be > "a=spdcapneg-acfg-indication-only". > > In essence it means that (if the indicator is included in the SDP) the > first offer/answer exchange will only be done to get the actual > configuration (a=acfg...). This would affect section 3.6.2 in > the draft. > If the indicator is included in the offer SDP it makes a 2nd > offer/answer exchange a MUST in order to complete the offer/answer > exchange. Section 3.6.3 specifies a "SHOULD" regarding the behavior if > the actual cofiguration and the SDP does not match. It is > possible that > "SHOULD" must be changed to "MUST" here. > > A UA that for some reason knows that intermediaries don't > understand the > new framework it will add the said SDP attribute at the > session level in > the offer-SDP. > Indications that intermediaries don't understand the new framework may > for instance in the 3GPP IMS case be that for a specific 3GPP release > the said attribute is mandated, a possible location for such a text in > this particular case is 3GPP TS26.114. > > We believe that the addition of the new functionality to the framework > will increase acceptance for the SDP Capability Negotiation framework > greatly and this without breaking the framework. > > PS. This issue has been raised previously in the MMUSIC WG, still we > want to bring this up again for your consideration. > > Regards > > Ingemar Johansson > Christer Holmberg > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf