[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
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?
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.
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.
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.
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