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.
I'm not sure what you mean by "modify m-line (or c-lines...)", but more
importantly; instead of describing a particular solution, can you
please take a step back and describe only the problem you want to
solve. Based on a clear understanding of that, we can then see how we
might be able to address it (as I've indicated a couple of times by
now, I believe we already have a solution to your problem, but we need
to focus purely on the problem description instead of your proposed
solution before we can adequately judge that).
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.
No - the idea is still to have a regular offer/answer exchange in the
first exchange, however, when using the basic capability negotiation
framework, you only add capabilites (not potential configurations) to
the offer and answer. Based on the capabilities exchanged, you can then
decide whether to go through a second O/A exchange using your new-found
knowledge of the peers capabilities.
If you use the media capabilities extensions, you can use latent
configurations as Bob has mentioned. This provides more expressiveness
(similar to what the base framework would have allowed, and then some)
but without actually negotiation use of the latent configurations until
the second exchange. Of course, you will have to support the media
capabilities extension for this to work.
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.
We will have this particular
situation for the 3GPP MMTel/MTSI services at least for rel. 7.
No. We perform a regular O/A exchange as usual. If the two endpoints
support capability negotiation and/or media capabilities, then they can
perform the more sophisiticated negotiation described above.
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) .
As I see it the answerer can
either return an lcfg untouched or pruned to indicate just one possible
alternative. 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.
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).
True, however given that plain SDP does not support what you are
looking for, some sort of extension is needed. Also, since your concern
seems to mainly be for 3GPP IMS, it should be possible to require
support for those features.
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.
Per the above, there will be m-lines in the offer.
My conclusion is that latent
configurations does not help us but please correct me where I make the
wrong interpretations/conclusions.
See above. Again, if you could please provide a crisp problem statement
(without any proposed solution detail), that would help us move forward
here.
Thanks
-- Flemming
/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
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
|