Okay, this all gets a little bit complicated and rather interesting. The following is purely my own reasoning.
We should not forget that we are talking a TLS layer context here, _not_ TCP. That is, the underlying TCP connection should not require a continuous _established_ state. But rather the TCP connection that is utilised by the TCP context could fail, be re-established, fail gain and so on.. And IMHO the TLS connection should be considered as being valid, as long as after the re-connection the remote site resumes with the valid TLS context. What I am trying to say, is that at the SIP layer, transactions are _not_ invalidated if the TCP connection to the remote site goes down. SIP transaction has it's own context, independent to TCP. So does the TLS. So I can't see how TLS connection could be made invalid by anything else but TLS layer. I mean, can somebody define when TLS connection is broken? Is it timeout, or something else, cause looking at rfc5246 I can't find anything related.. Comments please, Regards, Brez On Wed, Jul 6, 2011 at 8:11 PM, Olle E. Johansson <o...@edvina.net> wrote: > > 6 jul 2011 kl. 18.19 skrev Iñaki Baz Castillo: > > > 2011/7/6 Olle E. Johansson <o...@edvina.net>: > >> - A proxy (A) forwards a SIP request with a SIPS r-uri to another proxy > (B). The VIA header indicates SIPS and has a domain name. The proxy that > receives the request shows a server CERT, but doesn't require a client > certificate. > >> > >> 1) For the response - can we reuse the connection? > > > > Yes, always. Responses for request arrived via TCP/TLS/SCTP must reuse > > the same connection if available. > But SIP outbound says that this only applies when we have mutual TLS > identification - client and server certificate. > > > > > > >> 2) If the connection is lost, does proxy B has to open a new TLS > connection back to A, validating A's certificate agains the via header? > > > > IMHO it must easier don't perform such exotic step in RFC 3261. This > > is, if the response cannot be sent using the same connection, the > > client (proxy A) should realize that the connection is closed and > > should/could terminate current transaction and generate a new one. > > Well, one of the benefits with stateless proxies and load balancing using > SRV is that you can in fact activate fail over even for responses. What you > say breaks this. > > > > > I've seen no implementation performing such fallback mechanism for SIP > > responses (which usually never work due to common NAT scenarios and > > so). > We're talking proxy to proxy. The UA might be behind NAT, but in this > scenario I am assuming no NAT between the proxys. > > > > > >> 3) for a request from the UA behind proxy B to the UA behind proxy A > (contacts use TLS, record-route use TLS), can we reuse the existing > connection that was used for the connection from proxy A to proxy B? > > > > Only if proxy A uses ";alias" parameter in Via header and proxy B > > validated the TLS certificate given by proxy A during the request > > sending. > > > RIGHT! Which means that you require client certificate when proxy A sets up > the connection to proxy B. We agree here. > > /O _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
