Subject: [clue] Clue signaling alternatives discussed at the interim

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Feb 2012 17:18:16 -0500

I promised to post a cleaned up version of the three alternative 
approaches to signaling for CLUE that we discussed and wrote on the 
whiteboard during the interim last Thursday. Following is my attempt at 
that.

	Thanks,
	Paul

This covers the signaling for establishment of a point-to-point clue 
session. It assumes symmetry - that the two participants are comparable 
and it doesn't matter which one initiates the session. However I think 
everyone agreed that its also applicable to a session established 
between a room and an MCU. This assumes that there are two 
capabilities/advertisement/selection exchanges traveling in opposite 
directions. These are denoted as caller-capabilties, callee-capabilties, 
etc. So the two exchanges consist of:

- caller-capabilities, callee-advertisement, caller-selection
- callee-capabilities, caller-advertisement, callee-selection

Each approach is a different way of combining/coordinating these 
exchanges with sip signaling. In the meeting we labeled these 
alternatives A, B, C. I've preserved and extended this to A1, A2, B1, B2, C.

_______________________________

A) (this was really two alternatives run together. I've broken it out as 
two.)

A1) The advertisement/selection are encoded in SDP offers and answers, 
using some combination of existing and new SDP syntax.

- caller-advertisement in the SDP of the initial SDP offer.

- callee-selection in the SDP of the initial SDP answer.
- callee-advertisement is also in the SDP of the initial SDP answer.

- caller-selection in the SDP of a 2nd SDP offer.

This doesn't include a way to send capabilities.

The encoding is presumed to build on standard SDP audio and video media 
syntax in such a way that a callee that doesn't support clue will still 
be able to accept the basic audio and/or video.

A2) The capabilities/advertisement/selection are encoded in a separate 
body part with the sip messages, coexisting with the SDP offers and 
answers. This entails use of multipart/mixed so that both can reside in 
the same message. The encoding within this body part could be XML or 
something else.

- caller-advertisement in a separate body part with the
   initial SDP offer.

- callee-selection in a separate body part with the
   initial SDP answer.
- callee-advertisement is also in a separate body part with the
   initial SDP answer.

- caller-selection in a separate body part with a
   2nd SDP offer.

This doesn't include a way to send capabilities.

Its hoped that a UA that doesn't support CLUE will be able to deal with 
the multipart and find the SDP offers and answers while ignoring the 
clue-specific body part.

_______________________________

B) The initial INVITE offers "generic" audio and video, designed to be 
widely acceptable to audio and video UAs that don't support CLUE. It 
includes added syntax proposing establishment of a separate channel for 
clue signaling. Then clue capabilities/advertisemens/selections are 
exchanged over this channel. Finally there is a 2nd offer/answer 
exchange to establish media streams in accord with the selections.

There are two variations on this:

B1) and added m-line that establishes a "media" stream for signaling
     clue (analogous to bfcp).

B2) OR the offer of support for a new clue INFO-package.

If the callee doesn't support clue, then the clue channel will not be 
established, and the caller will set things up accordingly using the 
generic audio and video streams.

_______________________________

C) This is a variation on (B). It differs in that the encodings and 
encoding groups are represented in the SDP of the offer and answer (as 
they are in A1) but the remainder of the clue-specific info is exchanged 
in the separate clue signaling channel specified in (B).

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Feb 2012 18:16:48 -0500

Note - I intentionally didn't comment on the pros/cons of these 
alternatives. I'm leaving that for followup discussion.

Feel free to expand these, or offer further alternatives.

	Thanks,
	Paul

On 2/20/12 5:18 PM, Paul Kyzivat wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Roni Even" <[email-masked]>
Date: Mon, 27 Feb 2012 11:17:45 +0200

Hi Paul,
A general comment, I think that we have an open issue if CLUE need three
messages or two messages. Consumer capabilities message is still in
question.

As for the description I think we should use the consumer, provider terms so
we have  for example in A caller provider advertisement and callee consumer
configuration.

As for A1, I am not sure that this was the proposal on the whiteboard but it
is a valid option for the moment.

