Except in closed situations like 3GPP, how would the UA know whether to
insert this new attribute?
Those who think that the current behavior does not cause problems do not
need to care about the attribute :)
And, even in the current text: how does the UA know whether it needs to
send the second "synchronization" offer?
I guess one option is to provision it.
Regards,
Christer
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org]
On Behalf
Of Ingemar Johansson S
Sent: 07 October 2008 13:38
To: ietf(_at_)ietf(_dot_)org
Cc: Flemming Andreasen; Ingemar Johansson S;
mmusic(_at_)ietf(_dot_)org; Christer
Holmberg
Subject: RE: [MMUSIC] Last Call:
draft-ietf-mmusic-sdp-capability-negotiation(SDP Capability
Negotiation) 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
mmusic mailing list
mmusic(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf