Re: [MMUSIC] DTLS-SRTP client/server role negotiation

["Charles Eckel (eckelcu)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Justin Uberti
> Sent: Friday, May 03, 2013 11:15 AM
> To: Martin Thomson; Eric Rescorla
> Cc: Paul Kyzivat; Alan Johnston; [e-mail]
> Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
> 
> 
> 
> 
> On Fri, May 3, 2013 at 10:29 AM, Martin Thomson
> <[e-mail]> wrote:
> 
> 
> 	On 2 May 2013 22:53, Justin Uberti <[e-mail]> wrote:
> 	> This is where the OP's question came from - the differing policy
> between
> 	> Chrome and Firefox. I (regarding Chrome) had figured that if ICE had
> made a
> 	> determination regarding which side was in charge, the other layers in
> the
> 	> stack should do the same, but it sounds like there are already
> established
> 	> rules on how to do this.
> 	>
> 	> From this thread, it sounds like the recommendation is to use
> 	> a=setup:actpass in the offer, and then the answerer can use
> a=setup:active
> 	> to choose the client role. In 3pcc cases, the B2BUA can select
> a=setup
> 	> appropriately to avoid any issue.
> 	>
> 	> Is that an accurate summary, and is there consensus on this?
> 
> 
> 	The answer should probably be a=setup:passive, so that you don't have
> 	any disconnect on what candidate pair is nominated.  And you don't
> pay
> 	an extra half-RTT.  But otherwise, yes.
> 
> 
> 
> http://tools.ietf.org/html/rfc5763 recommends a=setup:active for the
> answerer, and Eric convinced me that any perf benefit from doing anything
> different was nominal.
> 
> If the answerer's initial ICE checks reach the offerer, the client hello can be
> sent by the answerer in 1.5 RTT, or the offerer in 2.0 RTT:
> 0.0: A: offer
> 0.5 B: answer
> 0.5 B: binding request
> 1.0 A: binding response
> 1.0 A: triggered binding request (USE-CANDIDATE)
> 1.5 B: DTLS client hello
> 
> If not, the client hello is sent by the answerer in 2.5 RTT, or the offerer in 2.0
> RTT:
> 0.0: A: offer
> 0.5 B: answer
> 0.5 B: binding request (dropped)
> 1.0 A: binding request (USE-CANDIDATE)
> 1.5 B: binding response
> 1.5 B: triggered binding request
> 2.0 A: binding response
> 2.5 B: DTLS client hello
> 
> So overall it's a bit of a wash, and therefore simpler to stick with 5763's
> recommendation.

Sorry for the delayed comment on this thread, but I wanted to state than I agree. In addition, this is consistent with the recommendations provided by the BFCPBIS WG when using DTLS with BFCP over UDP:
http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-07#section-9

Cheers,
Charles