Hi Damien,
IMHO, in most of the cases, the subscription is generated by the party
interested to receive the notifications, so the contact in SUBSCRIBE
will match the source address of the SUBSCRIBE requests.
To be honest, I never came across a kind of third-party subscription
scenario.
Anyhow, your comment is fully correct, I do thank you for the reminder
on looking into the connection reusage cases.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 31.08.2015 12:29, Damien Sandras wrote:
Hi Bogdan,
I'm not sure about that (see our previous discussions about connection
reuse).
It will only reuse the active SUBSCRIBE TCP connection if the Contact
header of the SUBSCRIBE indicates the same IP/port than the one used
to create the outbound SUBSCRIBE TCP connection. That is rarely the case.
Or am I missing something ?
Le lundi 31 août 2015 à 12:17 +0300, Bogdan-Andrei Iancu a écrit :
Hi Bogdan,
If the conn with B is still alive (the one created by SUBSCRIBE
requests), it should be reused when OpenSIPS has to send the NOTIFY.
Have you enabled the tcp aliases ?
If still a problem, can you make a log (with debug 6) when the NOTIFY
is to be send + a listing from list_tcp_conns ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 28.08.2015 20:53, Bogdan Chifor wrote:
Hello,
I have a question regarding the following scenario:
1. I have two devices connected to the server via two-way TLS(TCP).
1.1 Device A is behind a NAT
1.2 Device B is directly connected to the server
2. Device B subscribes to the presence of device A.
3. Device A gets offline and the server generates a NOTIFY message
to be sent to device B.
4. The server does not find an existing tcp connection (from the
logs), even though the socket is visible if the "opensipsctl fifo
list_tcp_conns" or "netstat" commands are used.
5. Because the server does not find an existing connection it
initiates one (TLS). After that the proto tls module logs the
following error: "NOTICE:proto_tls:verify_callback: verify
error:num=26:unsupported certificate purpose".
6. This error is normal because device B does not have a certificate
with server authentication extended key usage, it has only the
client authentication extended key usage (as normal).
What is the reason behind the start of the new connection and how
should I handle this issue?
This is my proto_tls config:
*modparam("proto_tls", "verify_cert", "1")*
*modparam("proto_tls", "require_cert", "1")*
*modparam("proto_tls", "tls_method", "TLSv1")*
*modparam("proto_tls", "certificate", "...")*
*modparam("proto_tls", "private_key", "...")*
*modparam("proto_tls", "ca_list", "...")*
*modparam("proto_tls", "ca_dir", "...")*
Any help is appreciated.
Best regards,
Bogdan.
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Damien SANDRAS
*Ekiga Project*
http://www.ekiga.org
_______________________________________________
Users mailing list
[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
