[SR-Users] Reuse TLS connections

[Klaus Darilion]

tcp_accept_aliases should work if you trust the other side. But do not 
accept aliases from untrusted nodes (e.g. SIP phones)

regards
klaus

On 15.02.2012 12:37, Bruno Bresciani wrote:
> Thank's for reply klaus
>
> you are correct when said "Unless you have s strange setup with strange
> requirements", but I was reading RFC 5923 to try solve my strange
> requirements and found some benefits to forcing all messages into a
> single TLS connection.
>
> I have included the flag *"tcp_accept_aliases = yes"* on kamailio.cfg
> and now if kamailio received a message with the parameter "aliases" at
> header Via, all messages will be forced into a single TLS connection
> with SIP server. I'm testing this config yet.
>
> Best Regards
>
>
> 2012/2/13 Klaus Darilion <klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>>
>
>
>
>     On 13.02.2012 18:07, Bruno Bresciani wrote:
>
>         Hi all,
>
>         There is the possibility to kamailio reuse the TLS connection
>         created by
>         other SIP server?  When kamailio use t_relay function to send a SIP
>         request message to other server, kamailio verify if already
>         exist some
>         connection established with the destiny and use it even if this
>         connection was created by the other SIP server.
>
>         In short, I want to keep only one connection between kamailio
>         and SIP
>         server. Sometimes kamailio will be a client and others a server.
>
>
>     This is quite difficult. For example, on a server with a single IP
>     address may run several SIP proxy instances with different purposes.
>     Each of these proxies uses another listening port, e.g: 1.1.1.1:5061
>     <http://1.1.1.1:5061>, 1.1.1.1:6061 <http://1.1.1.1:6061>,
>     1.1.1.1:7061 <http://1.1.1.1:7061>.
>
>     If on of these proxies establish a TCP connection to another proxy,
>     e.g. 2.2.2.2:5061 <http://2.2.2.2:5061>, it uses an ephemeral
>     source-port. Thus, for the TLS-server (the receiver of the TLS
>     connection) there is no way to know which of these SIP proxies on
>     1.1.1.1 established the connection. There are lots more issues e.g.
>     with certificate validation - a proxy may use various certificates
>     for several domains. Maybe you can overcome these problems if all
>     the proxies are controlled by you, but in an open environment this
>     kind of connection reuse does not work.
>
>     Thus: connection reuse can only be used for transactions in the same
>     direction with the same target domain. For example if you have a
>     proxy at 1.1.1.1:5061 <http://1.1.1.1:5061> authoritative for
>     a.example.com <http://a.example.com> and b.example.com
>     <http://b.example.com> and you have a proxy at 2.2.2.2:5061
>     <http://2.2.2.2:5061> authoritative for y.example.com
>     <http://y.example.com> and z.example.com <http://z.example.com> then
>     you will end up with 4 TLS connections:
>
>     1. 1.1.1.1 as TLS client to a.example.com <http://a.example.com>
>     2. 1.1.1.1 as TLS client to b.example.com <http://b.example.com>
>     3. 2.2.2.2 as TLS client to y.example.com <http://y.example.com>
>     4. 2.2.2.2 as TLS client to z.example.com <http://z.example.com>
>
>     Unless you have s strange setup with strange requirements I do not
>     see any benefit in forcing all messages into a single TLS connection.
>
>     regards
>     Klaus
>
>