Subject: Re: [MMUSIC] Last Call: draft-ietf-mmusic-sdp-capability-negotiation (SDP Capability Negotiation) to Proposed Standard

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 7 Oct 2008 14:37:55 +0200

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 7 Oct 2008 15:07:30 -0600

(Removing [email-masked] 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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ingemar Johansson S
> Sent: Tuesday, October 07, 2008 6:38 AM
> To: [email-masked]
> Cc: Flemming Andreasen; [email-masked]; Christer Holmberg
> Subject: Re: [MMUSIC] Last Call:draft-ietf-mmusic-sdp-capability-
> negotiation (SDP CapabilityNegotiation) to Proposed Standard
> 
> Hi
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 8 Oct 2008 07:52:37 +0200

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

> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: den 7 oktober 2008 23:08
> To: Ingemar Johansson S; Christer Holmberg
> Cc: Flemming Andreasen; [email-masked]
> Subject: RE: [MMUSIC] Last 
> Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP 
> CapabilityNegotiation) to Proposed Standard
> 
>    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:
> 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/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
> 
> > 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.
> > 
> > "The solution to this problem is to upgrade the intermediary to 
> > support 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 
> > 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.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 08 Oct 2008 08:20:52 +0100

Except in closed situations like 3GPP, how would the UA know whether to
insert this new attribute?

John 

> From: [email-masked] [mailto:[email-masked]] On 
> Sent: 07 October 2008 13:38
> To: [email-masked]
> Cc: Flemming Andreasen; Ingemar Johansson S; [email-masked]; 
> Christer Holmberg
> Subject: RE: [MMUSIC] Last Call: 
> draft-ietf-mmusic-sdp-capability-negotiation(SDP Capability 
> Negotiation) to Proposed Standard
> 
> Hi
> 
> understand the
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 09:34:34 +0200

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

> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Ingemar Johansson S
> > Cc: Flemming Andreasen; Ingemar Johansson S; 
> [email-masked]; Christer 
> > Holmberg

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 8 Oct 2008 09:50:10 +0200

Ingemar, Christer,

draft-ietf-mmusic-sdp-capability-negotiation defines a framework for
extension of the base spec.
Would it be a solution for your problem to define an option tag to be
used in the a=creq attribute?
If understood it could trigger your desired behaviour.
If not understood by the B-party then capability negotiation would not
be performed for that call.

Regards
Thomas

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
> Sent: Tuesday, October 07, 2008 2:38 PM
> To: [email-masked]
> Subject: Re: [MMUSIC] Last

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 8 Oct 2008 09:53:25 +0200

Jean-Francois,

your summary reflects nicely what I remember from the discussions in the
design team.

Regards
Thomas

> [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
> Sent: Tuesday, October 07, 2008 11:08 PM
> Call:draft-ietf-mmusic-sdp-capability-negotiation(SDP 
> IETF Last
> > the
> > support

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 08 Oct 2008 10:58:25 -0400

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:
>>> In essence it means that (if the indicator is included in 
>>>       
>> the SDP) the 
>>     
>>> exchange. Section 3.6.3 specifies a "SHOULD" regarding the 
>>>       
>> behavior if 
>>     
>>> 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 
>>     
>>> We believe that the addition of the new functionality to 
>>>       
>> the framework 
>>     
>>> will increase acceptance for the SDP Capability Negotiation 
>>>       
>> framework 
>>     
>>> PS. This issue has been raised previously in the MMUSIC WG, 
>>>       
>> still we 
>>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 10 Oct 2008 09:18:56 +0200

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:[email-masked]] 
Sent: den 8 oktober 2008 16:58
To: Ingemar Johansson S
Cc: Jean-Francois Mule; Christer Holmberg; [email-masked]
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> 

	Thanks 
	
	-- Flemming 

		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:[email-masked]] 

			(Removing [email-masked] to discuss your Last
Call comment on 
			the mmusic
			list.)
			
			Ingemar, Christer,

			   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/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

			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: [email-masked]
[mailto:[email-masked]] On 
				Behalf Of Ingemar Johansson S
				Sent: Tuesday, October 07, 2008 6:38 AM
				To: [email-masked]
				Cc: Flemming Andreasen; [email-masked];
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 

				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

---

From: Bob Gilman <[email-masked]>
Date: Fri, 10 Oct 2008 16:42:52 -0600

Ingemar-
Thanks for your comments.  I've added a few remarks below.
-Bob

> is an extra SDP attribute.
[rrg]: If we do this through a middlebox that doesn't understand capneg,
        then wouldn't we wind up fooling the middlebox into thinking the
        m-line option was chosen? - unless we do something like set the
        ports to zero as described in RFC3264, section 5.1.  I suppose
        that could be done by the answerer as part of the rules for
        a=sdpcapneg-acfg-indication-only processing.  If the answerer
        doesn't recognize such an attribute, then it doesn't support
        SDPCapNeg, and it would respond with it's best answer to the
        m-line(s) and be done with it.  Can we think of a shorter
        attribute name?
> session setup without SDPCapNeg at all.
[rrg]: But it's not particularly hurt either - the offerer expected to
        make two exchanges, so if the answerer doesn't support
        SDPMediaCapNeg, the offeror will know to construct a conventional
        offer anyway.
> We will have this particular situation for the 3GPP MMTel/MTSI services 
[rrg]: My apologies for the delays in getting the SDPMedCapNeg document
        finished.  I hope endpoints will all support it when it becomes
        available - or soon thereafter.  Your situation is a consequence
        of specifying capability negotiation in pieces.
> this, also the readers, among them "yours truly" should have been more 
[rrg]: Please let me know what you have in mind here so I can try to fix
        it for the upcoming meeting.
> to indicate just one possible alternative.
[rrg]: correct.
> ...... In the first case the problem 
[rrg]: Not necessarily.  If the offerer provides a set of latent
        configurations, and the answerer responds with some (sub)set of
        those, then the offerer can select its preferred one and offer
        only that in the m-line(s) of second exchange.  The second
        exchange doesn't need (indeed, really shouldn't have) any
        capability negotiation attributes in either the offer or the
        answer.
> would need to assume that SDPMedCapNeg is supported by the endpoints 
[rrg]: I hope it's not an issue (or at least soon won't be). :-)
> point of view ?, according to RFC3264 it should not be an issue.
[rrg]: Since we're assuming an old intermediary, I wouldn't be too
        surprised if the intermediary were surprised by a "media-less"
        session.
> correct me where I make the wrong interpretations/conclusions.
[rrg]: There seem to be three time periods under consideration:
        1. Endpoints support SDPCapNeg, but not SDPMedCapNeg, and
           middleboxes don't support SDPCapNeg.  In this case, lcfg
           clearly can't help.
        2. Endpoints support SDPMedCapNeg, but middleboxes don't;
           lcfg-only works, but requires two exchanges.
        3. Endpoints and middleboxes support SDPMedCapNeg.  Now
           lcfg isn't needed, and negotiation can be done in a single
           exchange.  Note however that the two-stage lcfg technique
           for period 2 will still work here.
        It's my hope that period 1 will be short.
>  
> /Ingemar
>  
>  
> ------------------------------------------------------------------------
> *From:* Flemming Andreasen [mailto:[email-masked]]
> *Sent:* den 8 oktober 2008 16:58
> *To:* Ingemar Johansson S
> *Cc:* Jean-Francois Mule; Christer Holmberg; [email-masked]
> *Subject:* Re: [MMUSIC] Last 
>     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>
>     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
> 
> 

-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 13 Oct 2008 13:09:50 +0200

Hi

Comments inline below 

Regards
Ingemar

> From: Bob Gilman [mailto:[email-masked]] 
> Sent: den 11 oktober 2008 00:43
> To: Ingemar Johansson S
> Cc: Flemming Andreasen; Jean-Francois Mule; Christer 
> Holmberg; [email-masked]; Roni Even
> > selected configuration on the a=acfg line. The proposed signal for 
> > this is an extra SDP attribute.
Reading RFC3264 your suggestion to pair this with port=0 seems to make
sense. I guess there are three alternatives here.
1) port number not set to zero in offer or answer: 
  may fool a middlebox as you hint above 
2) port number i set to zero in 1st SDP answer: 
  This may be an indication that the offer is rejected. 
  However the offerer will likely be able to deduce the correct behavior
and issue a second offer/answer.
  Below a list of 1st answer SDP examples with port=0
  a) potential config selected
    ======
    m=audio 0 RTP/AVP 98
    ..
    ..
    a=acfg:1 t=1 ..
    ======
    Offerer draws conclusion that 2nd offer answer is needed as 
      "legacy" SDP body and acfg is uncorrelated    
  b) no potential config selected
    ======
    m=audio 0 RTP/AVP 98
    ..
    ..
    ======
    Normal handling of rejected offers accroding to RFC3264  
3) port number set to zero already in 1st offer:
  RFC3264 explicitly says that an m-line with port=0 MUST NOT be used. 

My conclusion is that alternative 2) is the safest.

