Hello Bogdan, An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb: >opensipsl...@encambio.com wrote: >>> the t_relay() function does server location discovery via DNS (for >>> domain voip.host.tld ). >>> >>> Based on NAPTR and SRV records, a TLS destination is chosen (this >>> selection also depends on the RURI - like if a specific SIP schema >>> is required, etc). >>> >>> So, your problem is why TLS was chosen or why TLS write failed ? >>> >> Your explanation sounds reasonable. The problem is that TLS writes >> and sometimes even reads are failing. I wrote about the NAPTR and >> SRV records, because I suspected that OpenSIPS was sending TCP >> (unencrypted) commands to a TLS connection or vise versa. >> >I doubt it - you can check via tcpdump to see if traffic in >encrypted or not. > A tcpdump is running right now, but I think you're right that there is no mismatch. Maybe the dump will show something else.
>> You mentioned in another email that this could be NAT related and >> I agree. It seems that you don't think there is some mismatch >> between TCP and TLS, maybe involving the NAPTR and SRV records. >> >That is correct. > Okay then I'll forget about NAPTR and SRV and focus on debugging NAT instead, thanks. >>>> The same config worked well with OpenSER 1.3.X. Only when migrating >>>> to 1.6.0 do we see these errors. What could have changed? >>>> >> But this is maybe a clue. It would seem that something in TLS >> writing has changed between these two versions, maybe fundementally? >> >1.3 was doing infinite loop (for write and read), leading sometime to >blocking. > That was a painful part of 1.3, so good that the counter is there now. I guess you're saying that the same TLS problems existed in 1.3 as well, but they were masked by retries (maybe thousands.) Regards, Brian _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users