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

["Jean-Francois Mule" <jf.mule at cablelabs.com>]

(Removing ietf at ietf.org to discuss your Last Call comment on the mmusic
list.)

Ingemar, Christer,

   Thank you for the comment. 

   I would like to note the following history related to your IETF Last
Call comment:
- On June 17, 2008, an email thread "Closing on the SDPCapNeg modified
m-line issue" was initiated:
http://www.ietf.org/mail-archive/web/mmusic/current/msg06939.html
It was addressed to Flemming, Ingemar and Christer explicitly, copied to
the list.
- Between June 17 and July 7, 3 folks responded to the thread in favor
of moving forward (including Ingemar), and there were not one email
asking to reopen or address the issue:
http://www.ietf.org/mail-archive/web/mmusic/current/msg06940.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg06941.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg07002.html
- at IETF#72, on 8/1, Joerg and I put up the WG status slides
(http://www.ietf.org/proceedings/08jul/slides/mmusic-8.pdf, page 5)
showing SDP capneg as intended for publication request as soon as draft
09 was out.  Both of you were at the meeting and commented on other
draft discussions.
- On 8/29, the mmusic WG meeting minutes were posted and announced to
the list.  The minutes
(http://www.ietf.org/proceedings/08jul/minutes/mmusic.html) show the ID
is awaiting publication request.

Just to make sure I get the facts right, was there any new email on this
that I missed?  If so, please resend.

Thank you
Jean-Francois.
MMUSIC co-chair

> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
> Behalf Of Ingemar Johansson S
> Sent: Tuesday, October 07, 2008 6:38 AM
> To: ietf at ietf.org
> Cc: Flemming Andreasen; mmusic at ietf.org; Christer Holmberg
> Subject: Re: [MMUSIC] Last Call:draft-ietf-mmusic-sdp-capability-
> negotiation (SDP CapabilityNegotiation) 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
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic