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

[Paul Kyzivat <[e-mail]>]

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