[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
Comments inline below
Regards
Ingemar
> -----Original Message-----
> From: Bob Gilman [mailto:bob_gilman at comcast.net]
> Sent: den 11 oktober 2008 00:43
> To: Ingemar Johansson S
> Cc: Flemming Andreasen; Jean-Francois Mule; Christer
> Holmberg; mmusic at ietf.org; Roni Even
> Subject: Re: [MMUSIC] Last
> Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP
> CapabilityNegotiation) to Proposed Standard
>
> Ingemar-
> Thanks for your comments. I've added a few remarks below.
> -Bob
>
> Ingemar Johansson S wrote:
> > Hi
> >
> > To put it short, what we would like to do is to include a
> mechanism in
> > the SDP capability negitiation framework (SDPCapNeg) that tells the
> > endpoint to modify m-line (or c-lines..) and only indicated the
> > selected configuration on the a=acfg line. The proposed signal for
> > this is an extra SDP attribute.
> [rrg]: If we do this through a middlebox that doesn't
> understand capneg,
> then wouldn't we wind up fooling the middlebox into
> thinking the
> m-line option was chosen? - unless we do something
> like set the
> ports to zero as described in RFC3264, section 5.1. I suppose
> that could be done by the answerer as part of the rules for
> a=sdpcapneg-acfg-indication-only processing. If the answerer
> doesn't recognize such an attribute, then it doesn't support
> SDPCapNeg, and it would respond with it's best answer to the
> m-line(s) and be done with it. Can we think of a shorter
> attribute name?
Reading RFC3264 your suggestion to pair this with port=0 seems to make
sense. I guess there are three alternatives here.
1) port number not set to zero in offer or answer:
may fool a middlebox as you hint above
2) port number i set to zero in 1st SDP answer:
This may be an indication that the offer is rejected.
However the offerer will likely be able to deduce the correct behavior
and issue a second offer/answer.
Below a list of 1st answer SDP examples with port=0
a) potential config selected
======
m=audio 0 RTP/AVP 98
..
..
a=acfg:1 t=1 ..
======
Offerer draws conclusion that 2nd offer answer is needed as
"legacy" SDP body and acfg is uncorrelated
b) no potential config selected
======
m=audio 0 RTP/AVP 98
..
..
======
Normal handling of rejected offers accroding to RFC3264
3) port number set to zero already in 1st offer:
RFC3264 explicitly says that an m-line with port=0 MUST NOT be used.
My conclusion is that alternative 2) is the safest.
Shorter attribute name?, yes please! I am out of ideas for the moment.
> >
> > Latent configurations may indeed be useful to in order to
> solve this
> > problem but I am not convinced that it solves the problems
> all the way.
> >
> > The idea is (to my understanding) that the 1st SDP offer
> may contain
> > zero m-lines but a number of latent configurations for
> audio and video.
> > As the offerer will send an offer with zero m-lines it is easy to
> > realize that a 2nd offer/answer is needed.
> >
> > There are a few issues with this however:
> > 1) Assumes that SDPMedCapNeg (SDP media capabilities
> negotiation) is
> > supported by the endpoints. An endpoint that does not understand
> > SDPMedCapNeg is not helped by this trick and will have to
> resort to a
> > session setup without SDPCapNeg at all.
> [rrg]: But it's not particularly hurt either - the offerer expected to
> make two exchanges, so if the answerer doesn't support
> SDPMediaCapNeg, the offeror will know to construct a
> conventional
> offer anyway.
OK, correct
> > We will have this particular situation for the 3GPP MMTel/MTSI
> > services at least for rel. 7.
> [rrg]: My apologies for the delays in getting the
> SDPMedCapNeg document
> finished. I hope endpoints will all support it when
> it becomes
> available - or soon thereafter. Your situation is a
> consequence
> of specifying capability negotiation in pieces.
> >
> > 2) The examples and the description for lcfg is a bit unclear (no
> > offence meant, I realize the headache the authors must have
> had with
> > this, also the readers, among them "yours truly" should
> have been more
> > active with comments) .
> [rrg]: Please let me know what you have in mind here so I can
> try to fix
> it for the upcoming meeting.
I believe the issue I have was that it was not quite clear on the
untouched vs. pruned lcfgs below. I will anyway try to get time to do a
thorough read on the draft and see what other parts are unclear.
> > As I see it the answerer can either return an lcfg untouched or
> > pruned to indicate just one possible alternative.
> [rrg]: correct.
> > ...... In the first case the problem
> > is that it will be necesary to send a second offer with several
> > potential configurations which will leave us in the same
> situation as
> > before i.e that the 2nd offer must include a number of potential
> > configurations which leaves us in the same situation.
> [rrg]: Not necessarily. If the offerer provides a set of latent
> configurations, and the answerer responds with some
> (sub)set of
> those, then the offerer can select its preferred one and offer
> only that in the m-line(s) of second exchange. The second
> exchange doesn't need (indeed, really shouldn't have) any
> capability negotiation attributes in either the offer or the
> answer.
This will work, I believe however that it must be written in the draft
(unless it is already..)
> > 3) Other extenstions (such as the extension considered for
> the c-line)
> > would need to assume that SDPMedCapNeg is supported by the
> endpoints
> > (maybe not a big issue).
> [rrg]: I hope it's not an issue (or at least soon won't be). :-)
> >
> > 4) Would an SDP offer without any m-lines look odd from an
> > intermediary point of view ?, according to RFC3264 it
> should not be an issue.
> [rrg]: Since we're assuming an old intermediary, I wouldn't be too
> surprised if the intermediary were surprised by a "media-less"
> session.
> >
> > My conclusion is that latent configurations does not help us but
> > please correct me where I make the wrong
> interpretations/conclusions.
> [rrg]: There seem to be three time periods under consideration:
> 1. Endpoints support SDPCapNeg, but not SDPMedCapNeg, and
> middleboxes don't support SDPCapNeg. In this case, lcfg
> clearly can't help.
> 2. Endpoints support SDPMedCapNeg, but middleboxes don't;
> lcfg-only works, but requires two exchanges.
> 3. Endpoints and middleboxes support SDPMedCapNeg. Now
> lcfg isn't needed, and negotiation can be done in a single
> exchange. Note however that the two-stage lcfg technique
> for period 2 will still work here.
> It's my hope that period 1 will be short.
> >
> > /Ingemar
> >
> >
> >
> ----------------------------------------------------------------------
> > --
> > *From:* Flemming Andreasen [mailto:fandreas at cisco.com]
> > *Sent:* den 8 oktober 2008 16:58
> > *To:* Ingemar Johansson S
> > *Cc:* Jean-Francois Mule; Christer Holmberg; mmusic at ietf.org
> > *Subject:* Re: [MMUSIC] Last
> > Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP
> > CapabilityNegotiation) to Proposed Standard
> >
> > Thank you for the comments Ingemar. As Jean-Francois
> noted, we have
> > been through this issue many times before and the
> solution specified
> > in the draft reflects WG consensus, which you also
> supported in the
> > past (after admittedly considerable discussion). I
> think it's worth
> > taking a step back again, and look at what it is you
> actually want
> > to do here, and how we can address it. Quoting from an earlier
> > exchange on this subject ("SDPCapNeg, modified m-line issue",
> > 5/21/2008 on the MMUSIC list):
> >
> > <quote>
> > Taking a step back, I believe the essence of your
> comments are, that if
> > we want to use SDP Capability Negotiation to establish
> media streams,
> > then we cannot do that in a single offer/answer
> exchange. Instead, you
> > want to have a mechanism whereby we first exchange
> capabilities between
> > the offerer and the answerer (without establishing a
> stream) followed by
> > another exchange where we actually negotiate the media stream
> > parameters. In other words, the current
> single-roundtrip O/A exchange
> > provided by RFC 3264 and supported by SDPCapNeg is replaced by a
> > two-roundtrip solution.
> >
> > <snip>
> >
> > Note however, that the SDPCapNeg framework as currently
> defined can be
> > used more or less the way you seem to prefer by merely
> including
> > capabilities in the offer without the actual potential
> configuration
> > attributes (which are used to trigger the extended O/A
> exchange). The
> > thing that would be missing is expressing valid combinations of
> > capabilites as well as preferences, however this is
> part of what the
> > media capabilities extension document is addressing by
> introducing the
> > "latent configuration" attribute, which you could then use.
> > </quote>
> >
> >
> > In lieu of all the discussion and WG consensus on the currently
> > specified mechanism, can you please explain why the
> above cannot be
> > used to address your concerns, i.e. either just send
> capabilities
> > initially, or define an extension that provides the
> exact semantics
> > you are looking for ?
> >
> > Thanks
> >
> > -- Flemming
> >
> >
> > Ingemar Johansson S wrote:
> >> 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
> >>>>
> >>
> >>
>
>
> -------------------------------------------------------------
> Bob Gilman bob_gilman at comcast.net +1 303 898 9780
>
>
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic