Subject: [clue] FW: New Version Notification for draft-even-clue-sdp-clue-relation-01.txt

From: Roni Even <[email-masked]>
Date: Sun, 21 Oct 2012 20:05:55 +0000

________________________________________
From: [email-masked] [[email-masked]]
Sent: Sunday, October 21, 2012 9:59 PM
To: Roni Even
Subject: New Version Notification for draft-even-clue-sdp-clue-relation-01.txt

A new version of I-D, draft-even-clue-sdp-clue-relation-01.txt
has been successfully submitted by Roni Even and posted to the
IETF repository.

Filename:        draft-even-clue-sdp-clue-relation
Revision:        01
Title:           Signalling of CLUE and SDP offer/answer
Creation date:   2012-10-21
WG ID:           Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-even-clue-sdp-clue-relation-01.txt
Status:          http://datatracker.ietf.org/doc/draft-even-clue-sdp-clue-relation
Htmlized:        http://tools.ietf.org/html/draft-even-clue-sdp-clue-relation-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-even-clue-sdp-clue-relation-01

Abstract:
   This document describes the relation between the different CLUE
   attributes as specified in the CLUE framework and the SDP attributes.
   The document will discuss the issues with the CLUE call signalling in
   order to keep the consistency between the Offer/answer state and the
   CLUE state.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2012 11:08:04 -0400

Roni,

Thanks for submitting this. A few observations:

Section 3:

    The CLUE framework [I-D.ietf-clue-framework] recommends using one
    transport connection for each media type multiplexing using one RTP
    session.  This also makes it simple to add and remove media capture
    by the consumer without a need for an [RFC3264] offer answer.

    The exception is if the consumer prefers using a separate RTP non
    multiplex session.

IMO the last statement isn't quite right. There may well be a desire for 
multiple transport connections for a media type even though there is an 
intent to multiplex multiple RTP media streams on each of them. For 
instance, there indeed might be a separate m-lines with content 'main' 
and 'slides', and yet both might be multiplexed - multiple cameras in 
main, and multiple presentation sessions in slides. Or it may be that 
there are multiple m-lines with content 'main', each multiplexed, 
because of using independent encoding hardware.

So I would recommend either simply removing the sentence above "The 
exception...", or else replacing it with one or more that mention the 
various motivations for this.

That same section then goes on to say:

    When multiplexing RTP streams in a single RTP session there is
    probably no need for offer answer exchange when the consumer send a
    new configuration.

Is this really true? Suppose there is a single RTP session, and the 
advertisement gives the possibility of from one to three captures, and 
with a range of encodings. The amount of bandwidth required for this one 
m-line could vary by an order of magnitude or more depending on which 
capture encodings are configured. It is unlikely to be acceptable to 
negotiate the maximal bandwidth just on the off chance that it will be 
required. So it seems likely that some configurations will require a new 
O/A. (Of course there are also cases that will not - e.g. when a 
configuration simply replaces one capture encoding with another having 
similar encoding requirements.)

I am still struggling to understand when the SDP maps to "captures", 
"encodings" and "capture encodings".

Section 4 talks about bandwidth in the context of encodings, but in that 
part there is little mention of the relationship to when O/As will be 
needed for this part.

I suppose one way to view things is that the O/A should be used to 
establish/enable a set of encodings from among those in the 
advertisement, while the Configure message is used to select which 
capture is mapped to each of those encodings. Is that what you have in mind?

If so, then a new O/A may be required each time one is planning to send 
a Configure that selects encodings that have not already been negotiated 
in SDP.

That also may put a slightly different spin on the "static" mapping, in 
that perhaps it will only identify an 'encoding', not a 'capture encoding'.

	Thanks,
	Paul

On 10/21/12 4:05 PM, Roni Even wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Roni Even" <[email-masked]>
Date: Mon, 22 Oct 2012 17:42:38 +0200

Hi Paul,
Thanks, see inline
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 22 October, 2012 5:08 PM
To: [email-masked]
Subject: Re: [clue] FW: New Version Notification for
draft-even-clue-sdp-clue-relation-01.txt

Roni,

Section 3:

IMO the last statement isn't quite right. There may well be a desire for
multiple transport connections for a media type even though there is an
intent to multiplex multiple RTP media streams on each of them. For
instance, there indeed might be a separate m-lines with content 'main' 
and 'slides', and yet both might be multiplexed - multiple cameras in main,
and multiple presentation sessions in slides. Or it may be that there are
multiple m-lines with content 'main', each multiplexed, because of using
independent encoding hardware.

Roni E: you are right and I can change the text, the issue is that there may
be a need to open a new transport connection later, it can be multiplexed or
not.

Is this really true? Suppose there is a single RTP session, and the
advertisement gives the possibility of from one to three captures, and with
a range of encodings. The amount of bandwidth required for this one m-line
could vary by an order of magnitude or more depending on which capture
encodings are configured. It is unlikely to be acceptable to negotiate the
maximal bandwidth just on the off chance that it will be required. So it
seems likely that some configurations will require a new O/A. (Of course
there are also cases that will not - e.g. when a configuration simply
replaces one capture encoding with another having similar encoding
requirements.)

Roni E: I did not say that there is no need but you can do without it. I do
not think that current implementation will send a new offer/answer to lower
bandwidth if they are not using it since it is a maximum receive value and
not reservation for sending. This is different from the encoding value which
is the sending bandwidth.

Section 4 talks about bandwidth in the context of encodings, but in that
part there is little mention of the relationship to when O/As will be needed
for this part.

Roni E: I think I covered it considering that the b= in the SDP is receive
value while the encoding is send value. The b= say that the sender cannot
send more so both provide the limit.

I suppose one way to view things is that the O/A should be used to
establish/enable a set of encodings from among those in the advertisement,
while the Configure message is used to select which capture is mapped to
each of those encodings. Is that what you have in mind?

If so, then a new O/A may be required each time one is planning to send a
Configure that selects encodings that have not already been negotiated in
SDP.

Roni E: I do not see the case for that. Again the SDP is receive values so a
configuration will not ask for something it cannot receive.

That also may put a slightly different spin on the "static" mapping, in that
perhaps it will only identify an 'encoding', not a 'capture encoding'.

	Thanks,
	Paul

On 10/21/12 4:05 PM, Roni Even wrote:
> has been successfully submitted by Roni Even and posted to the IETF 
> repository.
>
> URL:
http://www.ietf.org/internet-drafts/draft-even-clue-sdp-clue-relation-01.txt
> Status:
http://datatracker.ietf.org/doc/draft-even-clue-sdp-clue-relation
> Htmlized:
http://tools.ietf.org/html/draft-even-clue-sdp-clue-relation-01
> Diff:
http://www.ietf.org/rfcdiff?url2=draft-even-clue-sdp-clue-relation-01