Subject: Re: [clue] draft-hansen-clue-sdp-interaction-00

From: "Roni Even" <[email-masked]>
Date: Sun, 3 Mar 2013 12:34:47 +0200

Hi Rob,
I wrote a similar draft
http://tools.ietf.org/html/draft-even-clue-sdp-clue-relation-01 and my
conclusion was 

Conclusion - except for the maxWidth and maxHeight there is no
   problem between the SDP and CLUE encoding values as long as SDP
   attributes are used as receiver capabilities and the relation between
   the two protocols is defined.  Changing SDP values will not require a
   change in CLUE advertisement or configuration and vice versa since
   these parameters signal maximum values and not exact values.

For the maxWidth and MaxHeight it has to do with using RFC6236 as image
attribute. 
 As for band width one issue I mention is using RTCP TMMBR for changing the
bw. This will need to be inline with both the SDP and CLUE values.

Still in section 5 you say "If updates to both negotiations are required for
a new stream to be added, then the new stream will not be available until
both  renegotiations are complete "
I was wondering how is it known to both sides. This was an open issue in our
discussion.

Another question is on "A cost of this is that endpoints will now need to
deal with the fact that CLUE  messages may contain parameters exceeding
those negotiated in SDP, or
   referencing SDP content that does not exist" Does it mean that we can add
an RTP stream without signaling? This will fail for intermediaries

Roni 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Hansen
Sent: 18 February, 2013 10:04 PM
To: [email-masked]
Subject: [clue] draft-hansen-clue-sdp-interaction-00

Hi all,

I've posted a new draft which will hopefully have a relatively short
lifespan on the topic of the interactions between CLUE signalling and SDP -
as we've discovered when we've tried to define things like call flows a lot
of the different aspects are dependant on each other, making it hard to make
a decision. I picked a couple of points that I believe aren't so entangled.

Some of these things in it are hopefully uncontroversial but haven't always
been documented yet, others are likely to provoke more disagreement.

There's no attempt in the draft at defining the SDP or CLUE messages, the
draft merely discusses what information is needed in each and how they
should interact.

For -01 I hope to add some diagrams to better illustrate what's going on.

Rob
_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Tue, 05 Mar 2013 16:26:49 +1100

Hello Robert,

Please see my replies below.

Regards, Christian

On 5/03/2013 2:00 AM, Robert Hansen wrote:
> > With regards to 4.2, you mention that middleboxes may want to alter the
> > SDP without involving themselves in CLUE. Isn't this fought with
> > problems if the middleboxes go and change SDP information related to
> > Clue without understanding any constraints indicated by CLUE?
>
> I agree it can be problematic, but it's a problem we have to deal with 
> - middleboxes exist today that both monitor and alter SDP information, 
> and not all of them will understand CLUE. As such we need to make sure 
> that even if this leads to suboptimal behaviour it doesn't lead to an 
> invalid state of any sort. 
[CNG] If CLUE has references to the SDP and then the SDP gets changed 
doesn't that then lead to possible invalid state? i.e. an endpoint would 
receive a CLUE reference to SDP that is changed from what it originally 
intended?
>
> > Can you give examples of the reference CLUE->SDP? I've currently been
> > thinking that as SDP will be used to establish media after the CLUE
> > exchange that it would construct the SDP with a reference to the CLUE
> > media capture or other construct.
>
> Assocating capture scenes (or individual captures) with specific 
> m-lines in the advertisment is one example, to say what m-lines are 
> controlled by the CLUE channel. Another example is in the configure, 
> if the receive streams/encodings are defined in SDP then the 
> information on what capture is assigned to each of those 
> streams/encodings in CLUE will be such a reference.
[CNG] I can see that in a m-line you could reference a capture id, but 
I'm not sure how you would reference an m-line in a CLUE exchange. 
There's no m-line ID and given that the SDP exchange would occur after 
an Advertisement I'm not sure how this would be done?

