[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



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