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

[Simon Perreault <[e-mail]>]

Wordsmithing: the more precise term would be "valid ICE candidate pair".
See inline...

Le 2015-03-28 05:52, Christer Holmberg a écrit :
> Hi,
> 
>  
> 
> Below is some suggested text (the new text is in bold) to cover ICE
> “virtual connections” in the SCTP-SDP draft:
> 
>  
> 
> 9.3.3.  TLS Role Determination
> 
>  
> 
>    If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or
> 
>    'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the
> 
>    (D)TLS roles of the endpoints.  Following the procedures in
> 
>    [RFC4572], the 'active' endpoint will take the (D)TLS client role.
> 
>  
> 
>    Once the DTLS connection has been established, the endpoints MUST NOT
> 
>    modify (as result of an offer/answer exchange) the TLS roles, or the
> 
>    'active/passive' status, of the endpoints, unless the underlying
> 
>    transport protocol is also modified (e.g. if an IP address- or port
> 
>    value associated with the transport protocol is modified).
> 
>  
> 
>    If the underlying transport protocol is modified, the endpoints MUST
> 
>    establish a new DTLS connection.  In such case the 'active/passive'
> 
>    status of the endpoints will again be determined following the
> 
>    procedures in [RFC4145], and the new status will be used to determine
> 
>    the (D)TLS roles of the endpoints associated with the new DTLS
> 
>    connection.
> 
>  
> 
>    NOTE: The procedure above is identical to the one defined for SRTP-
> 
>    DTLS in [RFC5763].
> 
>  
> 
> *   NOTE: As described in [add-reference], if the Interactive*
> 
> *   Connectivity Establishment (ICE) mechanism [RFC5245] is used, all ICE*
> 
> *   candidates associated with an SCTP association on top of a DTLS*

s/ICE candidates/valid ICE candidate pairs/

> 
> *   connection as part of the same DTLS connection.  Thus, a switch from*
> 
> *   one candidate pair to another candidate pair will not trigger the*
> 
> *   establishment of a new DTLS connection.*
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 12.2.  ICE Considerations
> 
>  
> 
>    At the time of writing this specification, no procedures have been
> 
>    defined for using ICE [RFC5245] together with SCTP as transport layer
> 
>    protocol.  Such procedures, including the associated SDP Offer/Answer
> 
>    procedures, are outside the scope of this specification, and might be
> 
>    defined in a future specification.
> 
>  
> 
>    When the transport layer protocol is UDP (in case of an SCTP
> 
>    association on top of a DTLS connection on top of UDP), if ICE is
> 
>    used, the ICE procedures defined in [RFC5245] are used.
> 
>  
> 
>    When the transport layer protocol is TCP (in case of an SCTP
> 
>    association on top of a DTLS connection on top of TCP), if ICE is
> 
>    used, the ICE procedures defined in [RFC6544] are used.
> 
>  
> 
> *   Implementations MUST treat all ICE candidate pairs associated with a*

s/ICE candidate pairs/valid ICE candidate pairs/

> 
> *   an SCTP association on top of a DTLS connection as part of the same*
> 
> *   DTLS connection.  Thus, there will only be one DTLS handshake even if*
> 
> *   there are multiple valid candidate pairs, and shifting from one*
> 
> *   candidate pair to another will not impact the DTLS connection.  If*
> 
> *   new candidates are added, they will also be part of the same DTLS*

"If new candidate pairs are added to the valid list, ..."

> 
> *   connection.*
> 


Simon