Re: [OpenSIPS-Users] Sometime opensips sends 477 reply for BYE packet in TLS
Hi, 477 is an intern error meaning some transport level err happened - like in your case, OpenSIPS did not find and was not able to open a new TLS connection back to softphone. Probably some times, depending on the call duration, the TLS conn is still up and the BYE is routed. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 16.02.2024 14:41, Vinayak Makwana via Users wrote: Hello all, I am facing an issue when opensips gets BYE from the freeswitch side. At that time, opensips sent 477 reply to the BYE request. Here's the call scenario : when we dial the call from softphone to opensips, it's TLS call flow, and from opensips to Freeswitch, it's UDP call flow. So when we disconnect a call from Softphone at that time, the call disconnects properly, but when we disconnect a call from FreeSwitch at that time, opensips sends 477 sending failed to Freeswitch. but sometimes OpenSIP sends 200 OK successfully to Freeswitch, and calls get disconnected also. *opensips logs at the time of 477 reply send:* ERROR:core:tcp_connect_blocking_timeout: connect timed out, 99171 us elapsed out of 10 us ERROR:core:tcp_sync_connect_fd: tcp_blocking_connect failed ERROR:proto_tls:proto_tls_send: connect failed ERROR:tm:msg_send: send() to a.b.c.d:53722 for proto tls/3 failed ERROR:tm:t_forward_nonack: sending request failed DBG:tm:t_relay_to: t_forward_nonack returned error DBG:sl:sl_reply_error: error text is Send failed (477/SL) Please suggest if anything needs to be configured on the opensips side. -- Regards, *Vinayak Makwana * *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems. ___ 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] opensips 3.4 push notification
Hi,
Could you share a pcap or trace so we can understand the routing you have ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 15.02.2024 22:24, r...@rvgeerligs.nl wrote:
Hi,
I kind of followed the article SIP Push Notification with OpenSIPS 3.1
LTS [RFC 8599 support][Part II] as I connot find anything related to
opensips 3.4.x.
When I disable (commenting by #) modparam("registrar", "pn_enable",
true), the call actually works.
When I enable modparam("registrar", "pn_enable", true) the call does
not come through.
It gets rerouted internally to external ip address after the
authentication, second INVITE with answer to nonce, and giving it a try.
Opensips keeps asking for Proxy Authentication required which was
allready accepted.
Anyone an idea?
Regards,
Ronald Geerligs
___
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] SIPMSGOPS changes
Search and you will find it: https://opensips.org/html/docs/modules/3.3.x/sipmsgops.html#func_get_updated_body_part In regards to rtpengine, afaik the function may get the SDP (and return it) via script vars too, not only from the actual msg. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 14.02.2024 21:10, Social Boh wrote: Hello list, after manipulating SDP annex, is there a function to apply the changes before to use rtpengine_manage? In debug mode I can see the module reorder the codec but after use rtpengine_amange the exit INVITE use the same original order. Thank's Regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPs generate PRACK
I agree here, the 183 must be relayed back to the original caller (which generate the received INVITE) and let it do the PRACK - this confirmation must be end-2-end in the dialog. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 12.02.2024 11:36, Ihor Olkhovskyi wrote: You should relay 183 to original source (ione that is sending INVITE) and got PRACK from there. That would be the most correct way of handling this Le lun. 12 févr. 2024 à 02:29, Social Boh a écrit : Maybe someone can help me. This is the scenario. OpenSIPs receive a INVITE and send it to a server that reply with a 302 message (always) Then OpenSIPs, in the failure route, take the user part present in the 302 contact header, change the destination IP and send with t_relay The destination reply with a 183 with Require: 100rel header so OpenSIPs have to reply with a PRACK. This is my problem. I don't know which is the best way to handle this (the PRACK) Thank you Regards --- I'm SoCIaL, MayBe El 9/02/2024 a las 6:46 a. m., Social Boh escribió: > Hello list, > > can OpenSIPs generate a PRACK message to reply a 180/183 message? > > Thank you > > Regards > > --- > I'm SoCIaL, MayBe > > > ___ > 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 -- Best regards, Ihor (Igor) ___ 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
[OpenSIPS-Users] Sometime opensips sends 477 reply for BYE packet in TLS
Hello all, I am facing an issue when opensips gets BYE from the freeswitch side. At that time, opensips sent 477 reply to the BYE request. Here's the call scenario : when we dial the call from softphone to opensips, it's TLS call flow, and from opensips to Freeswitch, it's UDP call flow. So when we disconnect a call from Softphone at that time, the call disconnects properly, but when we disconnect a call from FreeSwitch at that time, opensips sends 477 sending failed to Freeswitch. but sometimes OpenSIP sends 200 OK successfully to Freeswitch, and calls get disconnected also. *opensips logs at the time of 477 reply send:* ERROR:core:tcp_connect_blocking_timeout: connect timed out, 99171 us elapsed out of 10 us ERROR:core:tcp_sync_connect_fd: tcp_blocking_connect failed ERROR:proto_tls:proto_tls_send: connect failed ERROR:tm:msg_send: send() to a.b.c.d:53722 for proto tls/3 failed ERROR:tm:t_forward_nonack: sending request failed DBG:tm:t_relay_to: t_forward_nonack returned error DBG:sl:sl_reply_error: error text is Send failed (477/SL) Please suggest if anything needs to be configured on the opensips side. -- Regards, *Vinayak Makwana* -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
