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

[Christer Holmberg <[e-mail]>]

Hi,

>Wordsmithing: the more precise term would be "valid ICE candidate pair".
>See inline...
>
>> 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/

I'll fix that.

Thanks!

Regards,

Christer



>> *   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