Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

[Roman Shpount <[e-mail]>]

Hi Christer,

I have looked through the slides and I think they are misleading. To me
they seem to imply that DTLS association is orthogonal to transport and
only gets re-established when fingerprint changes. In other words, even if
the underlying transport changes, but fingerprint stays the same, the
slides imply that existing DTLS association continues to be used with the
new transport. BTW, I think this is what Chrome is currently doing. This
behavior is against the proposed specification language ("If the underlying
transport protocol is modified, the endpoints MUST establish a new DTLS
connection"). This also presents a serious problem in the use case where
third party call control is used to move the call between the several end
point that use the same site-wide certificate. All of those end points will
present the same fingerprint, but the DTLS connection will need to be
re-established since the media connection is moved to a different device.
This also shows that fingerprint alone cannot be used to determine that
connection moved to the new device.

I thought the logic that made sense was:
1. DTLS connection is re-established whenever underlying transport changes
(already in the specification).
2. Fingerprint and setup role MUST not change unless underlying transport
changes as well (already in the specification).
3. Unless ICE is used, underlying transport is considered changed if
5-tuple for connection changes  (already in the specification)
4. In case of ICE, the underlying transport is considered changed if ufrag
and entire candidate list changed on either side of the call (missing from
the current specification).

In the proposed text, the issue that I have is with the phrase
"Implementations MUST treat all ICE candidate pairs associated with a an
SCTP association on top of a DTLS connection as part of the same DTLS
connection". I am not 100% sure what this means and even if this is
accurate. "All ICE candidate pairs associated with a an SCTP association"
is unclear to me. Does this refer only to the candidate pairs for the
current ICE session or to the candidate pairs for any future ICE sessions
associated with this SCTP association?

Original text from RFC 5763 ("Implementations MUST treat all ICE candidate
pairs associated with a single component as part of the same DTLS
association") is more accurate but suffers from the fact that "single
component" is not well defined and because of this runs into similar
issues. Does ICE re-start creates a new component or is old component
considered to be re-used? If component is specific to ICE session (ufrag
pair), can candidates from the previous session be re-used for negotiating
a new component? If they can, how do you de-mux packets received between
old and new component if candidates were reused on both sides.
_____________
Roman Shpount