Re: [MMUSIC] Last Call: draft-ietf-mmusic-sdp-capability-negotiation(SDP Capability Negotiation) to Proposed Standard

["Elwell, John" <john.elwell at siemens.com>]

Except in closed situations like 3GPP, how would the UA know whether to
insert this new attribute?

John 

> -----Original Message-----
> From: ietf-bounces at ietf.org [mailto:ietf-bounces at ietf.org] On 
> Behalf Of Ingemar Johansson S
> Sent: 07 October 2008 13:38
> To: ietf at ietf.org
> Cc: Flemming Andreasen; Ingemar Johansson S; mmusic at ietf.org; 
> 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 at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic