Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation between potential configurations

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jul 2007 19:13:49 +0200

The draft comes to the conclusion that there is no real need for 
coordintion between different media descriptions and their potential 
configurations. I think that is wrong for several reasons:

1. I would start with referening once more to a defined usage in RFC 
4588 (RTP Retransmission). In the case of desire to use session 
multiplexing for the retransmission one would only like to use that 
under the constraint that one already uses AVPF in the primary 
transmission session. Thus one would like to make the following offer:

Primary session: AVP, potential configuration 1: AVPF with NACK

Retransmission session: Only used in case primary session selects 
potential configuration 1.

2. Allow for media capability negotiation. As I see it when moving into 
a media capability negotiation extension one will very much like to 
present cases where there are set of media configurations. That may 
include additional media streams needing their own media descriptions, 
i.e. RTP sessions / or other media transport (MSRP). One would in other 
words like to express capabilites like. Lets do (Audio, video and Text), 
or (Audio, video and MSRP) or (Audio and Text) or (Audio and MSRP) 
depending on peers capabilities. Without the functionality to make 
higher level bindings between potential configurations into different 
sets that will not work.

Unfortunately the above has one very frightening conclusion, we need to 
have possibility to do potential configurations for media descriptions 
that has no match in the actual configuration.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 20 Jul 2007 12:24:38 +0200

Magnus,

more inline. 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Thursday, July 19, 2007 7:14 PM
> To: mmusic (E-mail)
> Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation 
> betweenpotential configurations
> 

In other words this means an actual configuration with one m-line and 
a potential configuration with two m-lines.
Would it help if the problem is described in the core spec, but not
solved?
My intention is to keep the core spec as simple as possible, 
but to state its restrictions.

> higher level bindings between potential configurations into different 

Here I think we must decide how far we want go with media capability
negotiation.

> that has no match in the actual configuration.

I'm not sure how frightening that is from specification perspective
(e.g. an a=mcap for additional m-lines could do), 
but it surely is for an implementor.

Regards
Thomas

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 20 Jul 2007 20:23:09 +0300

Magnus,

I have other examples for such requirements like receiver would like to get one H.264 stream or two H.263 streams. I think that there is already a problem with grouping such alternatives in regular SDP and than I already started to discuss with Bob Gilman about having similar functionality for media potential configurations.

Roni

> Sent: Thursday, July 19, 2007 8:14 PM
> To: mmusic (E-mail)

---

From: "Joe Stone \(joestone\)" <[email-masked]>
Date: Fri, 20 Jul 2007 11:42:05 -0700

Magnus seems to be discussing the notion of an "actual session
description" consisting of "actual media descriptions" versus "potential
session descriptions" consisting of "potential media descriptions". Not
to confuse matters and for purely illustrative purposes (in short-hand
SDP notation),

	v=0
	a=X-psd:1 X-pmd=1
	a=X-pmd:1 m=image 53458 udptl t38
	a=X-pmd:1 a=T38FaxVersion: <Version>
	a=X-pmd:1 a=T38MaxBitrate: <bitrate>
	m=audio 53456 RTP/AVP 0

The actual session description consists of one actual media description
involving audio/PCMU. There is one potential (preferred) session
description, "X-psd:1", consisting of one potential media description,
"X-pmd:1", involving image/t38.

And more along the lines of Magnus' example,

	v=0
	a=X-psd:1 X-pmd=1|2
	a=X-psd:2 X-pmd=3
	a=X-pmd:1 m=audio 53456 RTP/AVP 18
	a=X-pmd:2 m=text 53458 RTP/AVP 98      <<< RFC 4103
	a=X-pmd:2 a=rtpmap:98 t140/1000
	a=X-pmd:3 m=audio 53456 RTP/AVP 18 98  <<< RFC 4351
	a=X-pmd:3 a=rtpmap:98 t140c/8000
	m=audio 53456 RTP/AVP 18 98            <<< V.152
	a=rtpmap:98 PCMU/8000
	a=gpmd:98 vbd=yes

Applying semantics similar to sdp-capability-negotiation, the most
preferred potential session description, "X-psd:1", consists of two
potential media descriptions involving audio/G729 and text/t140,
respectively. The second most preferred potential session description,
"X-psd:2", consists of one potential media description involving
audio/G729 and audio/t140c.

If my hypothetical pseudo-code doesn't make any sense, disregard it.
However, I do agree with Magnus that there's a need to negotiate between
groups of media descriptions. I see this as the "big picture". It should
be shown, at least at a high-level, that the transport protocol
negotiation of sdp-capability-negotiation will fit with a more
comprehensive SDP negotiation framework. 

On a related topic...

I'm not convinced that sdp-capability-negotiation should obsolete RFC
3407 given that sdp-capability-negotiation doesn't define equivalent
functionality (at least based on -06).

Joe

-----Original Message-----
From: Stach, Thomas [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 5:25 AM
To: Magnus Westerlund; mmusic (E-mail)
Subject: RE: [MMUSIC] SDPCapNeg-06: Session level
coordintationbetweenpotential configurations

Magnus,

more inline. 

> potential configuration 1.

In other words this means an actual configuration with one m-line and a
potential configuration with two m-lines.
Would it help if the problem is described in the core spec, but not
solved?
My intention is to keep the core spec as simple as possible, but to
state its restrictions.

> 
> 2. Allow for media capability negotiation. As I see it when moving 
> into a media capability negotiation extension one will very much like 
> to present cases where there are set of media configurations. That may

> i.e. RTP sessions / or other media transport (MSRP). One would in 
> other words like to express capabilites like. Lets do (Audio, video 
> and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio 
> and MSRP) depending on peers capabilities. Without the functionality 
> to make higher level bindings between potential configurations into 
> different sets that will not work.

> 
> Unfortunately the above has one very frightening conclusion, we need 
> to have possibility to do potential configurations for media 
> descriptions that has no match in the actual configuration.

I'm not sure how frightening that is from specification perspective
(e.g. an a=mcap for additional m-lines could do), but it surely is for
an implementor.

Regards
Thomas

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jul 2007 12:00:20 -0400

> potential configuration 1.
Agree with your point - we had primarily looked at attribute 
interactions, but as you note RFC 4588 (and FEC as well I believe) are 
examples where do you may need inter-media stream syncrhonization of the 
negotiated parameters (payload formats, etc.). Still, per our limited 
scope in the core document, and support for extensions, such as media 
capabilities, I don't believe we need to solve this in the core 
capabilities document, however we should at least add a note pointing 
out the above.

> different sets that will not work.
Right - this is well understood I believe, however there has not been 
consensus to adopt this level of complexity in the core document. 
Instead the WG consensus is that this type of functionality can be 
handled in an (optional) extensions.
> descriptions that has no match in the actual configuration.
If you want to address that requirement (which we currently don't have) 
I agree, however why is that frightening ?

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jul 2007 12:05:44 -0400

> comprehensive SDP negotiation framework. 
Or rather a set of possible extensions to the core framework.

We keep going back to scope and requirements here. Currently, we have a 
separate requirement document (which we don't have any real plans for, 
e.g. turning into RFC). At one point, we discussed incorporating it into 
an Appendix to give some people some additional background and 
motivation for the design and scope. What do people (and the chairs) 
want to do here:
1) Let the requirements draft expire.
2) Publich requirements draft as a separate RFC
3) Incorporate requirements into an appendix in the core document
4) Something else ?

> functionality (at least based on -06).
I'm open either way - current consensus is to obsolete it.

-- Flemming

---

From: "Joe Stone \(joestone\)" <[email-masked]>
Date: Mon, 23 Jul 2007 15:29:07 -0700

[js] Comments in line...

________________________________

From: Flemming Andreasen (fandreas) 
Sent: Monday, July 23, 2007 11:06 AM
To: Joe Stone (joestone)
Cc: Stach, Thomas; Magnus Westerlund; mmusic (E-mail)
Subject: Re: [MMUSIC] SDPCapNeg-06: Session level
coordintationbetweenpotential configurations

	However, I do agree with Magnus that there's a need to negotiate
between
	groups of media descriptions. I see this as the "big picture".
It should
	be shown, at least at a high-level, that the transport protocol
	negotiation of sdp-capability-negotiation will fit with a more
	comprehensive SDP negotiation framework. 

 
[js] I'm not suggesting a change to the scope of
sdp-capability-negotiation(-06) or the requirements of
sdp-capability-negotiation-reqts-01. However, you should consider...
sdp-capability-negotiation-reqts-01 defines a set of requirements. It
categorizes these requirements (and the corresponding functionality) as
either mandatory ("core") or optional ("enhancements"), dealing with
whether an entity must support/implement a particular function or not.
It gives examples of "extensions",  e.g., unicast/multicast and
IPv4/IPv6 address negotiation. Note that REQ-150 (valid combinations of
media lines) is an enhancement, not necessarily an extension.
sdp-capability-negotiation-reqts-01 does not limit the scope of
sdp-capability-negotiation(-06) to the core requirements. You may want
to clarify this before further referencing the requirements I-D.

	On a related topic...
	
	I'm not convinced that sdp-capability-negotiation should
obsolete RFC
	3407 given that sdp-capability-negotiation doesn't define
equivalent
	functionality (at least based on -06).

[js] I hope that those who form the consensus understand the way in
which RFC 3407 is being used. I understand the motivation for wanting to
derail RFC 3407 (in favor of SDPCapNeg) sooner than later. However, as
you're well aware, RFC 3407 support is mandatory with MGCP profiles such
as PacketCable's NCS and TGCP. RFC 3407 has found its way into SIP
implementations. It's acknowledged as part of the PacketCable 2.0 (SIP)
specifications. Once the cat is out of the bag...
 
[js] I can see an extension to SDPCapNeg (with equivalent functionality)
*possibly* obsoleting RFC 3407, however, I don't see where it makes
sense in the case of sdp-capability-negotiation-06.
 
-- Flemming 

	Joe
	
	-----Original Message-----
	From: Stach, Thomas [mailto:[email-masked]] 
	Sent: Friday, July 20, 2007 5:25 AM
	To: Magnus Westerlund; mmusic (E-mail)
	Subject: RE: [MMUSIC] SDPCapNeg-06: Session level
	coordintationbetweenpotential configurations
	
	Magnus,
	
	more inline. 

		-----Original Message-----
		From: Magnus Westerlund
[mailto:[email-masked]]
		Sent: Thursday, July 19, 2007 7:14 PM
		To: mmusic (E-mail)
		Subject: [MMUSIC] SDPCapNeg-06: Session level
coordintation 
		betweenpotential configurations
		
		The draft comes to the conclusion that there is no real
need for 
		coordintion between different media descriptions and
their potential 
		configurations. I think that is wrong for several
reasons:
		
		1. I would start with referening once more to a defined
usage in RFC
		4588 (RTP Retransmission). In the case of desire to use
session 
		multiplexing for the retransmission one would only like
to use that 
		under the constraint that one already uses AVPF in the
primary 
		transmission session. Thus one would like to make the
following offer:
		
		Primary session: AVP, potential configuration 1: AVPF
with NACK
		
		Retransmission session: Only used in case primary
session selects 
		potential configuration 1.

	In other words this means an actual configuration with one
m-line and a
	potential configuration with two m-lines.
	Would it help if the problem is described in the core spec, but
not
	solved?
	My intention is to keep the core spec as simple as possible, but
to
	state its restrictions.

		2. Allow for media capability negotiation. As I see it
when moving 
		into a media capability negotiation extension one will
very much like 
		to present cases where there are set of media
configurations. That may

		include additional media streams needing their own media
descriptions,

		i.e. RTP sessions / or other media transport (MSRP). One
would in 
		other words like to express capabilites like. Lets do
(Audio, video 
		and Text), or (Audio, video and MSRP) or (Audio and
Text) or (Audio 
		and MSRP) depending on peers capabilities. Without the
functionality 
		to make higher level bindings between potential
configurations into 
		different sets that will not work.

	Here I think we must decide how far we want go with media
capability
	negotiation.

		Unfortunately the above has one very frightening
conclusion, we need 
		to have possibility to do potential configurations for
media 
		descriptions that has no match in the actual
configuration.

	I'm not sure how frightening that is from specification
perspective
	(e.g. an a=mcap for additional m-lines could do), but it surely
is for
	an implementor.
	
	Regards
	Thomas

		Cheers
		
		Magnus Westerlund

	
----------------------------------------------------------------------
		Ericsson AB                | Phone +46 8 4048287
		Torshamsgatan 23           | Fax   +46 8 7575550
		S-164 80 Stockholm, Sweden | mailto:
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Jul 2007 01:35:17 +0200

> I agree, however why is that frightening ?

Because you need to be able to create media descriptions, i.e. m= lines 
that only exist in potential configurations, not in the actual 
configurations. That means one thing to me. We need some attribute to 
encode the equivalent to a "m=" line and also its attributes and other 
functions in the media block. This may not really be frightining, but it 
has potential issues in regards to both complexity and getting things 
right.

-- 

Magnus Westerlund

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 24 Jul 2007 07:42:51 -0400

Joe Stone (joestone) wrote:
> [js] Comments in line...
>
> ------------------------------------------------------------------------
> *From:* Flemming Andreasen (fandreas)
> *Sent:* Monday, July 23, 2007 11:06 AM
> *To:* Joe Stone (joestone)
> *Cc:* Stach, Thomas; Magnus Westerlund; mmusic (E-mail)
> *Subject:* Re: [MMUSIC] SDPCapNeg-06: Session level 
> We keep going back to scope and requirements here. Currently, we have 
> a separate requirement document (which we don't have any real plans 
> for, e.g. turning into RFC). At one point, we discussed incorporating 
> it into an Appendix to give some people some additional background and 
> categorizes these requirements (and the corresponding functionality) 
> as either mandatory ("core") or optional ("enhancements"), dealing 
> with whether an entity must support/implement a particular function or 
> not. It gives examples of "extensions",  e.g., unicast/multicast and 
> IPv4/IPv6 address negotiation. Note that REQ-150 (valid combinations 
> of media lines) is an enhancement, not necessarily an extension.
Enhancement and extension is largely synonymous in the requirements 
document.
> to clarify this before further referencing the requirements I-D.
OK. I think it's hereby clarified.
> which RFC 3407 is being used. I understand the motivation for wanting 
> to derail RFC 3407 (in favor of SDPCapNeg) sooner than later. However, 
> as you're well aware, RFC 3407 support is mandatory with MGCP profiles 
> such as PacketCable's NCS and TGCP. RFC 3407 has found its way into 
> SIP implementations. It's acknowledged as part of the PacketCable 2.0 
> (SIP) specifications. Once the cat is out of the bag...
>  
> [js] I can see an extension to SDPCapNeg (with equivalent 
> functionality) *possibly* obsoleting RFC 3407, however, I don't see 
> where it makes sense in the case of sdp-capability-negotiation-06.
Fair point.

-- Flemming