Thank you, Ovidiu.
I Just posted my logs on github.
Regards,
Jehanzaib
On Fri, May 20, 2022 at 3:02 AM Ovidiu Sas <[email protected]
<mailto:[email protected]>> wrote:
Set the log_level parameter to 4 and restart opensips. Once the
error occurs, collect all the logs from the start (from syslog)
and send them to Razvan.
There’s bug tracking this issue:
https://github.com/OpenSIPS/opensips/issues/2724
<https://github.com/OpenSIPS/opensips/issues/2724>
For compiling tls_wolfssl, try from a clean clone.
-ovidiu
On Thu, May 19, 2022 at 08:08 Jehanzaib Younis
<[email protected] <mailto:[email protected]>> wrote:
Thanks Ovidiu,
I just checked the source code, the same bug is also present
in the opensips-3.2.6 branch. I have another issue with 3.2.6.
I am not able to compile tls_wolfssl. No issue with 3.3 though.
Now I need to check what is causing this.
I am getting the following error:
make[1]: Entering directory
`/usr/src/opensips-3.2/modules/tls_wolfssl'
configure: WARNING: unrecognized options: --disable-shared,
--enable-static
checking whether make supports nested variables... (cached) yes
./configure: line 5259: syntax error near unexpected token `2.4.2'
./configure: line 5259: `LT_PREREQ(2.4.2)'
make[1]: *** [lib/lib/libwolfssl.a] Error 2
Regards,
Jehanzaib
On Thu, May 19, 2022 at 1:35 AM Ovidiu Sas
<[email protected] <mailto:[email protected]>> wrote:
Please upgrade to the latest version and see if the error
persists. If yes, please run the server in debug mode and
save the logs so this issue can be investigated properly.
Thanks,
Ovidiu
On Wed, May 18, 2022 at 09:02 Jehanzaib Younis
<[email protected]
<mailto:[email protected]>> wrote:
Thank you Bogdan,
That helped a lot. As you mentioned I need to start
only with server_domain or client_domain.
Now I changed my config a bit as shown below:
#### (WebRTC) Client
modparam("tls_mgm", "server_domain", "sip.mywebphone.xx")
modparam("tls_mgm", "certificate",
"[sip.mywebphone.xx]/etc/letsencrypt/live/sip.mywebphone.xx/cert.pem")
modparam("tls_mgm", "private_key",
"[sip.mywebphone.xx]/etc/letsencrypt/live/sip.mywebphone.xx/privkey.pem")
modparam("tls_mgm", "ca_list",
"[sip.mywebphone.xx]/etc/letsencrypt/live/sip.mywebphone.xx/fullchain.pem")
modparam("tls_mgm", "ca_dir",
"[sip.mywebphone.xx]/etc/letsencrypt/live/sip.mywebphone.xx")
modparam("tls_mgm", "tls_method",
"[sip.mywebphone.xx]SSLv23")
modparam("tls_mgm", "verify_cert", "[sip.mywebphone.xx]1")
modparam("tls_mgm", "require_cert",
"[sip.mywebphone.xx]1")
### This is for MS-Teams direct route
modparam("tls_mgm", "client_domain",
"dom1.formsteams.com <http://dom1.formsteams.com/>")
modparam("tls_mgm", "certificate",
"[dom1.formsteams.com
<http://dom1.formsteams.com/>]/etc/letsencrypt/live/dom1.formsteams.com/cert.pem
<http://dom1.formsteams.com/cert.pem>")
modparam("tls_mgm", "private_key",
"[dom1.formsteams.com
<http://dom1.formsteams.com/>]/etc/letsencrypt/live/dom1.formsteams.com/privkey.pem
<http://dom1.formsteams.com/privkey.pem>")
modparam("tls_mgm", "ca_list", "[dom1.formsteams.com
<http://dom1.formsteams.com/>]/etc/letsencrypt/live/dom1.formsteams.com/fullchain.pem
<http://dom1.formsteams.com/fullchain.pem>")
modparam("tls_mgm", "ca_dir", "[dom1.formsteams.com
<http://dom1.formsteams.com/>]/etc/letsencrypt/live/dom1.formsteams.com
<http://dom1.formsteams.com/>")
modparam("tls_mgm", "tls_method",
"[dom1.formsteams.com
<http://dom1.formsteams.com/>]SSLv23")
modparam("tls_mgm", "verify_cert",
"[dom1.formsteams.com <http://dom1.formsteams.com/>]1")
modparam("tls_mgm", "require_cert",
"[dom1.formsteams.com <http://dom1.formsteams.com/>]1")
modparam("tls_mgm", "client_sip_domain_avp",
"tls_sip_dom")
Looks like the initial handshake is fine when my
server sends OPTIONS to MSTeams. There is a bug in the
code according to the logs as shown below:
opensips[10659]: CRITICAL:core:io_watch_add: #012>>>
used fd map fd=142 is not present in fd_array
(fd=142,type=19,flags=80000003,data=0x7f825805ceb8)#012#012It
seems you have hit a programming bug.#012Please help
us make OpenSIPS better by reporting it at
https://github.com/OpenSIPS/opensips/issues
<https://github.com/OpenSIPS/opensips/issues>
opensips[10659]: CRITICAL:core:io_watch_add:
[TCP_main] check failed after successful fd add
(fd=141,type=19,data=0x7f825804fd98,flags=1) already=0
opensips[23993]: NOTICE:tls_wolfssl:verify_callback:
depth = 1, verify success
opensips[23993]: NOTICE:tls_wolfssl:verify_callback:
depth = 0, verify success
opensips[23993]:
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS
connection to 52.114.16.74:5061
<http://52.114.16.74:5061> established
opensips[23993]: NOTICE:tls_wolfssl:verify_callback:
depth = 1, verify success
opensips[23993]: NOTICE:tls_wolfssl:verify_callback:
depth = 0, verify success
opensips[23995]:
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS
connection to 52.114.76.76:5061
<http://52.114.76.76:5061> established
Regards,
Jehanzaib
On Wed, May 18, 2022 at 6:15 PM Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi Jehanzaib,
The sequence for the MST TLS domains is wrong.
For each TLS domain block, you need to start only
with a server_domain or client_domain - of course,
different names. And for each domain you need you
set the matching conditions. See
https://opensips.org/html/docs/modules/3.2.x/tls_mgm.html#domains-param
<https://opensips.org/html/docs/modules/3.2.x/tls_mgm.html#domains-param>
Basically something like:
modparam("tls_mgm", "server_domain",
"formsteams_server")
modparam("tls_mgm", "match_ip_address",
"[formsteams_server]....")
modparam("tls_mgm", "match_sip_domain",
"[formsteams_server]....")
modparam("tls_mgm", "certificate",
"[formsteams_server].....)
....
modparam("tls_mgm", "client_domain",
"formsteams_client")
modparam("tls_mgm", "match_ip_address",
"[formsteams_client]....")
modparam("tls_mgm", "match_sip_domain",
"[formsteams_client]....")
modparam("tls_mgm", "certificate",
"[formsteams_client].....)
....
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
<https://www.opensips-solutions.com>
OpenSIPS eBootcamp 23rd May - 3rd June 2022
https://opensips.org/training/OpenSIPS_eBootcamp_2022/
<https://opensips.org/training/OpenSIPS_eBootcamp_2022/>
On 5/18/22 2:38 AM, Jehanzaib Younis wrote:
Hi Bogdan,
That's the problem, when I try to add the
client_domain I get an error. Actually, I have a
working config for webrtc but now I am adding a
new domain for MS teams direct route. In fact,
any other domain gives an error. If I disable MS
Teams domain, the opensips do not give an
error message and my webrtc client can connect
without any issue.
loadmodule "tls_mgm.so"
modparam("tls_mgm", "tls_library", "wolfssl")
#### (WebRTC) Client
modparam("tls_mgm", "server_domain",
"sip.mywebphone.xx")
modparam("tls_mgm", "certificate",
"[sip.mywebphone.xx]/etc/letsencrypt/live/sip.mywebphone.xx/cert.pem")
modparam("tls_mgm", "private_key",
"[sip.mywebphone.xx]/etc/letsencrypt/live/sip.mywebphone.xx/privkey.pem")
modparam("tls_mgm", "ca_list",
"[sip.mywebphone.xx]/etc/letsencrypt/live/sip.mywebphone.xx/fullchain.pem")
modparam("tls_mgm", "ca_dir",
"[sip.mywebphone.xx]/etc/letsencrypt/live/sip.mywebphone.xx")
modparam("tls_mgm", "tls_method",
"[sip.mywebphone.xx]SSLv23")
modparam("tls_mgm", "verify_cert",
"[sip.mywebphone.xx]1")
modparam("tls_mgm", "require_cert",
"[sip.mywebphone.xx]1")
### This is for MS-Teams direct route
modparam("tls_mgm", "server_domain",
"dom1.formsteams.com <http://dom1.formsteams.com>")
modparam("tls_mgm", "client_domain",
"dom1.formsteams.com <http://dom1.formsteams.com>")
modparam("tls_mgm", "certificate",
"[dom1.formsteams.com
<http://dom1.formsteams.com>]/etc/letsencrypt/live/dom1.formsteams.com/cert.pem
<http://dom1.formsteams.com/cert.pem>")
modparam("tls_mgm", "private_key",
"[dom1.formsteams.com
<http://dom1.formsteams.com>]/etc/letsencrypt/live/dom1.formsteams.com/privkey.pem
<http://dom1.formsteams.com/privkey.pem>")
modparam("tls_mgm", "ca_list",
"[dom1.formsteams.com
<http://dom1.formsteams.com>]/etc/letsencrypt/live/dom1.formsteams.com/fullchain.pem
<http://dom1.formsteams.com/fullchain.pem>")
modparam("tls_mgm", "ca_dir",
"[dom1.formsteams.com
<http://dom1.formsteams.com>]/etc/letsencrypt/live/dom1.formsteams.com
<http://dom1.formsteams.com>")
modparam("tls_mgm", "tls_method",
"[dom1.formsteams.com
<http://dom1.formsteams.com>]SSLv23")
modparam("tls_mgm", "verify_cert",
"[dom1.formsteams.com
<http://dom1.formsteams.com>]1")
modparam("tls_mgm", "require_cert",
"[dom1.formsteams.com
<http://dom1.formsteams.com>]1")
modparam("tls_mgm", "client_sip_domain_avp",
"tls_sip_dom")
When i enable the MS-Teams direct route domain i
get the below error:
no certificate for tls domain '
dom1.formsteams.com
<http://dom1.formsteams.com> ' defined
Regards,
Jehanzaib
On Wed, May 18, 2022 at 3:04 AM Bogdan-Andrei
Iancu <[email protected]
<mailto:[email protected]>> wrote:
Hi Jehanzaib,
What are the TLS client domains you have
defined in your tls_mgm module ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
<https://www.opensips-solutions.com>
OpenSIPS eBootcamp 23rd May - 3rd June 2022
https://opensips.org/training/OpenSIPS_eBootcamp_2022/
<https://opensips.org/training/OpenSIPS_eBootcamp_2022/>
On 5/17/22 4:32 PM, Jehanzaib Younis wrote:
Hi,
I am having trouble to send/receive OPTIONS
to ms teams.
Using the dispatcher module. The socket is
defined as tls:*mysbcip*:5061
Looks like when my opensips (3.2.x) tries to
send OPTIONS. it is giving me the following
error
*
*
ERROR:proto_tls:proto_tls_conn_init: no TLS
client domain found
ERROR:core:tcp_conn_create: failed to do
proto 3 specific init for conn 0x7f00ef2a85a0
ERROR:core:tcp_async_connect:
tcp_conn_create failed
ERROR:proto_tls:proto_tls_send: async TCP
connect failed
ERROR:tm:msg_send: send() to
52.114.76.76:5061 <http://52.114.76.76:5061>
for proto tls/3 failed
ERROR:tm:t_uac: attempt to send to
'sip:sip3.pstnhub.microsoft.com:5061;transport:tls'
failed
I am setting the Contact as
<sip:mytlsdomain:5061;transport=tls>
Looks like the client domain is used for
outgoing TLS connection but no idea which
domain i need to add here. The socket is my
opensips ip address.
Has anyone seen a similar kind of behaviour?
Thank you.
Regards,
Jehanzaib
_______________________________________________
Users mailing list
[email protected]
<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<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
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
--
VoIP Embedded, Inc.
http://www.voipembedded.com <http://www.voipembedded.com>
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<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
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
--
VoIP Embedded, Inc.
http://www.voipembedded.com <http://www.voipembedded.com>
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users