29 Oct
2012
29 Oct
'12
11:45 a.m.
29 okt 2012 kl. 10:52 skrev Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Agree. Just wanted to check.
On 26.10.2012 22:03, Olle E. Johansson wrote:
Will that happen with Kamailio today?
Won't the TCP matching make us reuse the existing connection?
26 okt 2012 kl. 21:08 skrev Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Not necessarily. Usually SIP clients are behind NAT (not servers) and thus we need NAT
traversal for these clients and these clients usually do not have a client certificate.
For servers, we usually want to have separate TLS connections for each direction. In your
"untypical" scenario the NAT traversal should be fixed on the client side and
then you could use 2 separate TLS connections. Am 26.10.2012 14:08, schrieb Olle E. Johansson:
That's bad. We need to check the domains in the certificate before
re-using it. If they showed NO client cert, we should open a new
one. If they showed a client, we should verify. 25 okt 2012 kl. 19:05 skrev Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
> Kamailio uses the next hop target (probably the URI in the Path
> header) and searches for open TCP connections to this target. I
> guess the Path header contains the private IP address of the
> outbound proxy, thus it does not match the open TCP connection.
> If there is not outboundproxy, the solution is simple: as
> always use fix_nated_register() on REGISTER. Then, after
> lookup() the proxy will search for a TCP connection to the
> "received" IP:port and find and uses the existing connection.
Thinking about TLS - how do we match there?
AFAIK there is no difference to TLS. If there is a TLS connection
whose remote address matches the next hop, it will be used. Will the on-send route give me the possibility or
is it triggered
before kamailio selects a tcp connection? I'm a bit unclear of the
exact situation where the on-send route is called.
[on-send] is just before the message is sent. AFAIK it is executed before the message is
handled over to the transport layer - thus I think TLS paramters of the new connection are
not available.
Generally, domain verification against the certificate name is broken. For example if you
have to reopen a TLS connection for an in-dialog request, there is no proper URI (RURI,
next hop Route URI) to compare against the certificate.
no, which is why we
don't want IP addresses in the record-route headers for TLS.
/O
regards
Klaus
>
> /O
>