Hi Yes I did that, and also with EXTRA_DEBUG too - I should be able to grab the logs from the time it happened.
Is there any particular item you want me to look for? On 23 February 2015 at 09:45, Bogdan-Andrei Iancu <[email protected]> wrote: > Hi Pete, > > Do you have any chance to run in debug mode to get some extra info ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 23.02.2015 10:49, Pete Kelly wrote: > > Hi Bogdan > > As I said in my original post, I tried that already with no success. > > On 12 February 2015 at 19:11, Bogdan-Andrei Iancu <[email protected]> > wrote: > >> Hi Pete, >> >> Try setting the tcp_accept_aliases global param to 1: >> tcp_accept_aliases = 1 >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 12.02.2015 11:24, Pete Kelly wrote: >> >> Bogdan >> >> In fact the TCP connection stays open (I checked with netstat on port >> 28733 being open on the remote host). >> >> I think the problem is opensips is opening (or is supposed to open) >> 5060 on the remote and this is failing? I think it may be looking for an >> already existing connection to 5060? >> >> Pete >> >> On 11 February 2015 at 20:11, Bogdan-Andrei Iancu <[email protected]> >> wrote: >> >>> Hi Pete, >>> >>> If the TCP connection (the one used to received the SUBSCRIBE from end >>> user) went down, when sending an in-dialog NOTIFY, OpenSIPS will refuse to >>> open a new TCP connection (the policy is to accept connection, not to open >>> connections towards end-users). >>> >>> Can you check if this is your case ? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>> >>> On 11.02.2015 12:50, Pete Kelly wrote: >>> >>> I have been experimenting recently with Presence over TCP and noticed >>> sometimes OpenSIPS fails to send a NOTIFY for a recent SUBSCRIBE, with a >>> tcp_send error in the logs. >>> >>> I did some research and found an old issue which seems to be similar >>> to this as the inbound SUBSCRIBE TCP connection is on a high port, yet the >>> NOTIFY is to go to port 5060. >>> >>> http://lists.opensips.org/pipermail/users/2013-May/025922.html >>> >>> The fix here is to set tcp_accept_aliases =1 >>> >>> I tried this fix and it did not resolve the issue. Looking in the >>> source code it seems OpenSIPS may be trying to reuse an old/existing TCP >>> connection and is failing to find one - it does seem to be slightly >>> intermittent too. Sometimes (very rarely) it will work, and it seems to be >>> related to how many other TCP connections are open at the moment but I have >>> found it very very difficult to pin down. In the end I got round it by >>> looping the TCP SUBSCRIBE back to UDP and the OpenSIPS then produces a >>> NOTIFY/UDP no problem. This solution is a bodge and I would be interested >>> to know if the failure to tcp_send is a bug or something I can detect and >>> handle in the config somehow? >>> >>> Using OpenSIPS 1.11 latest, in EXTRA_DEBUG mode this is the error that >>> is produced: >>> >>> [19361]: ERROR:tm:msg_send: tcp_send failed >>> [19361]: ERROR:tm:t_uac: attempt to send to >>> 'sip:111.111.8.146:5060;transport=tcp;lr' >>> failed >>> >>> This is the inbound SUBSCRIBE and 200OK... I am simply dealing with >>> this by calling handle_subscribe('1'); >>> >>> T 2015/02/10 12:52:09.324134 111.111.8.146:28733 -> 192.168.0.113:5060 >>> [AP] >>> SUBSCRIBE sip:[email protected] SIP/2.0. >>> Via: SIP/2.0/TCP 111.111.8.146:5060 >>> ;egress-zone=DNS;branch=z9hG4bK5c628151ab895c5f2f45ed8bdafeda0d24504147.1569b0b8efc74f7daf3767cc97d0b38e;proxy-call-id=345dee99-7aca-44b4-bf5f-fb1f2e57774a;rport. >>> Via: SIP/2.0/TLS 10.15.20.113:54999 >>> ;branch=z9hG4bKfd5e7b1424014fc8de23205f0de3873e.1;received=188.39.51.2;rport=54999;ingress-zone=DefaultSubZone. >>> Call-ID: [email protected]. >>> CSeq: 303 SUBSCRIBE. >>> Contact: <sip:[email protected] >>> ;gr=urn:uuid:683f87a0-e026-5f0a-b86b-58139361c7a4>. >>> From: <sip:[email protected]>;tag=359dbb1cb104d434. >>> To: <sip:[email protected]>. >>> Max-Forwards: 15. >>> Record-Route: <sip:111.111.8.146:5060;transport=tcp;lr>. >>> Record-Route: <sip:111.111.8.146:5061;transport=tls;lr>. >>> Record-Route: <sip:188.39.51.2:54999 >>> ;transport=tls;apparent=remove;ds;lr;proxy-call-id=345dee99-7aca-44b4-bf5f-fb1f2e57774a>. >>> User-Agent: Test. >>> Expires: 3600. >>> Event: presence. >>> Accept: application/pidf+xml. >>> P-Asserted-Identity: <sip:[email protected]>. >>> X-TAATag: 6ed63f01-3191-4a1f-b2a2-4121fb834f07. >>> Content-Length: 0. >>> . >>> >>> >>> T 2015/02/10 12:52:09.326218 192.168.0.113:5060 -> 111.111.8.146:28733 >>> [AP] >>> SIP/2.0 200 OK. >>> Via: SIP/2.0/TCP 111.111.8.146:5060 >>> ;received=111.111.8.146;egress-zone=DNS;branch=z9hG4bK5c628151ab895c5f2f45ed8bdafeda0d24504147.1569b0b8efc74f7daf3767cc97d0b38e;proxy-call-id=345dee99-7aca-44b4-bf5f-fb1f2e57774a;rport=28733. >>> Via: SIP/2.0/TLS 10.15.20.113:54999 >>> ;branch=z9hG4bKfd5e7b1424014fc8de23205f0de3873e.1;received=188.39.51.2;rport=54999;ingress-zone=DefaultSubZone. >>> Call-ID: [email protected]. >>> CSeq: 303 SUBSCRIBE. >>> From: <sip:[email protected]>;tag=359dbb1cb104d434. >>> To: <sip:[email protected] >>> >;tag=e3eb1f19b04f8e78afd28f643f416b5f-9be8. >>> Record-Route: <sip:111.111.8.146:5060;transport=tcp;lr>. >>> Record-Route: <sip:111.111.8.146:5061;transport=tls;lr>. >>> Record-Route: <sip:188.39.51.2:54999 >>> ;transport=tls;apparent=remove;ds;lr;proxy-call-id=345dee99-7aca-44b4-bf5f-fb1f2e57774a>. >>> Expires: 3600. >>> Contact: <sip:[email protected]:5060;transport=tcp> >>> <sip:[email protected]:5060;transport=tcp>. >>> Server: Test. >>> Content-Length: 0. >>> >>> >>> _______________________________________________ >>> Users mailing >>> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> >> > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
