[OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist at encambio.com]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipslist at encambio.com wrote:
>> An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>>> opensipslist at encambio.com wrote:
>>>>> One solution fixed both errors (assuming there really were two
>>>>> different erros) as you see below.
>>>>>         
>>>> Whoops I spoke too soon. It seems that patching MAX_SSL_RETRIES only
>>>> fixed the 'tls_blocking_write' error. Now I still have in the log:
>>>>
>>>>   <error> ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
>>>>   <error> ERROR:core:tcpconn_connect: tcp_blocking_connect failed
>>>>   <error> ERROR:core:tcp_send: connect failed
>>>>   <error> ERROR:tm:msg_send: tcp_send failed
>>>>   <error> ERROR:tm:t_forward_nonack: sending request failed
>>>>       
>>> I guess you are trying to connect to some destination which is not
>>> listening - check with tcpdump where opensips tries to open the TCP
>>> connection and see if there is a really app listening there.
>>>     
>> Seems reasonable, so I'll take your advise and start debugging with
>> tcpdump. My guess is that there is some NAT problem and/or faulty IP
>> number substitution in SDP (a config error basically.) The strange
>> thing is that the same config was being used with OpenSER 1.3.X and
>> these errors did not appear.
>>
>> I'll start tcpdump and report what I find.
>>   
>For sure it is after the lookup() and opensips tries to open a 
>connection somwhere behind a NAT (where a TLS phone is located).
>
That would seem right, but in my case I'm handling NAT correctly:

    if (client_nat_test("3")) {
        if (method=="SUBSCRIBE")
            nat_keepalive();
        if (!has_totag()) {
            if (method=="REGISTER") {
                if (proto==UDP)
                    nat_keepalive();
                else
                    setflag(7);  # tcp_persistent
                    #Try as well force_tcp_alias();  # reuse port
                $avp(s:regrcv) = $source_uri;
                fix_nated_register();  # add Received header
            }
            else if (method=="INVITE") {
                nat_keepalive();
                fix_nated_sdp("3");
            }
        }
    }

...which means that lookup is most likely reporting a valid TLS/TCP
connection which is both open and still in the NAT table of the IP
router. Have I missed something there?

Another idea is that SUBSCRIBEs or NOTIFYs are causing the TLS
errors. I don't know if 'nat_keepalive' works on TCP/TLS or if
OpenSIPS is able to reuse the TLS connection stored in usrloc for
non INVITE messages.

Regards,
Brian