29 okt 2012 kl. 10:52 skrev Klaus Darilion <[email protected]>:
> > > On 26.10.2012 22:03, Olle E. Johansson wrote: >> >> 26 okt 2012 kl. 21:08 skrev Klaus Darilion >> <[email protected]>: >> >>> Am 26.10.2012 14:08, schrieb Olle E. Johansson: >>>> 25 okt 2012 kl. 19:05 skrev Klaus Darilion >>>> <[email protected]>: >>>> >>>>> 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. >> >> 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. > > 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. Will that happen with Kamailio today? Won't the TCP matching make us reuse the existing connection? > >> 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. Agree. Just wanted to check. > > 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 >> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
