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

[Justin Uberti <[e-mail]>]

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.