Re: [OpenSIPS-Users] We didn't manage to read a full request
On Wed, Oct 20, 2021 at 3:30 PM jacky z wrote: > We found most of the time, it follows a global (per process) buff and is > followed by a per connection buff and then the message is read. > > try to do a tcpdump on that interface/port, then wireshark the pcap, you will see what opensips see eg: tcpdump -i eth0 -w fail_req.pcap port 5080 -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] We didn't manage to read a full request
We found most of the time, it follows a global (per process) buff and is followed by a per connection buff and then the message is read. Oct 19 13:34:32 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tls_read_req: *Using the global ( per process ) buff * Oct 19 13:34:32 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tls_update_fd: New fd is 118 Oct 19 13:34:32 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tcp_handle_req: *We didn't manage to read a full request* Oct 19 13:34:32 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tls_read_req: tls_read_req end Oct 19 13:34:32 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tls_read_req: *Using the per connection buff* Oct 19 13:34:32 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tls_update_fd: New fd is 118 Oct 19 13:34:32 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:_tls_read: *683 bytes read* The one I mentioned in the previous email was not followed by a per connection buff and it seems the connection was dead. Oct 19 13:35:05 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tls_read_req: *Using the global ( per process ) buff * Oct 19 13:35:05 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tls_update_fd: New fd is 118 Oct 19 13:35:05 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tcp_handle_req: *We didn't manage to read a full request* Oct 19 13:35:05 sipserver /usr/sbin/opensips[18615]: DBG:proto_tls:tls_read_req: tls_read_req end Oct 19 13:35:07 sipserver /usr/sbin/opensips[18622]: DBG:tm:timer_routine: timer routine:2,tl=0x7f0fc18a3630 next=(nil), timeout=428446 Oct 19 13:35:07 sipserver /usr/sbin/opensips[18622]: DBG:tm:wait_handler: removing 0x7f0fc18a35b0 from table Oct 19 13:35:07 sipserver /usr/sbin/opensips[18622]: DBG:tm:delete_cell: delete transaction 0x7f0fc18a35b0 Oct 19 13:35:07 sipserver /usr/sbin/opensips[18622]: DBG:tm:wait_handler: done jacky z wrote: > Thanks! We found an end point sent an INVITE, but the server did not > receive. The time of this message in the opensips log matched the INVITE. > Not sure whether the INVITE message failed to be read for whatever reason. > Then we checked the server and found a lot of such messages. The server is > a still a test server and we don't expect there are a lot random connection > attempts. > > Giovanni Maruzzelli wrote: > >> On Wed, Oct 20, 2021 at 11:00 AM jacky z wrote: >> >>> >>> Recently checked the log and found a lot of items. >>> >>> DBG:proto_tls:tcp_handle_req: We didn't manage to read a full request >>> >>> Does this mean that there is an incoming message but the server can't >>> read it successfully? What can induce this problem? Thanks! >>> >> >> These are probably connection attempts that happen to be on the tcp port >> where opensips is listening. >> >> They are probably script kiddies sending http/https/ssh/whatever to >> random ports >> >> -giovanni >> -- >> Sincerely, >> >> Giovanni Maruzzelli >> OpenTelecom.IT >> cell: +39 347 266 56 18 >> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] We didn't manage to read a full request
Thanks! We found an end point sent an INVITE, but the server did not receive. The time of this message in the opensips log matched the INVITE. Not sure whether the INVITE message failed to be read for whatever reason. Then we checked the server and found a lot of such messages. The server is a still a test server and we don't expect there are a lot random connection attempts. Giovanni Maruzzelli wrote: > On Wed, Oct 20, 2021 at 11:00 AM jacky z wrote: > >> >> Recently checked the log and found a lot of items. >> >> DBG:proto_tls:tcp_handle_req: We didn't manage to read a full request >> >> Does this mean that there is an incoming message but the server can't >> read it successfully? What can induce this problem? Thanks! >> > > These are probably connection attempts that happen to be on the tcp port > where opensips is listening. > > They are probably script kiddies sending http/https/ssh/whatever to random > ports > > -giovanni > -- > Sincerely, > > Giovanni Maruzzelli > OpenTelecom.IT > cell: +39 347 266 56 18 > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] We didn't manage to read a full request
On Wed, Oct 20, 2021 at 11:00 AM jacky z wrote: > > Recently checked the log and found a lot of items. > > DBG:proto_tls:tcp_handle_req: We didn't manage to read a full request > > Does this mean that there is an incoming message but the server can't read > it successfully? What can induce this problem? Thanks! > These are probably connection attempts that happen to be on the tcp port where opensips is listening. They are probably script kiddies sending http/https/ssh/whatever to random ports -giovanni -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] config 477 for offline message
Hi Bogdan-Andrei,
Yes. 0x02 flag works. I knew this but struggled a lot to figure out where
to do the t_relay(0x02). It works now and no 477 sent. Thanks!
Regards,
Jacky
Hi,
>
> Using the 0x02 flag should do the trick . If you enable it, do you still
> see the TM sending the 477 reply automatically ?
>
> 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/14/21 5:17 AM, jacky z wrote:
>
> 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
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [RELEASE] OpenSIPS 3.1.6 and 3.2.3 minor releases
Hello! It is my pleasure to announce a new set of OpenSIPS minor releases: 3.1.6 and 3.2.3! These releases include the fixes of the past couple of months: roughly 40 bugfixes/improvements, touching critical modules such as tls_wolfssl, rtp_relay, dialog, rtpengine, b2b_logic, auth, mid-registrar and event_routing. Both releases are ready for production use, even more stable/accurate than before and backwards-compatible with the previous minor release. Since they contain the latest bug fixes, we strongly recommend you to upgrade your current instances. Thank you all for your reports, fixes, pull requests and all other contributions to this project! Full ChangeLogs: https://opensips.org/pub/opensips/3.1.6/ChangeLog https://opensips.org/pub/opensips/3.2.3/ChangeLog Download instructions: https://opensips.org/Downloads/Downloads Enjoy, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS eBootcamp 2021: www.opensips.org/training ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Call-API / 404 Dialog not found
Hi, i am using trunking scenario with Topology hiding + RTPEngine and
it is working fine.
Additionally i am trying to setup Call-API to work for outbound dialer app.
For now i am using only internal module "cmd/call-api-client/main.go
.." to originate call .The call is send to first ddi (call leg
"caller") , when answered the transfer to "callee" is not happening
because, as it is shown in logs ,dialog is not found . And next i got
BYE from Opensips.
Oct 20 10:12:03 Debian10opensips3 /usr/sbin/opensips[10910]:
DBG:dialog:get_dlg_by_callid: input
ci=(36)
Oct 20 10:12:03 Debian10opensips3 /usr/sbin/opensips[10910]:
DBG:mi_datagram:mi_datagram_callback: the response:
{"jsonrpc":"2.0","error":{"code":404,"message":"Dialog not
found"},"id":2} has been sent in 74 octets
I tried to play with dialog module parameter ,local_route etc but for
now no success
Call-Api is supposed to work for any 2 ddi number ,right?
If you have any idea how to setup properly Call-Api please advice.
Thanks
Regards
Vladan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] We didn't manage to read a full request
Hi Team, Recently checked the log and found a lot of items. DBG:proto_tls:tcp_handle_req: We didn't manage to read a full request Does this mean that there is an incoming message but the server can't read it successfully? What can induce this problem? Thanks! Regards, Jacky ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
