[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] Last Call:draft-ietf-mmusic-sdp-capability-negotiation(SDP CapabilityNegotiation) to Proposed Standard
Jean-Francois,
your summary reflects nicely what I remember from the discussions in the
design team.
Regards
Thomas
> -----Original Message-----
> From: mmusic-bounces at ietf.org
> [mailto:mmusic-bounces at ietf.org] On Behalf Of Jean-Francois Mule
> Sent: Tuesday, October 07, 2008 11:08 PM
> To: Ingemar Johansson S; Christer Holmberg
> Cc: Flemming Andreasen; mmusic at ietf.org
> Subject: Re: [MMUSIC] Last
> Call:draft-ietf-mmusic-sdp-capability-negotiation(SDP
> CapabilityNegotiation) to Proposed Standard
>
> (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
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic