Re: [clue] comment on conclusion 7 of the interim meeting report

["Roni Even" <[e-mail]>]

Paul,
Here is a scenario  two endpoints A and B support CLUE. Let's say that A is
a one camera system with two monitors that support also H.239 like
presentation. So it sends an offer with CLUE channel and the SDP will
include the people video stream and the support for BFCP and the content.
B responds with similar SDP and the CLUE channel is opened, now B sends an
advertisement with one video media capture and also a second capture scene
indicating it can send a presentation. So this looks like two similar
systems. Now what is the reason for A to send an advertisement, for
all-purpose he can close the clue channel and continue as non-clue call. The
reason to open the CLUE  channel is because the systems do not know when
starting the call what is in the other side before opening a CLUE channel.

I am not sure what a default advertisement is?  
I am not sure that there is a requirement to have advertisements in both
directions. 
 Also According to SIP, media can flow when a receive port is available in
the O/A and I do not think we intend to change the semantic of SIP and this
is also what the call flow document described.

Practically, it make sense to send media ASAP (at least audio and probably
video) in order to provide a better user experience (once connected you
expect to be able to speak and hear the other side.

BTW: I think that having max-ssrc for SSRC multiplexing can help both side
to see that there is no need for CLUE here.

Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]] 
Sent: 09 October, 2012 8:26 PM
To: Roni Even
Cc: [e-mail]
Subject: Re: [clue] comment on conclusion 7 of the interim meeting report

On 10/9/12 12:49 PM, Roni Even wrote:
> Paul,
> I think that the change I proposed is in-line with conclusion 9, where 
> the media started based on the first offer answer and the 
> advertisement may be done later.
>   This is also the call flow in
> http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 .

I think there is a difference (at least there could be) between the defaults
that apply before the first exchange of advertisements, and what happens
later.

We discussed the possibility that there could be a well defined "default"
advertisement that is assumed until an actual advertisement is received.
(Though I don't think we reached any conclusion.)

What we didn't discuss what what that default might be, or whether it would
be "fixed" or "derived" from the SDP.

We *did* discuss the possibility that if there was an explicit way to say
you wanted the default advertisement then you might be able to revert to the
default advertisement at a later point in the session, and that that could
be useful.

Perhaps you are suggesting that the "empty" advertisement means the same as
the "default" advertisement - to do whatever is implied by the SDP. 
That is *possible*, but it doesn't seem like the obvious choice to me.

	Thanks,
	Paul

> Roni
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Paul Kyzivat
> Sent: 09 October, 2012 5:55 PM
> To: [e-mail]
> Subject: Re: [clue] comment on conclusion 7 of the interim meeting 
> report
>
> Roni,
>
> On 10/9/12 3:03 AM, Roni Even wrote:
>> Hi
>>
>> 7) Empty Advertisement:  Is this allowed and what does it mean?
>>
>> Conclusion: Yes. It means you have nothing you are willing to send.
>> May also still want media in other direction.
>>
>> I think that the correct sentence is "It means you have nothing you 
>> are willing to advertise". The SDP is still there and you can still 
>> send media based on the SDP.
>
> Hmm. I think what you say requires some discussion.
>
> When a clue endpoint connects with another endpoint that doesn't 
> support clue it is clear that one should decide what to do based on 
> the SDP in a normal non-clue way.
>
> But when both ends support clue and exchange advertisements it isn't 
> clear to me what should be done about stuff described in SDP that 
> isn't negotiated via the advertisements.
>
> ISTM that there are different possible philosophies here, that we 
> haven't discussed, or even realized need to be discussed. Off the top of
my head:
>
> 1) we could consider that advertisements and configurations provide 
> the high level view of the session, while the SDP provides a lower 
> level mechanism to support that and fill in details. There is a clear 
> mapping from elements in the configurations to elements in the SDP. 
> The meaning of the SDP for proper rendering can't be discerned from 
> the SDP alone - the advertisement and configuration are required to 
> understand it. Any "extra" SDP that isn't referenced from the 
> advertisements and configurations then probably doesn't apply to the
telepresence session.
> It may be ignored, or else may relate to some other "application"
> sharing the same session.
>
> 2) we could consider that the negotiated SDP in the session is the 
> primary representation of the telepresence session. In principle this 
> could be sufficient without exchange of any advertisements and
configurations.
> Advertisements and configurations are exchanged to
> *supplement* this - provide extra hints about what to do when the SDP 
> itself isn't sufficient, and also to provide hints about what SDP 
> would be fruitful to negotiate. Any SDP that isn't referenced by 
> advertisements and configurations should be taken at face value and 
> fitted into the telepresence session using local algorithms.
>
> Frankly I had been thinking that (1) was the intended way. It wasn't 
> until your message that I realized there might be another view.
>
> It seems to me that this needs careful consideration.
>
> 	Thanks,
> 	Paul
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>
>