>
> > Section 5: I support CLUE and SDP being independent. I'm abit confused
> > regarding the "reference to SDP contents". I take it that we're not
> > talking about using actual SDP in CLUE rather referring to the
> > information indicated by SDP.
>
> Yes, as you say - I was trying to steer clear of specific syntax since 
> there's no settled answer on how the SDP will look, but rather than 
> duplicating SDP information in the CLUE channel I was talking about 
> making references to existing SDP information.
>
> Rob
>
> On 28/02/2013 06:39, Christian Groves wrote:
>> Hello Rob,
>>
>> With regards to 4.2, you mention that middleboxes may want to alter the
>> SDP without involving themselves in CLUE. Isn't this fought with
>> problems if the middleboxes go and change SDP information related to
>> Clue without understanding any constraints indicated by CLUE?
>>
>> Can you give examples of the reference CLUE->SDP? I've currently been
>> thinking that as SDP will be used to establish media after the CLUE
>> exchange that it would construct the SDP with a reference to the CLUE
>> media capture or other construct.
>>
>> Section 5: I support CLUE and SDP being independent. I'm abit confused
>> regarding the "reference to SDP contents". I take it that we're not
>> talking about using actual SDP in CLUE rather referring to the
>> information indicated by SDP.
>>
>> Regards, Christian
>>
>>
>> On 19/02/2013 7:03 AM, Robert Hansen wrote:
>>> Hi all,
>>>
>>> lifespan on the topic of the interactions between CLUE signalling and
>>> SDP - as we've discovered when we've tried to define things like call
>>> flows a lot of the different aspects are dependant on each other,
>>> making it hard to make a decision. I picked a couple of points that I
>>> believe aren't so entangled.
>>>
>>> Some of these things in it are hopefully uncontroversial but haven't
>>> always been documented yet, others are likely to provoke more
>>> disagreement.
>>>
>>> There's no attempt in the draft at defining the SDP or CLUE messages,
>>> the draft merely discusses what information is needed in each and how
>>> they should interact.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 02:01:32 +0800

> receive a CLUE reference to SDP that is changed from what it originally

Of course this depends on what sorts of changes the middleboxes are 
making. There are no "rules" for this, so we can only work with known 
observed behavior. If the middlebox does something really awful then 
things are going to break.

Some things we know are relatively common are:
- admission control - looking at what the SDP needs and then
   accepting or rejecting the call. Not much we can do about this.

- limit media usage - perhaps block video at certain times.
   This will break TP. But as long as the blocking is done by
   zeroing out the ports in the m-lines we can at least work with
   what is allowed. If blocking is done by removing m-lines then
   it may make a terrible mess. But I don't think anyone does that.

- codec policing - remove "undesirable" codecs from offers and answers.
   We should be able to work with this, but depending on details it may
   make a mess.

- bandwidth limitation - adjust offers and answers to put reduced maxima
   on bandwidth. To some extent we can probably work with this.

- bandwidth policing - monitor media and block it when it exceeds the
   negotiated bandwidth. This should not cause us any trouble. But this
   can get complicated in some of the bundling proposals if the middle
   box doesn't understand the bundling. We need to consider that as part
   of the bundling proposals if we use them.

- gating media flows - block media from flowing except that which
   complies with observed O/A exchanges. This should be ok.

- policing SDP usage/syntax in general. This could cause great trouble
   if the middle box doesn't understand what we are using. But I don't
   think this is very common.

If we want to *refer* to the SDP from the CLUE signaling, then I expect 
it will be via a=label attributes in the SDP. We will be OK as long as 
middle boxes don't drop those labels. In general I think we will be OK.

> an Advertisement I'm not sure how this would be done?

a=label is intended for application level reference to the SDP.

If the SDP is to be updated *after* the CLUE exchange, then the 
reference may not be satisfied until it is. But in some cases it will 
make sense to reference SDP that is already in effect.

	Thanks,
	Paul