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 <[email protected]
<mailto:[email protected]>>
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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
