[OpenSIPS-Users] config 477 for offline message

[jacky z]

Hi Team,

I am working on msilo module for offline message processing. When a message
receiver just closed the user agent but the server hasn't updated the
"location", the server will try to send the message several times through
TCP/TLS and failed with "477". How can we capture this "477" and m_store
the offline message? It seems the sample scripts don't handle this
scenario. I also tried the following scripts in the route[relay] and the
scripts were not executed based on the log. Appreciate your help! Thanks!

if (!t_relay(0x02) ) {

if (is_method("MESSAGE")) {

if (m_store("$ou")) {
log("MSILO: offline message stored\n");
send_reply(202, "Accepted");
}else{
log("MSILO: offline message NOT stored\n");
send_reply(503, "Service Unavailable");
}
exit;

}
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MSILO can't send message

[jacky z]

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
> 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:10...@xxx.com:5061;transport=tls
> Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]: DBG:core:parse_msg:
> version: 
> Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
> DBG:core:parse_headers: flags=
> Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
> DBG:core:parse_via_param: found param type 232, = ;
> 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=
> 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:10...@xxx.com:5061}
> Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
> DBG:core:get_hdr_field: [50]; uri=[sip:10...@xxx.com:5061]
> Sep 18 17:29:55 sipserver /usr/sbin/opensips[9794]:
> DBG:core:get_hdr_field: to body [sip:10...@xxx.com: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=
> 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 1