My understanding is that we discussed A2 where the CLUE exchange is done in
a separate MIME body in the offer answer exchange and having the individual
encodes as part of the regular SDP. The major point about A is that the
initial offer may include all media channels using grouping probably based
on http://www.ietf.org/id/draft-ietf-mmusic-sdp-bundle-negotiation-00.txt .
We also had another option based on A2 which will carry the CLUE messages in
a separate SIP method for example using an INFO package. This will mean a
two stage call setup starting with one audio and maybe one video and adding
the rest after doing the CLUE negotiation. I think that this is what you
call B2.

I think it can be broken differently

Three main topics:

A) how to carry the CLUE information:

1. Using SIP offer answer with a second MIME body for CLUE.
2. Using SIP offer answer with an offer for a CLUE channel (similar to BFCP
channel open)
3. Using SIP offer answer and doing CLUE using another SIP method for
example using INFO package

B) What does the initial offer answer include (here we are also assuming
that CLUE endpoint MUST support ssrc multiplexing but not necessarily using
one UDP port):  

1. All possible simultaneous media lines described in SDP (based on bundle)
in the initial offer answer. See
http://tools.ietf.org/html/draft-even-clue-rtp-mapping-00 
2. SDP will have one audio and one video (maybe two) and all media captures
will be negotiated based on CLUE and
http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-02 

C) Is it required to have the offer answer with SDP refelct all the
currently configured media streams in order to address intermediaries like
SBCs. This was discuss in MMUSIC see
http://tools.ietf.org/html/rfc5939#section-3.12 

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Tuesday, February 21, 2012 12:18 AM
> To: CLUE
> Subject: [clue] Clue signaling alternatives discussed at the interim
> 
> directions. These are denoted as caller-capabilties, callee-
> capabilties, etc. So the two exchanges consist of:
> 
> they are in A1) but the remainder of the clue-specific info is
> exchanged in the separate clue signaling channel specified in (B).

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Feb 2012 12:44:20 -0500

> messages or two messages. Consumer capabilities message is still in

Yes, I realize that. I think part of this exercise is to explore 
alternatives, including those that support it and those that don't.

> we have  for example in A caller provider advertisement and callee consumer

Perhaps. I hadn't thought about it when writing those words. I think 
this can be added, though I don't think it really changes anything 
fundamentally. The provider/consumer distinction is analogous to the 
UAS/UAC distinction - its a role, with most devices supporting both.

When sending an advertisement, it is necessarily the case that the 
device sending it is the provider and the one receiving it is the 
consumer with respect to that message. My point in using the 
caller/callee distinction in this description was because that 
distinguishes one endpoint from the other.

> is a valid option for the moment.

On the board I had written "in/with" to cover the two alternative ways 
of conveying the clue messages - either "in" the SDP, or "with" the SDP 
but in a separate body part. My intent with A1 and A2 was to cover both 
of these cases in a way that is more explicit and less confusing.

Your questioning of this is evidence of the value of clarifying what we 
thought we were talking about. And of course, just because it is 
included as an alternative doesn't mean that it will ultimately be 
chosen. Maybe it will quickly be discarded. But lets see what others 
have to say about it.

> I think it can be broken differently

My hope was that what I wrote described what we discussed in the room.
I was expecting the subsequent development to:

- refine one or more of the alternatives I documented.
   (this could just add/change the text, if there is
   general agreement, or further split an alternative,
   such as A1.1, A1.2 if we want to explore different directions

- adding additional alternatives - e.g. B3 or D or E

- agreeing that we are not interested in further pursuing some
   of the alternatives.

I think what you are describing below is a different perspective on the 
same thing. What we did in the meeting was, effectively, some 
alternative Use Cases. The breakdown below is a start at describing some 
mechanisms to support those use cases.

IMO both are useful, as long as we are clear that they are distinct, 
though related, things.

> 1. Using SIP offer answer with a second MIME body for CLUE.

Note that when going this way, it isn't necessary that the new bodies 
always accompany offers or answers. There may be cases when no offer or 
answer is needed but there is still a desire to convey CLUE info - e.g. 
capabilities.

I realized that while writing up the alternatives, but was waiting to 
bring it up because I first wanted to get down what we had discussed.

> http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-02

Just to check if I understand you: you mean that the negotiations in (2) 
above will be confirmed by (C) below?

	Thanks,
	Paul