[bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?

[Christer Holmberg <[e-mail]>]

Hi,

I realize the following comes late in the process, and I apologize if it has been discussed, but it is related to something which just has recently popped up in 3GPP, and it's not addressed in the draft.

Section 7 says the following:

"For a TCP/TLS connection established using an SDP
                offer/answer exchange [7], the answerer (which may be the client or
                the floor control server) always acts as the TLS server."

Q1:

Assume the TCP/TLS connection, for whatever reason, goes down.

Now, I assume that whoever endpoint is "active" will most likely try to re-establish the TCP connection.

But, if the "active" endpoint doesn't send an Offer (i.e. it simply tries to re-establish the TCP connection based on the previously negotiated SDP information), who will act as TLS server? There is no Answerer.

One alternative would be to mandate the sending of an Offer when the TCP/TLS connection is re-established. Then it would be clear who is Offerer, and who is Answerer.

Another alternative would be to say that whoever was previously Answerer will act as TLS server.


Q2:

Assume there is an Offer/Answer transaction during the session. Now, the TCP/TLS connection is not affected by that, but the TLS roles may change (if whoever was Offerer in the previous O/A transaction is now Answerer).

I think some wording would be needed about that also.

One alternative is to say that the TLS roles may change, but that doesn't affect the TCP/TLS connection.


Regards,

Christer