Hi
Comments inline
Please note that we are not trying to delay
standardization. SDPCapNeg is needed in 3GPP MTSI services and here it is
much better to reference to an RFC rather than work in progress. If we are the
only ones expressing the concerns below we can probably live with the
established concensus even though we are not 100% satisfied with it.
Regards
/Ingemar
Christer Holmberg wrote:
Hi Flemming,
To
put the problem short:
An
intermediate, which do not support, CapNeg may experience an "unexpected"
SDP answer, since some parameter(s) has changed compared to the
corresponding SDP offer.
The problem can be solved by using any of the following solutions:
1)
Don't use capability negotiation
Not an option
2) Use base capability
negotiation without including potential configurations but just include
capability information with the intial O/A exchange instead. Based on the
capabilities exchanged, you can then do a second O/A exchange. You loose a bit
of expressiveness this way, however that can be addressed by 3)
I don't believe I understand this. My interpretation: The offer specifies
tcap's and acap's but no pcfg's. I don't see how this would solve the
problem. If the answerer understands SDPCapNeg I would believe that (from
reading the draft) that the tcap's and acap's will not be included in
the answer. If the answered does not understand SDPCapNeg I would believe that
the tcap and acfg lines are removed.
3) Use the media
capabilities extensions with latent configurations. You now have complete
expressiveness.
4) Define a new extension using the extensibility
framework provided by the base capability negotiation framework.
Both of these alternatives can be used. Problem is that for 3GPP release
7 no such thing is possible as the time-window to include new functionality is
closed. This means that this can be included in rel 8 with the consequence that
we will have a time-gap in the product lines where the potential problem is not
solved.
Let me know if none
of the above addresses your problem (and if so please elaborate on why).
Thanks
-- Flemming
(And, I don't think the issue is specific to IMS,
but potentially to any network where intermediates are
used.)
Regards,
Christer
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
|