Shorter attribute name?, yes please! I am out of ideas for the moment. 

>         SDPMediaCapNeg, the offeror will know to construct a 
OK, correct

> > We will have this particular situation for the 3GPP MMTel/MTSI 
> > services at least for rel. 7.
I believe the issue I have was that it was not quite clear on the
untouched vs. pruned lcfgs below. I will anyway try to get time to do a
thorough read on the draft and see what other parts are unclear. 

> >   As I see it the answerer can either return an lcfg untouched or 
> > pruned to indicate just one possible alternative.
> [rrg]: correct.
This will work, I believe however that it must be written in the draft
(unless it is already..)

> > 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.
> >>>>     configuration (a=acfg...). This would affect section 
> 3.6.2 in the 
> >>>>     draft.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 13 Oct 2008 16:48:10 -0400

> 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).

> 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.

> 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.

> 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.
>  
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.
> intermediary point of view ?, according to RFC3264 it should not be an 
> issue.
Per the above, there will be m-lines in the offer.
> 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

>     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>
>     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
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 14 Oct 2008 15:10:40 +0200

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.
 
(And, I don't think the issue is specific to IMS, but potentially to any
network where intermediates are used.)
 
Regards,
 
Christer

From: Flemming Andreasen [mailto:[email-masked]] 
Sent: 13. lokakuuta 2008 23:48
To: Ingemar Johansson S
Cc: Jean-Francois Mule; [email-masked]; Christer Holmberg; Flemming
Andreasen
Subject: Re: [MMUSIC] Last
Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP
CapabilityNegotiation) to Proposed Standard

	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). 

	

	

Thanks 

-- Flemming 

	/Ingemar

		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 

			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
				To: Ingemar Johansson S; Christer
	
Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP 
				CapabilityNegotiation) to Proposed
Standard
				
				(Removing [email-masked] to discuss your
Last Call comment on 
				the mmusic
				list.)
				
				Ingemar, Christer,

				   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/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-----
				
				Hi
				
				In

				While this 

				offer/answer exchanges 

				exacerbated further 

				

				indicator in the 

				indicated on 

				the SDP) the 

				behavior if 

				understand 

				framework may 

				3GPP release 

				such a text in 

				the framework 

				framework 

				still we 

				Regards
				
				Ingemar Johansson
				Christer Holmberg

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 16 Oct 2008 19:05:38 -0400

Christer Holmberg wrote:
> "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
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)
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.

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
>  
>  
>  
>
> *Sent:* 13. lokakuuta 2008 23:48
> *Cc:* Jean-Francois Mule; [email-masked]; Christer Holmberg; Flemming 
> Andreasen
>> 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 
> 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).
>
>>  
> 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.
>
> 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.
>
>>  
> support capability negotiation and/or media capabilities, then they 
> can perform the more sophisiticated negotiation described above.
>
>
>> this, also the readers, among them "yours truly" should have been 
>> more active with comments) .
> 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.
>>  
>> intermediary point of view ?, according to RFC3264 it should not be 
>> an issue.
> 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: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 21 Oct 2008 14:25:01 +0200

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

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: den 17 oktober 2008 01:06
	To: Christer Holmberg
	Cc: Ingemar Johansson S; Jean-Francois Mule; [email-masked]
	Subject: Re: [MMUSIC] Last
Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP
CapabilityNegotiation) to Proposed Standard

	Christer Holmberg wrote: 

		Hi Flemming,

		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

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

		From: Flemming Andreasen [mailto:[email-masked]] 
		Sent: 13. lokakuuta 2008 23:48
		To: Ingemar Johansson S
		Cc: Jean-Francois Mule; [email-masked]; Christer
Holmberg; Flemming Andreasen
		Subject: Re: [MMUSIC] Last
Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP
CapabilityNegotiation) to Proposed Standard

			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.

			
			 
			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:[email-masked]] 
			Sent: den 8 oktober 2008 16:58
			To: Ingemar Johansson S
			Cc: Jean-Francois Mule; Christer Holmberg;
[email-masked]
			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 

				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

				
				Ingemar, Christer,

	

	

				
				
				Thank you
				Jean-Francois.
				MMUSIC co-chair

				-----Original Message-----
				
				Hi
				
				In

				While this 

				offer/answer exchanges 

				exacerbated further 

				

				indicator in the 

				indicated on 

				the SDP) the 

				behavior if 

				understand 

				framework may 

				3GPP release 

				such a text in 

				the framework 

				framework 

				still we 

				Regards
				
				Ingemar Johansson
				Christer Holmberg