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

[Paul Kyzivat <[e-mail]>]

Christer,

After rereading this and checking 4583, I realize my comment was based 
on a misunderstanding of what BFCP was doing. I thought you were saying 
that BFCP didn't use a=setup, and that the active party for the TCP/TLS 
connection was always the offerer. I see that was wrong - that it uses 
a=setup for that and says that the answer is the TLS server.

BFCP seems to have arranged its authentication so either end is capable 
of being the TLS server, and it is only necessary to have *some* 
mechanism for deciding which one will be. As long as that is the case, I 
don't have a particular problem with it.

	Thanks,
	Paul

On 5/3/13 2:58 AM, Christer Holmberg wrote:
> 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
>
>