|
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.
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.
We will have this particular situation for the 3GPP
MMTel/MTSI services at least for rel. 7.
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).
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.
My conclusion is that latent configurations does not help
us but please correct me where I make the wrong
interpretations/conclusions.
/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
|