Hello Bogdan, An mer., janv 20, 2010, Bogdan-Andrei Iancu schrieb: >opensipsl...@encambio.com wrote: >> Here's a record I see when I run 'opensipsctl ul show': >> >> AOR:: mylogin-osips >> Contact:: >> sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm Q=1 >> Expires:: 560 >> Callid:: 2b21cdfae784-av13rj1txbsq >> Cseq:: 2 >> User-agent:: Bigphone123 >> Received:: sip:85.182.68.45:2240;transport=TLS >> State:: CS_SYNC >> Flags:: 0 >> Cflag:: 64 >> Socket:: tls:80.200.123.45:5061 >> Methods:: 7999 >> >> OpenSIPS is trying to reach the private IP number above from time >> to time, and I see this in the logs: >> >> Jan 19 17:57:20 name.host.tld <error> opensips[23432]: ERROR:tm:t_uac: >> attempt to send to >> 'sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm' failed >> >> Thanks for any advice on correcting the failed private IP attempts. >> >the problem is not the private IP in the contact, as opensips properly >saved the source IP (of the REGISTER) too -> see the Received field. So >the Received field will be used over the Contact for sending the >requests to UAC. > Yes, that's what was confusing me, that the Received header was correct and the TCP connection still failed.
>Now, what probably goes wrong in your case is that when using TLS/TCP >(connection oriented protos), after the REGISTER, the connection is >dropped and opensips cannot open later a TCP connection behind a NAT >:(....By default opensips closes the inactive TCP connections. > >To make opensips to keep the connection (even with no traffic going on), >see the tcp_persistent_flag: > >http://www.opensips.org/html/docs/modules/devel/registrar.html#id228181 > Good guess, but sadly your're wrong. I'm well informed of manipulating the TCP connection using the tcp_persistent_flag. It just wasn't where you expected it (and didn't appear in my email.) The tcp_persistent_flag is being set on all registrations just before save(). When I use tcpdump to see which address OpenSIPS is trying to connect to before reporting the failure above, I see that it really is trying to connect to 192.168.0.31 (over the Internet.) If I write fix_contact() just before save() then this behaviour and the failure goes away. It would seem that a lookup("location") does not always use the AOR's Received header, or what do you think could be the problem? It doesn't seem right changing the AOR's contact string to hack this problem away. Greetings, Brian _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
