Subject: [clue] decisions and issues re establishment of clue channel

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Apr 2014 11:27:36 -0400

In the design team call today we got into a discussion about how to 
specify which end of the sip session is responsible for opening the clue 
channel. The following is a summary of what I think we agreed:

- There was a proposal that it is an error to have a clue group that
   doesn't include an sctp m-line. I think there was general agreement
   with this.

- The end that creates the sctp association - the end that is
   *active* according to RFC 4572/4145 - will be responsible for
   the initial open, and for reopening after a reset as long as
   association is working and is part of the clue group.

- If the association is reestablished (signaled by a=connection:new)
   then the end that is responsible is redefined at that time by the
   end that is active for establishing the new association.

- we didn't discuss a case where the sctp association is first
   established but is not part of a clue group, and is later added
   to the clue group. IMO, in this case the responsibility should
   still be the end that was active for establishment of the association.

- another we didn't discuss is what happens if there is clue channel
   open and then the sctp association is removed from the clue group.
   (This means that there should be no clue group, so indicates a
   change to legacy mode.) It is possible that the sctp m-line is
   still in the SDP, just not in the clue group, and is still functional.
   I think, in this case that what happens to the clue channel is
   undefined. But if it is reset, then the active end of the association
   is *not* responsible for opening it again.

Based on this, we have some issues to bring to MMUSIC for clarification:

- draft-ietf-mmusic-sdp-mux-attributes specifies that a=setup
   and a=connection must be identical across all bundled m-lines.

- draft-ietf-mmusic-sctp-sdp specifies use of a=setup and
   a=connection as specified in rfc4145.

- RFC 5763 (section 5) forbids use of a=connection for
   UDP/TLS/RTP/SAVP.

This is a conflict. It appears that draft-ietf-mmusic-sdp-mux-attributes 
needs to be revised. Perhaps it can say that a=connection must be 
identical across all bundled m-lines *that permit the use of a=connection.*

And then we have a general concern over the progress of 
draft-ietf-mmusic-sctp-sdp.

	Thanks,
	Paul