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

[Christer Holmberg <[e-mail]>]

Hi Paul,

>> RFC 4572 specifies that the "active" endpoint also takes the role as TLS client. At least MSRP refers to RFC 4572.
>>
>> AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act as TLS client - ie it separates the TCP setup from TLS roles - which I think is very good.
>
> I think that approach has limitations. What does one do when doing a subsequent o/a, especially in the opposite direction?

Well, I could ask you to look it up in the BFCP RFC, but I doubt you'll find an answer there :)

> And how does one distinguish when in a subsequent o/a you do/don't want to reestablish the connection rather than retaining the existing one?

I would need some more time to think about that, but a few questions that came to my mind:

1) If the TLS connection already exists, is there a reason to reestablish it to begin with?

2) Would you need an o/a to reestablish the TLS connection to begin with? Once the roles have been determined (in the initial o/a), can't everything be handled on the TLS layer?

3) If the TLS connection already exists, is there a reason to renegotiate the TLS roles?

4) If a subsequent o/a is needed in order to reestablish the connection, and/or renegotiate the TLS roles, could the TLS connection first be terminated on the TLS layer, before the subsequent of/a is sent?

Regards,

Christer