Hi,
So the actual content of the message is not attached to the MSG? Could
you send me (maybe off list) the opensips logs (level 4) for a m_dump() ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS eBootcamp 2021
https://opensips.org/training/OpenSIPS_eBootcamp_2021/
On 10/15/21 11:02 AM, jacky z wrote:
Hi Bogdan-Andrei,
Did you also noticed the msilo module still can't send the dumped
message, but send "[Offline message - Thu Jan 1 00:00:00 1970" no
matter what the message is? or just the setting I used?
:+1:
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com <https://www.opensips-solutions.com>
OpenSIPS eBootcamp 2021
https://opensips.org/training/OpenSIPS_eBootcamp_2021/
<https://opensips.org/training/OpenSIPS_eBootcamp_2021/>
On 10/14/21 5:03 AM, jacky z wrote:
Hi Bogdan-Andrei,
Finally made it send offline message by setting
modparam("msilo", "outbound_proxy",
"sip:name.domain.com:5061;transport=tls")
modparam("tls_mgm", "match_sip_domain", "[dom]*")
It seems the port number needs to be included and the
match_sip_domain needs to *. If the domain name is included, the
error happens. Hope this info is helpful for others who may be
interested.
However, it still can't send the dumped message, but send
"[Offline message - Thu Jan 1 08:00:00 1970" no matter what the
message is. It seems the message was truncated. Based on the
source code of the msilo module, the message should be something
like "[Offline message - Thu Jan 1 08:00:00 1970] message here".
In the log, I can see the correct message was read out from the
silo table. Here is the log that shows the correct offline
message that should be sent:
DBG:db_mysql:db_mysql_str2val: converting BLOB
[{"type":"1","cont":"the right message"}]
Thanks!
Hi Jacky,
The m_dump() sends the MESSAGE to the AOR of the user, so,
ideally, you should do take care of the "lookup(location)" in
order to the get it properly routed.
For the TLS part, do you use it between the end-point and
opensips? if so, I guess the MESSAGE sent by m_dump() and
looping back to opensips (for doing the lookup(location)) is
via UDP ?
I'm asking as from the TLS perspective the most important
think to know is where (in the routing logic) the TLS
connection gets used/opened, as you need to be sure and
correlate the destination IP (at the moment) with the
IPs/mask you have in the TLS client domain.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
<https://www.opensips-solutions.com>
OpenSIPS eBootcamp 2021
https://opensips.org/training/OpenSIPS_eBootcamp_2021/
<https://opensips.org/training/OpenSIPS_eBootcamp_2021/>
On 9/28/21 3:03 AM, jacky z wrote:
Hi Team,
I want to use MSILO to forward offline messages. I use TLS
connections and have set up both server domain and client
domains. If we don't use outbound_proxy, the logs show no
error, but the message just was not sent. I searched online
and it was said that the outbound proxy needs to be used.
However, if we use outbound_proxy, there will be errors- no
TLS client domain found. Actually, I have set up the client
domain. It seems the MSILO module can't recognize the client
domain. I have checked the messages were all in the database
table silo. Have you ever encountered such issues? Any clue
to debug? Thanks!
Here are the scripts and logs
When m_dump() is called in "REGISTER":
|if (m_dump()) { xlog("MSILO: offline messages dumped - if
they were"); }else{ xlog("MSILO: no offline messages
dumped"); }; |
It can dump the message from the database but can't send the
message. Here is the log:
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_msg: method:
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_msg: uri: sip:[email protected]:5061;transport=tls
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_msg: version: <SIP/2.0>
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_headers: flags=ffffffffffffffff
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_via_param: found param type 232, =
<z9hG4bKe0c6.787dad54.0>; state=16
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_via: end of header reached, state=5
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_headers: via found, flags=ffffffffffffffff
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_headers: this is the first via
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_to_param: transport=tls
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:_parse_to: end of header reached, state=29
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:_parse_to: display={}, ruri={sip:[email protected]
<mailto:[email protected]>:5061}
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:get_hdr_field: [50]; uri=[sip:[email protected]
<mailto:[email protected]>:5061]
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:get_hdr_field: to body [sip:[email protected]
<mailto:[email protected]>:5061]
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:get_hdr_field: cseq : <10>
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:get_hdr_field: content_length=78
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:get_hdr_field: found end of header
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_headers: flags=ffffffffffffffff
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:parse_headers: flags=78
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:proto_tls:proto_tls_send: no open tcp connection found,
opening new one
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:probe_max_sock_buff: using snd buffer of 416 kb
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:init_sock_keepalive: TCP keepalive enabled on
socket 119
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:print_ip: tcpconn_new: new tcp connection to:
142.107.16.203 <http://142.107.16.203:5061/>
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:tcpconn_new: on port 5061, proto 3
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:proto_tls:tls_conn_init: Creating a whole new ssl connection
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
ERROR:proto_tls:tls_conn_init: no TLS client domain found
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
ERROR:core:tcp_conn_new: failed to do proto 3 specific init
for conn 0x7f0559e116b8
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
DBG:core:tcpconn_destroy: destroying connection
0x7f0559e116b8, flags 0018
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
ERROR:proto_tls:tls_sync_connect: tcp_conn_create failed,
closing the socket
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
ERROR:proto_tls:proto_tls_send: connect failed
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
ERROR™️msg_send: send() to 142.107.16.203:5061
<http://142.107.16.203:5061/> for proto tls/3 failed
Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
ERROR™️t_uac: attempt to send to 'sip:[email protected]
<mailto:[email protected]>:5061;transport=tls' failed
_______________________________________________
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
