Subject: [clue] Some thoughts about CLUE signaling

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Dec 2012 16:11:55 -0500

In hopes of kickstarting more work on clue signaling, here are some 
thoughts I have on the subject. I request comments about this, 
especially from those of you signed up to work on signaling:
- Rob Hansen
- Roni Even
- Simon Pietro-Romano
- Roberta Presta
- Christer Holmberg

First, we need to agree on what is included in the subject "clue 
signaling". I consider all of the following are aspects/dimensions to 
the subject:

1) the clue-specific signaling protocol
    a) the messages: advertisement, configure, ack?, nak?
    b) the payload of advertisement & configure (from data model)
    c) sequencing of clue messages, state machines
2) clue use of SDP O/A, including establishment of clue message channel
3) linkage & sequencing of clue-specific messages and SDP O/A
4) sip signaling (this may be unremarkable)
5) interop with legacy SIP devices
6) clue over RTCWEB

I expect that the clue signaling document will cover all of these 
subjects. (Perhaps with the exception of RTCWEB.) I have no strong 
preference at this time about the document structure to cover these.

I have thought some about the sequencing of clue messages. The following 
are some thoughts on that. These may be entirely obvious to everyone. 
(If so, hurray!) But I'll have a better idea after everyone concurs, or not.

- media for a capture encoding will not be sent unless it has
   been configured. (Exception: prior to first adv/cfg exchange,
   which includes compatibility with non-clue endpoints.)

- a capture must be advertised before it can be configured.
   (This is fundamental, the config must reference identifiers
   from the advertisement for the capture & encoding.)

- when a provider wishes to stop sending a capture encoding that has
   been configured, it *should* *first* send a new advertisement
   that no longer advertises that capture and/or encoding, and should
   wait for that advertisement to be acknowledged.

- if a provider must stop sending a capture encoding before advertising
   that it is not available, it *must* still send an advertisement
   indicating this at the first opportunity.
   (Until it gets this, the consumer is likely to treat the
   missing capture encoding as an error, giving a poor user experience.)

- when a consumer receives a new advertisement that no longer
   offers a capture and/or encoding that is currently configured,
   that is an indication that the capture is no longer available and will
   most likely no longer be sent. The consumer should not
   consider it an error when that capture encoding is no longer received.

- when a consumer receives a new advertisement, it *should*
   send a new configuration asap that is consistent with the
   new advertisement. This means it references the new
   advertisement and it configures only captures and encodings
   mentioned in that advertisement.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 19 Dec 2012 11:00:26 +1100

Hello Paul,

Please see my comments below.

Regards, Christian

..snip..
> 2) clue use of SDP O/A, including establishment of clue message channel
[CNG] Need to consider removal of clue channel?

> 5) interop with legacy SIP devices

[CNG] I would also add to the list clue interaction with any call / 
bearer release/teardown. Also "in session" modification is something 
also to cover.
> I have thought some about the sequencing of clue messages. The 
> following are some thoughts on that. These may be entirely obvious to 
> everyone. (If so, hurray!) But I'll have a better idea after everyone 
> concurs, or not.
>
[CNG] How does this relate to any call bearer / release signalling?
>   missing capture encoding as an error, giving a poor user experience.)
[CNG] Assuming that the CLUE channel is still up?
>   consider it an error when that capture encoding is no longer received.
[CNG] I guess its important to understand what that then means for SIP/ 
SDP OA signalling. Its one thing to say not an error but should it 
trigger some signalling.
>   mentioned in that advertisement.
[CNG] The current framework says that this is not necessary. A new 
configuration is only sent if the old configuration is invalid. From a 
protocol perspective I think its good practise to send an 
acknowledgement but the transport may give that indication.

>
>     Thanks,
>     Paul
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Dec 2012 12:56:23 +0000

Hi,

Below is an attempt to structure the bullets in Paul's list:

Q1: The initial SDP offer/answer and establishment of the CLUE channel:

This is bullet 2) in Paul's list, and based on my suggestion to specify how such SDP offer will look like, that also covers interop with legacy SIP devices (bullet 5).

(Assuming we will use offer/answer to establish the CLUE channel, I assume we will also use offer/answer to remove it, by setting the port to zero for the m- line associated with the CLUE channel).

Q2: The advertisements, configurations and additional SDP offer/answers in order to establish the CLUE session:

This covers bullets 1) and 3) in Paul's list.

Bullet 4) is perhaps not a standalone task, but will need to be considered in other bullets.

I really don't think we have to think about RTCWEB at this point, because there is still lots to do in that area before we can even do something useful.

Q3: Mid-session acknowledgements/configurations

This covers bullet 1).

In general I also think it's good to acknowledge a new advertisement with a configuration. 

However, I think mid-session acknowledgements will be EXTREMELY rare, so I would even suggest to leave that for now and focus on the session establishment.

Mid-session configurations might be a little more common, e.g. if a receiver wants to switch from a capture of Paul to a capture of Christian. But, assuming the original advertisement contained the captures for both Paul and Christian, no new advertisement is needed for that. A new SDP offer/answer might also be needed, if the capture switch has impact on the SDP.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 19. joulukuuta 2012 2:00
To: Paul Kyzivat
Cc: CLUE
Subject: Re: [clue] Some thoughts about CLUE signaling

Hello Paul,

Regards, Christian

..snip..

> 5) interop with legacy SIP devices

[CNG] I would also add to the list clue interaction with any call / bearer release/teardown. Also "in session" modification is something also to cover.
>   consider it an error when that capture encoding is no longer received.
[CNG] I guess its important to understand what that then means for SIP/ SDP OA signalling. Its one thing to say not an error but should it trigger some signalling.