[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
Hi
I believe the threads below pretty much summarizes the previous
discussions around this topic.
The difference is that the new effort is to introduce an extra indicator
that essentially says that the 1st offer/answer is only capability
exhange in the sense that if "a=spdcapneg-acfg-indication-only" (or
something with the same meaning) is present at the session level of the
offer SDP, then the answerer MUST only specify actual configuration on
the a=acfg line. As mentioned before the proposed change is minimal and
as far as I can see it does not break the framework.
The indicator is not mandatory to use other than that it may be
specified as mandatory in another standards text that use the SDP
Capability Negotiation Framework (for instance a 3GPP specification).
/Ingemar
> -----Original Message-----
> From: Jean-Francois Mule [mailto:jf.mule at cablelabs.com]
> Sent: den 7 oktober 2008 23:08
> 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