Hi Pete,
Try setting the tcp_accept_aliases global param to 1:
tcp_accept_aliases = 1
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://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]
<mailto:[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 Developer
http://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
<http://111.111.8.146:28733> -> 192.168.0.113:5060
<http://192.168.0.113:5060> [AP]
SUBSCRIBE sip:[email protected]
<mailto: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]
<mailto:[email protected]>.
CSeq: 303 SUBSCRIBE.
Contact: <sip:[email protected]
<mailto:sip%[email protected]>;gr=urn:uuid:683f87a0-e026-5f0a-b86b-58139361c7a4>.
From: <sip:[email protected]
<mailto:sip%[email protected]>>;tag=359dbb1cb104d434.
To: <sip:[email protected]
<mailto: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]
<mailto: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
<http://192.168.0.113:5060> -> 111.111.8.146:28733
<http://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]
<mailto:[email protected]>.
CSeq: 303 SUBSCRIBE.
From: <sip:[email protected]
<mailto:sip%[email protected]>>;tag=359dbb1cb104d434.
To: <sip:[email protected]
<mailto: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>
<mailto:sip:[email protected]:5060;transport=tcp>.
Server: Test.
Content-Length: 0.
_______________________________________________
Users mailing list
[email protected] <mailto:[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
