Hello,
Thank you very much! I've used your suggestion to accomplish some amazing things. However, I'm having an issue when calling the procedures over jsonrpc with http. I've noticed that the number of "200" responses gets incremented by 2, which is not the case when using the `*kamcmd*` tool. I suspect that this may be due to jsonrpc using *http/https*, which iscausing Kamailio to treat it as a "200" http responses code as "200" SIP codes. Could you advise on how to avoid this issue? Is there any further configuration that needs to be done?
Best regards.
Hello,
On 09.03.23 10:59, sadik.oualla.mohamed@gmail.com wrote:
Hello,
Thank you very much! I've used your suggestion to accomplish some amazing things. However, I'm having an issue when calling the procedures over jsonrpc with http. I've noticed that the number of "200" responses gets incremented by 2, which is not the case when using the `*kamcmd*` tool. I suspect that this may be due to jsonrpc using *http/https*, which iscausing Kamailio to treat it as a "200" http responses code as "200" SIP codes. Could you advise on how to avoid this issue? Is there any further configuration that needs to be done?
can you tell which exactly is the value that increases twice? Is it a core statistic? Or maybe you can give an example jsonrpcs response to identify the field.
Cheers, Daniel
Hello Daniel,
Thank you for your response. I can confirm that the value that gets increased twice is the "200" code response when calling the procedures over JSONRPC with HTTP, or maybe all HTTP responses code. The response that I get when calling the "sl.stats" procedure using the jsonrpc is:
{ "200" : 2, "202" : 0, "2xx" : 0, "300" : 0, "301" : 0, "302" : 0, "3xx" : 0, "400" : 0, "401" : 0, "403" : 0, "404" : 0, "407" : 0, "500" : 0, "5xx" : 0, "6xx" : 0, "xxx" : 0 }
I have compared this with the output of the "kamcmd sl.status" command and can confirm that the "200" value does not get incremented when using this tool. Based on my analysis, I suspect that this issue is caused by Kamailio treating the HTTP responses code as a "200" SIP response code.
I configured the "ctl" module with its "binrpc" paramater to test in wireshark how the transmition goes like this : " loadmodule "ctl" modparam("ctl", "binrpc", "unix:/run/kamailio/kamailio_ctl") modparam("ctl", "binrpc", "udp:*:1234") " So I created a socket client for the server 127.0.0.1:1234, and sent the message for example "sl.stats", I got a "bad request" response from kamailio, then I noticed in wireshark that the data sent from kamcmd and my script are different and encoded in different way... So my question is just how to avoid kamailio treating HTTP responses in a different way as SIP, because it may the problem not only for "200 ok" responses ...
Thank you very much! Best,
Hello,
xhttp is using internally the sl module for generating the http response, that's likely the cause of getting the sl stats increased.
This behaviour is there for very long time, but I guess nobody has noticed it before.
Probably the non-sip responses generated by sl should be skipped from statistics, it would require c code development, maybe a new inter-module api function with a parameter to skip updating stats.
Cheers, Daniel
On 09.03.23 12:34, sadik.oualla.mohamed@gmail.com wrote:
Hello Daniel,
Thank you for your response. I can confirm that the value that gets increased twice is the "200" code response when calling the procedures over JSONRPC with HTTP, or maybe all HTTP responses code. The response that I get when calling the "sl.stats" procedure using the jsonrpc is:
{ "200" : 2, "202" : 0, "2xx" : 0, "300" : 0, "301" : 0, "302" : 0, "3xx" : 0, "400" : 0, "401" : 0, "403" : 0, "404" : 0, "407" : 0, "500" : 0, "5xx" : 0, "6xx" : 0, "xxx" : 0 }
I have compared this with the output of the "kamcmd sl.status" command and can confirm that the "200" value does not get incremented when using this tool. Based on my analysis, I suspect that this issue is caused by Kamailio treating the HTTP responses code as a "200" SIP response code.
I configured the "ctl" module with its "binrpc" paramater to test in wireshark how the transmition goes like this : " loadmodule "ctl" modparam("ctl", "binrpc", "unix:/run/kamailio/kamailio_ctl") modparam("ctl", "binrpc", "udp:*:1234") " So I created a socket client for the server 127.0.0.1:1234, and sent the message for example "sl.stats", I got a "bad request" response from kamailio, then I noticed in wireshark that the data sent from kamcmd and my script are different and encoded in different way... So my question is just how to avoid kamailio treating HTTP responses in a different way as SIP, because it may the problem not only for "200 ok" responses ...
Thank you very much! Best, __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello Daniel,
Thank you for your response and explanation. I appreciate your help in identifying the cause of the issue. It's good to know that xhttp is using the sl module internally for generating http responses and that is why the sl stats are increased.
Skipping the non-sip responses generated by sl from statistics would be a good solution.
However, I was wondering if it would be possible to use the proper Kamailio RPC with a socket UDP script to send the data instead of using the jsonrpc with xhttp. Have you had any experience with this approach? Would it be a viable solution?
Thank you again for your help.
Best regards.
Hello,
using a "standard" protocol like http certainly has some advantages over a home-grown solution.
The ctl module supports a UDP socket (among others): https://kamailio.org/docs/modules/5.6.x/modules/ctl.html
This is for example used from the (old) kamcmd command with an unix domain socket. Maybe this can give you some ideas.
Cheers,
Henning
-----Original Message----- From: sadik.oualla.mohamed@gmail.com sadik.oualla.mohamed@gmail.com Sent: Donnerstag, 9. März 2023 14:00 To: sr-users@lists.kamailio.org Subject: [SR-Users] Re: Increment in number of "200" responses while calling procedures over jsonrpc with http
Hello Daniel,
Thank you for your response and explanation. I appreciate your help in identifying the cause of the issue. It's good to know that xhttp is using the sl module internally for generating http responses and that is why the sl stats are increased.
Skipping the non-sip responses generated by sl from statistics would be a good solution.
However, I was wondering if it would be possible to use the proper Kamailio RPC with a socket UDP script to send the data instead of using the jsonrpc with xhttp. Have you had any experience with this approach? Would it be a viable solution?
Thank you again for your help.
Best regards. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Dear Henning,
Thank you for your previous message and for pointing me to the "ctl" module documentation. I have successfully configured the module to support both TCP and UDP protocols using the following lines:
`modparam("ctl", "binrpc", unix:/run/kamailio/kamailio_ctl") modparam("ctl", "binrpc", "udp:*:8888") modparam("ctl", "binrpc", "tcp:*:3333")`
However, I am experiencing issues when attempting to send messages to the Kamailio server using a socket script. Specifically, when I send a message to the server using either TCP or UDP, I receive a malformed response containing "bad request" with some other symbols. I suspect that I need to enable some special encoding to allow the Kamailio server to properly understand the procedure being executed.
Could you please provide me with more information on how to properly encode the messages that are being sent to the Kamailio server via the socket script? Any guidance you can provide would be greatly appreciated.
Thank you for your time and assistance.
Best regards,
Hello,
maybe you can have a look at the "kamcmd" command sources (you can find them inside the kamailio source tree as well) for some examples. There is also the binrpc.h header file in the ctl module directory, as indicated from the module docs.
Cheers,
Henning
-----Original Message----- From: sadik.oualla.mohamed@gmail.com sadik.oualla.mohamed@gmail.com Sent: Freitag, 10. März 2023 11:15 To: sr-users@lists.kamailio.org Subject: [SR-Users] Re: Increment in number of "200" responses while calling procedures over jsonrpc with http
Dear Henning,
Thank you for your previous message and for pointing me to the "ctl" module documentation. I have successfully configured the module to support both TCP and UDP protocols using the following lines:
`modparam("ctl", "binrpc", unix:/run/kamailio/kamailio_ctl") modparam("ctl", "binrpc", "udp:*:8888") modparam("ctl", "binrpc", "tcp:*:3333")`
However, I am experiencing issues when attempting to send messages to the Kamailio server using a socket script. Specifically, when I send a message to the server using either TCP or UDP, I receive a malformed response containing "bad request" with some other symbols. I suspect that I need to enable some special encoding to allow the Kamailio server to properly understand the procedure being executed.
Could you please provide me with more information on how to properly encode the messages that are being sent to the Kamailio server via the socket script? Any guidance you can provide would be greatly appreciated.
Thank you for your time and assistance.
Best regards, __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
Thank you very much for you advice, I am looking on this library looks interesting and give me some new points to follow,
Crdly,