Re: [sr-dev] xflag losing state on serial forking
Dear all Would you have any feedback about this query? thanks a lot! David Escartín El jue, 11 feb 2021 a las 23:56, David Escartin () escribió: > Hello > > seems with t_flush_xflags() after setxflag on failure_route, it makes it > work. However i don't know if that should be the expected behaviour, since > with regular transaction flags there is no need to use t_flush_flags() > > best regards > david > > El mié, 10 feb 2021 a las 16:08, David Escartin () > escribió: > >> Dear all >> >> i think i have noticed a wrong behaviour with xflags. When they are set >> in a failure_route and a t_relay is done after that to a destination, its >> state is lost in the next on_reply route. >> This doesn't happen with regular transaction flags, and it doesn't happen >> with xflags either when xflag is set inside an onreply_route. >> We have seen it on versions 5.3 and 5.4 >> >> Could you please confirm this? >> thanks a lot >> regards >> david escartin >> >> -- >> [image: Logo] >> >> David Escartín Almudévar >> VoIP/Switch Engineer >> descar...@sonoc.io >> >> *SONOC* >> C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España >> Tlf: +34 917019888 · www.sonoc.io >> > > > -- > [image: Logo] > > David Escartín Almudévar > VoIP/Switch Engineer > descar...@sonoc.io > > *SONOC* > C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España > Tlf: +34 917019888 · www.sonoc.io > -- [image: Logo] David Escartín Almudévar VoIP/Switch Engineer descar...@sonoc.io *SONOC* C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España Tlf: +34 917019888 · www.sonoc.io ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] issue using evapi module with evapi_relay
hello Daniel
related to this module, I had an issue this week on a different topic.
We have been testing this module with the application we made to write
events from kamailio to kafka, and it was working fine.
But the other day i tried to send messages to a damaged kafka cluster, so
the application got congested, and the socket between kamailio and the the
application had some issue.
I didn't see the buffer Send-Q increased in the socket from kamailio's
point of view, but i saw Recv-Q increased in the socket from application's
point of view
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name Timer
tcp22802 0 APP_IP:40068 KAMAILIO_IP:8448 ESTABLISHED
128595/evapi_kafka off (0.00/0/0)
and after a while of having timeouts trying to produce at kafka and having
the socket buffer congested, kamailio stopped to process any UDP message
Would you have any idea about the reason for this behaviour?
I would expect the evapi socket not to interfer with UDP receivers
thanks a lot and regards
david
El mar, 15 dic 2020 a las 15:05, David Escartin ()
escribió:
> Hello Daniel
>
> Thanks a lot for the feedback
> I tried the netstring option but since i had to reparse in the
> application, I finally didn't use it.
> But I will consider it since I will test the performance for heavy load
> during the next days.
>
> About the tcp_nodelay option, I remember I saw no frames with more than a
> message (Json object) relayed to evapi and sent out to the socket :$, but
> anycase, I removed that option and changed the application side.
>
> best regards
> david
>
> El vie, 11 dic 2020 a las 13:51, Daniel-Constantin Mierla (<
> mico...@gmail.com>) escribió:
>
>> Hello,
>>
>> tcp is a streaming protocol, it is the receiving application that has to
>> parse and split the stream content in logical messages from its point of
>> view. As you noticed, there can be socket options to enforce some sending
>> policy (wait or not wait for a specific amount of data to accumulate, not
>> to send too many small packets, but if it is too much in very short time,
>> it is no difference).
>>
>> As a side note, your patch below is setting the TCP_NODELAY to listen
>> socket, not to the socket associated with the client connection (returned
>> by accept()). I do not think is inherited by accept() from listen socket,
>> in such case practically your patch didn't make any difference in behaviour.
>>
>> The evapi module has the option (modparam) to serialize the packets in
>> netstring format, being easier to split the stream in messages and I would
>> recommend that mode for heavy traffic.
>>
>> At the end, we can introduce modparams for evapi to set TCP_NODELAY, it
>> can be useful to reduce delays when sending short data messages from time
>> to time, but it won't help in your case.
>>
>> Cheers,
>> Daniel
>> On 11.12.20 09:39, David Escartin wrote:
>>
>> Dear all
>>
>> seems the issue was not on the module or related to kamailio, but related
>> to the application we were using to read from tcp socket.
>> I saw that some messages sent with evapi_relay were encapsulated in the
>> same frame, and i even tried to force the TCP_NODELAY option on the evapi
>> socket by compiling the kamailio with this
>> --- a/src/modules/evapi/evapi_dispatch.c
>> +++ b/src/modules/evapi/evapi_dispatch.c
>> @@ -30,8 +30,8 @@
>> #include
>> #include
>> #include
>> -
>> #include
>> +#include
>>
>> #include "../../core/sr_module.h"
>> #include "../../core/dprint.h"
>> @@ -690,6 +691,15 @@ int evapi_run_dispatcher(char *laddr, int lport)
>> freeaddrinfo(ai_res);
>> return -1;
>> }
>> +
>> +if(setsockopt(evapi_srv_sock, IPPROTO_TCP, TCP_NODELAY,
>> + _true, sizeof(int)) < 0) {
>> + LM_INFO("cannot set TCP_NODELAY option on descriptor\n");
>> + close(evapi_srv_sock);
>> + freeaddrinfo(ai_res);
>> + return -1;
>> + }
>> +
>>
>> if (bind(evapi_srv_sock, ai_res->ai_addr, ai_res->ai_addrlen) <
>> 0) {
>> LM_ERR("cannot bind to local address and port [%s:%d]\n",
>> laddr, lport);
>>
>> and i saw that with this change we had always a frame for each message
>> published to evapi, but the issue was still there.
>> So no matter if this option was activated or not in Kamailio, I had to
>> tune the application (in erlang) to delimit th
Re: [sr-dev] xflag losing state on serial forking
Hello seems with t_flush_xflags() after setxflag on failure_route, it makes it work. However i don't know if that should be the expected behaviour, since with regular transaction flags there is no need to use t_flush_flags() best regards david El mié, 10 feb 2021 a las 16:08, David Escartin () escribió: > Dear all > > i think i have noticed a wrong behaviour with xflags. When they are set in > a failure_route and a t_relay is done after that to a destination, its > state is lost in the next on_reply route. > This doesn't happen with regular transaction flags, and it doesn't happen > with xflags either when xflag is set inside an onreply_route. > We have seen it on versions 5.3 and 5.4 > > Could you please confirm this? > thanks a lot > regards > david escartin > > -- > [image: Logo] > > David Escartín Almudévar > VoIP/Switch Engineer > descar...@sonoc.io > > *SONOC* > C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España > Tlf: +34 917019888 · www.sonoc.io > -- [image: Logo] David Escartín Almudévar VoIP/Switch Engineer descar...@sonoc.io *SONOC* C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España Tlf: +34 917019888 · www.sonoc.io ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] xflag losing state on serial forking
Dear all i think i have noticed a wrong behaviour with xflags. When they are set in a failure_route and a t_relay is done after that to a destination, its state is lost in the next on_reply route. This doesn't happen with regular transaction flags, and it doesn't happen with xflags either when xflag is set inside an onreply_route. We have seen it on versions 5.3 and 5.4 Could you please confirm this? thanks a lot regards david escartin -- [image: Logo] David Escartín Almudévar VoIP/Switch Engineer descar...@sonoc.io *SONOC* C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España Tlf: +34 917019888 · www.sonoc.io ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] rtpengine_allow_op usage doubt
sorry i edit the previous message
since version 4.4 we are using this parameter to 1 to allow that ongoing
calls process their messages through a particular rtpengine when disabling
it manually from database.
But we see that enabling it also makes all the messages select the
rtpengine and attempt to send its own op command **when an rtpengine is
disabled because the socket or host is unreachable**. This is causing an
impact in cases where the rtpengine crashes (luckily not so often).
We have been doing some tests, and with this change
El vie, 5 feb 2021 a las 10:43, David Escartin ()
escribió:
> Dear all
>
> since version 4.4 we are using this parameter to 1 to allow that ongoing
> calls process their messages through a particular rtpengine when disabling
> it manually from database.
> But we see that enabling it also makes all the messages select the
> rtpengine and attempt to send its own op command. This is causing an impact
> in cases where the rtpengine crashes (luckily not so often).
>
> We have been doing some tests, and with this change
>
> diff --git a/src/modules/rtpengine/rtpengine.c
>> b/src/modules/rtpengine/rtpengine.c
>> index 20df725d2e..2f6130c62a 100644
>> --- a/src/modules/rtpengine/rtpengine.c
>> +++ b/src/modules/rtpengine/rtpengine.c
>> @@ -3138,11 +3138,12 @@ select_rtpp_node(str callid, str viabranch, int
>> do_test, struct rtpp_node **quer
>> if (node->rn_recheck_ticks ==
>> RTPENGINE_MAX_RECHECK_TICKS) {
>> LM_DBG("node=%.*s for calllen=%d callid=%.*s is
>> disabled(permanent) (probably still UP)! Return it\n",
>> node->rn_url.len, node->rn_url.s,
>> callid.len, callid.len, callid.s);
>> +return node;
>> } else {
>> LM_DBG("node=%.*s for calllen=%d callid=%.*s is
>> disabled, either broke or timeout disabled! Return it\n",
>> node->rn_url.len, node->rn_url.s,
>> callid.len, callid.len, callid.s);
>> }
>> - return node;
>> + /*return node;*/
>> }
>>
>> return NULL;
>
>
> it would make to only use allow_op for manually disabled rtpengine nodes,
> and would make to not select the node and not try to send the rtpp command,
> so we would not have almost any impact in kamailio like timeouts and
> congestion, expect having messages not doing rtpengine in a call where
> others did.
>
> Do you think this change could make sense?
> Is there any reason for being like it is now?
>
> thanks a lot and regards
> david
>
> --
> [image: Logo]
>
> David Escartín Almudévar
> VoIP/Switch Engineer
> descar...@sonoc.io
>
> *SONOC*
> C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
> Tlf: +34 917019888 · www.sonoc.io
>
--
[image: Logo]
David Escartín Almudévar
VoIP/Switch Engineer
descar...@sonoc.io
*SONOC*
C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
Tlf: +34 917019888 · www.sonoc.io
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] rtpengine_allow_op usage doubt
Dear all
since version 4.4 we are using this parameter to 1 to allow that ongoing
calls process their messages through a particular rtpengine when disabling
it manually from database.
But we see that enabling it also makes all the messages select the
rtpengine and attempt to send its own op command. This is causing an impact
in cases where the rtpengine crashes (luckily not so often).
We have been doing some tests, and with this change
diff --git a/src/modules/rtpengine/rtpengine.c
> b/src/modules/rtpengine/rtpengine.c
> index 20df725d2e..2f6130c62a 100644
> --- a/src/modules/rtpengine/rtpengine.c
> +++ b/src/modules/rtpengine/rtpengine.c
> @@ -3138,11 +3138,12 @@ select_rtpp_node(str callid, str viabranch, int
> do_test, struct rtpp_node **quer
> if (node->rn_recheck_ticks == RTPENGINE_MAX_RECHECK_TICKS)
> {
> LM_DBG("node=%.*s for calllen=%d callid=%.*s is
> disabled(permanent) (probably still UP)! Return it\n",
> node->rn_url.len, node->rn_url.s,
> callid.len, callid.len, callid.s);
> +return node;
> } else {
> LM_DBG("node=%.*s for calllen=%d callid=%.*s is
> disabled, either broke or timeout disabled! Return it\n",
> node->rn_url.len, node->rn_url.s,
> callid.len, callid.len, callid.s);
> }
> - return node;
> + /*return node;*/
> }
>
> return NULL;
it would make to only use allow_op for manually disabled rtpengine nodes,
and would make to not select the node and not try to send the rtpp command,
so we would not have almost any impact in kamailio like timeouts and
congestion, expect having messages not doing rtpengine in a call where
others did.
Do you think this change could make sense?
Is there any reason for being like it is now?
thanks a lot and regards
david
--
[image: Logo]
David Escartín Almudévar
VoIP/Switch Engineer
descar...@sonoc.io
*SONOC*
C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
Tlf: +34 917019888 · www.sonoc.io
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] issue using evapi module with evapi_relay
Hello Daniel
Thanks a lot for the feedback
I tried the netstring option but since i had to reparse in the application,
I finally didn't use it.
But I will consider it since I will test the performance for heavy load
during the next days.
About the tcp_nodelay option, I remember I saw no frames with more than a
message (Json object) relayed to evapi and sent out to the socket :$, but
anycase, I removed that option and changed the application side.
best regards
david
El vie, 11 dic 2020 a las 13:51, Daniel-Constantin Mierla (<
mico...@gmail.com>) escribió:
> Hello,
>
> tcp is a streaming protocol, it is the receiving application that has to
> parse and split the stream content in logical messages from its point of
> view. As you noticed, there can be socket options to enforce some sending
> policy (wait or not wait for a specific amount of data to accumulate, not
> to send too many small packets, but if it is too much in very short time,
> it is no difference).
>
> As a side note, your patch below is setting the TCP_NODELAY to listen
> socket, not to the socket associated with the client connection (returned
> by accept()). I do not think is inherited by accept() from listen socket,
> in such case practically your patch didn't make any difference in behaviour.
>
> The evapi module has the option (modparam) to serialize the packets in
> netstring format, being easier to split the stream in messages and I would
> recommend that mode for heavy traffic.
>
> At the end, we can introduce modparams for evapi to set TCP_NODELAY, it
> can be useful to reduce delays when sending short data messages from time
> to time, but it won't help in your case.
>
> Cheers,
> Daniel
> On 11.12.20 09:39, David Escartin wrote:
>
> Dear all
>
> seems the issue was not on the module or related to kamailio, but related
> to the application we were using to read from tcp socket.
> I saw that some messages sent with evapi_relay were encapsulated in the
> same frame, and i even tried to force the TCP_NODELAY option on the evapi
> socket by compiling the kamailio with this
> --- a/src/modules/evapi/evapi_dispatch.c
> +++ b/src/modules/evapi/evapi_dispatch.c
> @@ -30,8 +30,8 @@
> #include
> #include
> #include
> -
> #include
> +#include
>
> #include "../../core/sr_module.h"
> #include "../../core/dprint.h"
> @@ -690,6 +691,15 @@ int evapi_run_dispatcher(char *laddr, int lport)
> freeaddrinfo(ai_res);
> return -1;
> }
> +
> +if(setsockopt(evapi_srv_sock, IPPROTO_TCP, TCP_NODELAY,
> + _true, sizeof(int)) < 0) {
> + LM_INFO("cannot set TCP_NODELAY option on descriptor\n");
> + close(evapi_srv_sock);
> + freeaddrinfo(ai_res);
> + return -1;
> + }
> +
>
> if (bind(evapi_srv_sock, ai_res->ai_addr, ai_res->ai_addrlen) < 0)
> {
> LM_ERR("cannot bind to local address and port [%s:%d]\n",
> laddr, lport);
>
> and i saw that with this change we had always a frame for each message
> published to evapi, but the issue was still there.
> So no matter if this option was activated or not in Kamailio, I had to
> tune the application (in erlang) to delimit the messages received by
> converting them to line mode. This way we could reach up to 1000 processed
> messages per second.
>
> best regards
> david
>
>
>
> El lun, 30 nov 2020 a las 11:19, David Escartin ()
> escribió:
>
>> Dear all
>>
>> we have been testing this module with the following setup
>> kamailio 5.3.2
>> evapi params
>> modparam("evapi", "workers", 4)
>> modparam("evapi", "netstring_format", 0)
>> modparam("evapi", "bind_addr", "127.0.0.1:8448")
>> modparam("evapi", "max_clients", 32)
>>
>> then in the configuration we do evapi_relay of avp including a json data
>> (which can be quite long), like this
>> {"key" : "aarp2q0tcpqhs0cpucuhukjs2ah2j00q@10.18.5.64" , "msg" :
>> {"rg_in":"701","ani_init":{"ani_source":"pai", ... }}}
>>
>> We have an application listening on the tcp socket and writing those
>> messages to a kafka cluster, and this works ok, and in the previous manual
>> tests we have done no issue was found.
>> But when making some load tests, and passing some live traffic we see
>> some issues
>>
>> seems like some times, when there are messages to be sent to the tcp
>> socket at the same time, they are sent in the
Re: [sr-dev] issue using evapi module with evapi_relay
Dear all
seems the issue was not on the module or related to kamailio, but related
to the application we were using to read from tcp socket.
I saw that some messages sent with evapi_relay were encapsulated in the
same frame, and i even tried to force the TCP_NODELAY option on the evapi
socket by compiling the kamailio with this
--- a/src/modules/evapi/evapi_dispatch.c
+++ b/src/modules/evapi/evapi_dispatch.c
@@ -30,8 +30,8 @@
#include
#include
#include
-
#include
+#include
#include "../../core/sr_module.h"
#include "../../core/dprint.h"
@@ -690,6 +691,15 @@ int evapi_run_dispatcher(char *laddr, int lport)
freeaddrinfo(ai_res);
return -1;
}
+
+if(setsockopt(evapi_srv_sock, IPPROTO_TCP, TCP_NODELAY,
+ _true, sizeof(int)) < 0) {
+ LM_INFO("cannot set TCP_NODELAY option on descriptor\n");
+ close(evapi_srv_sock);
+ freeaddrinfo(ai_res);
+ return -1;
+ }
+
if (bind(evapi_srv_sock, ai_res->ai_addr, ai_res->ai_addrlen) < 0) {
LM_ERR("cannot bind to local address and port [%s:%d]\n",
laddr, lport);
and i saw that with this change we had always a frame for each message
published to evapi, but the issue was still there.
So no matter if this option was activated or not in Kamailio, I had to tune
the application (in erlang) to delimit the messages received by converting
them to line mode. This way we could reach up to 1000 processed messages
per second.
best regards
david
El lun, 30 nov 2020 a las 11:19, David Escartin ()
escribió:
> Dear all
>
> we have been testing this module with the following setup
> kamailio 5.3.2
> evapi params
> modparam("evapi", "workers", 4)
> modparam("evapi", "netstring_format", 0)
> modparam("evapi", "bind_addr", "127.0.0.1:8448")
> modparam("evapi", "max_clients", 32)
>
> then in the configuration we do evapi_relay of avp including a json data
> (which can be quite long), like this
> {"key" : "aarp2q0tcpqhs0cpucuhukjs2ah2j00q@10.18.5.64" , "msg" :
> {"rg_in":"701","ani_init":{"ani_source":"pai", ... }}}
>
> We have an application listening on the tcp socket and writing those
> messages to a kafka cluster, and this works ok, and in the previous manual
> tests we have done no issue was found.
> But when making some load tests, and passing some live traffic we see some
> issues
>
> seems like some times, when there are messages to be sent to the tcp
> socket at the same time, they are sent in the same message, when normally
> each data sent using evapi_relay is sent in 1 message
> We do sometimes see something like this on the application consuming from
> the tcp socket
> 2020-11-25 15:20:01.744 UTC [error]
> <0.706.0>@evapi_kafka_listener:handle_info:167 body "{\"key\" : \"
> 6142651aa63616c6c04a783cd@72.21.24.130\" , \"msg\" :
> {\"rg_in\":\"677\",\"ani_init\":{\"ani_source\":\"fro\",...}}}{\"key\"
> : \"isbc7caT4001915251VabcGhEfHdNiF0i@172.16.120.1\" , \"msg\" :
> {\"rg_in\":\"22\",\"ani_init\":{\"ani_source\":\"pai\", ...
> ,\"translate" not valid json; error = {691,invalid_trailing_data}
> 2020-11-25 15:20:01.745 UTC [error]
> <0.706.0>@evapi_kafka_listener:handle_info:167 body
> "dPartition\":\"-1\",..}}}" not valid json; error = {1,invalid_json}
>
> and we do see that the application cannot parse the json message fine,
> because we have like 2 json objects together
> ..{\"ani_source\":\"fro\",...}}}{\"key\" :
> \"isbc7caT4001915251Vabc
> This happens with 2 different UDP receivers processing messages and
> calling evapi_relay at the same time. But i don't think this happens all
> the time. Seems like some issue when several processes try to use evapi
> workers at the same time.
> We tried to increase evapi workers and it's the same
>
> We also saw another issue I think. Seems when the avp sent to evapi socket
> is bigger than ~1680 char, the json is also truncated, and also happens
> when we use the socket in Lo interface which has an MTU of 65535.
>
> Could you please take a look to see if there is any problem or limitation,
> or if we are using something wrong?
>
> thanks and best regards
> david
>
> --
> [image: Logo]
>
> David Escartín Almudévar
> VoIP/Switch Engineer
> descar...@sonoc.io
>
> *SONOC*
> C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
> Tlf: +34 917019888 · www.sonoc.io
>
--
[image: Logo]
David Escartín Almudévar
VoIP/Switch Engineer
descar...@sonoc.io
*SONOC*
C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
Tlf: +34 917019888 · www.sonoc.io
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] issue using evapi module with evapi_relay
Dear all
we have been testing this module with the following setup
kamailio 5.3.2
evapi params
modparam("evapi", "workers", 4)
modparam("evapi", "netstring_format", 0)
modparam("evapi", "bind_addr", "127.0.0.1:8448")
modparam("evapi", "max_clients", 32)
then in the configuration we do evapi_relay of avp including a json data
(which can be quite long), like this
{"key" : "aarp2q0tcpqhs0cpucuhukjs2ah2j00q@10.18.5.64" , "msg" :
{"rg_in":"701","ani_init":{"ani_source":"pai", ... }}}
We have an application listening on the tcp socket and writing those
messages to a kafka cluster, and this works ok, and in the previous manual
tests we have done no issue was found.
But when making some load tests, and passing some live traffic we see some
issues
seems like some times, when there are messages to be sent to the tcp socket
at the same time, they are sent in the same message, when normally each
data sent using evapi_relay is sent in 1 message
We do sometimes see something like this on the application consuming from
the tcp socket
2020-11-25 15:20:01.744 UTC [error]
<0.706.0>@evapi_kafka_listener:handle_info:167 body "{\"key\" : \"
6142651aa63616c6c04a783cd@72.21.24.130\" , \"msg\" :
{\"rg_in\":\"677\",\"ani_init\":{\"ani_source\":\"fro\",...}}}{\"key\"
: \"isbc7caT4001915251VabcGhEfHdNiF0i@172.16.120.1\" , \"msg\" :
{\"rg_in\":\"22\",\"ani_init\":{\"ani_source\":\"pai\", ...
,\"translate" not valid json; error = {691,invalid_trailing_data}
2020-11-25 15:20:01.745 UTC [error]
<0.706.0>@evapi_kafka_listener:handle_info:167 body
"dPartition\":\"-1\",..}}}" not valid json; error = {1,invalid_json}
and we do see that the application cannot parse the json message fine,
because we have like 2 json objects together
..{\"ani_source\":\"fro\",...}}}{\"key\" :
\"isbc7caT4001915251Vabc
This happens with 2 different UDP receivers processing messages and calling
evapi_relay at the same time. But i don't think this happens all the time.
Seems like some issue when several processes try to use evapi workers at
the same time.
We tried to increase evapi workers and it's the same
We also saw another issue I think. Seems when the avp sent to evapi socket
is bigger than ~1680 char, the json is also truncated, and also happens
when we use the socket in Lo interface which has an MTU of 65535.
Could you please take a look to see if there is any problem or limitation,
or if we are using something wrong?
thanks and best regards
david
--
[image: Logo]
David Escartín Almudévar
VoIP/Switch Engineer
descar...@sonoc.io
*SONOC*
C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
Tlf: +34 917019888 · www.sonoc.io
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] dialog: reason behind not storing early state dialogs in db
Dear all this would be related to one query we sent to sr-users some time ago? https://lists.kamailio.org/pipermail/sr-users/2018-November/103842.html we would also be interested in having the dialog structure to be written on db_redis during early dialog, but it still was in a to do list according to Daniel. This would great to be able to track and store the dialogs on a db redis for HA. thanks a lot and regards david El mié., 10 jun. 2020 a las 11:25, Henning Westerholt () escribió: > Hi Victor, > > I guess it was done because of easier implementation and also DB load > considerations. > > I planned to add functionality to make it configurable in git master it > this week, as I also have the requirements in one of my projects. > > Cheers, > > Henning > > -- > Henning Westerholt – https://skalatan.de/blog/ > Kamailio services – https://gilawa.com > > -Original Message- > From: sr-dev On Behalf Of Victor Seva > Sent: Wednesday, June 10, 2020 10:32 AM > To: Kamailio Devel List > Subject: [sr-dev] dialog: reason behind not storing early state dialogs in > db > > Hi, > > is there a known reason not to store early state dialogs in db? > > I have some logic relaying on event_route exported by dialog module and > that logic breaks for non confirmed dialogs when a switch-over happens > since those dialogs are not loaded from db. > > Thanks in advance, > Victor > > > ___ > Kamailio (SER) - Development Mailing List > sr-dev@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev > > > ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] possible bug on kemi dlg_ontimeout
Hello Daniel
thanks a lot
Regards
david
El lun., 6 abr. 2020 a las 13:22, Daniel-Constantin Mierla (<
mico...@gmail.com>) escribió:
> Hello,
>
> apparently it was not backported to 5.3, somehow I forgot about it. I just
> did it a few minutes ago.
>
> Cheers,
> Daniel
> On 06.04.20 10:49, David Escartin wrote:
>
> Dear Daniel
>
> hope everything is ok.
> Sorry if i missed something, but has been this patch already backported
> from master to 5.3 yet?
>
> thanks alot and regards
> david
>
> El jue., 13 feb. 2020 a las 18:12, David Escartin ()
> escribió:
>
>> hello Daniel
>>
>> i have tried it and seems fine.
>>
>> thanks a lot and regards
>> david
>>
>> El jue., 13 feb. 2020 a las 17:13, Daniel-Constantin Mierla (<
>> mico...@gmail.com>) escribió:
>>
>>> Hello,
>>>
>>> indeed keeping route block index in unsigned it can create problems. I
>>> pushed a patch for it:
>>>
>>> -
>>> https://github.com/kamailio/kamailio/commit/6c557efc1b9cb8c880a05235c94780bbaf305073
>>>
>>> Can you try and see if now works ok? If yes, it will be backported.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 13.02.20 13:27, David Escartin wrote:
>>>
>>> Hello all
>>>
>>> Testing dialog timeout event callback for kemi lua setup on kamailio
>>> 5.4.0-dev3 (x86_64/linux) d74157-dirty, i had some problems to perform the
>>> dlg timeroute behaviour the same as we could on native version.
>>> If i used KSR.dialog.var_sets to set $dlg_ctx(timeout_route), I saw that
>>> on a dialog timeout, the dlg_ontimeout event route was not triggered, and
>>> only the dialog callback was executed with evname dialog:end.
>>> (only executing event_route -1 on state 5)
>>> So i'm guessing that the kemi dialog var_sets is for $dlg_var only (¿?)
>>> Anycase, If i used KSR.pv.sets, i saw the kamailio was crashing
>>> .
>>> 16(5579) DEBUG: dialog [dlg_hash.c:1013]: dlg_ref_helper(): ref dlg
>>> 0x7f9a961f5f90 with 1 -> 3
>>> 16(5579) DEBUG: dialog [dlg_handlers.c:1589]: dlg_ontimeout(): executing
>>> route -1 on timeout
>>> 22(5645) CRITICAL: [core/pass_fd.c:277]: receive_fd(): EOF on 8
>>> 22(5645) DEBUG: [core/tcp_main.c:3762]: handle_ser_child(): dead
>>> child 16, pid 5579 (shutting down?)
>>>
>>> Adding some debug, i could see that the call was not attempting the kemi
>>> function of line 1598 of dlg_handlers.c, and was trying the code i think
>>> was for native on line 1593.
>>> We think the issue is that the toroute is defined as unsigned
>>> dlg_hash.h: unsigned int toroute; /*!< index of route that is
>>> executed on timeout */
>>> but after that when setting $dlg_ctx(timeout_route) with pv module, it
>>> tries to compare an integer being unsigned, so it's always true and never
>>> uses kemi
>>> with this change we made it work
>>> + if ((int)(dlg->toroute) > 0) {
>>> + /*if(dlg->toroute>0) {*/
>>> but i don't know maybe there is a better way to do it.
>>>
>>> best regards
>>> david
>>>
>>> ___
>>> Kamailio (SER) - Development Mailing
>>> Listsr-dev@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>> --
>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
>>> www.linkedin.com/in/miconda
>>> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
>>> Kamailio World Conference - April 27-29, 2020, in Berlin --
>>> www.kamailioworld.com
>>>
>>> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
> www.linkedin.com/in/miconda
>
>
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] possible bug on kemi dlg_ontimeout
Dear Daniel
hope everything is ok.
Sorry if i missed something, but has been this patch already backported
from master to 5.3 yet?
thanks alot and regards
david
El jue., 13 feb. 2020 a las 18:12, David Escartin ()
escribió:
> hello Daniel
>
> i have tried it and seems fine.
>
> thanks a lot and regards
> david
>
> El jue., 13 feb. 2020 a las 17:13, Daniel-Constantin Mierla (<
> mico...@gmail.com>) escribió:
>
>> Hello,
>>
>> indeed keeping route block index in unsigned it can create problems. I
>> pushed a patch for it:
>>
>> -
>> https://github.com/kamailio/kamailio/commit/6c557efc1b9cb8c880a05235c94780bbaf305073
>>
>> Can you try and see if now works ok? If yes, it will be backported.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 13.02.20 13:27, David Escartin wrote:
>>
>> Hello all
>>
>> Testing dialog timeout event callback for kemi lua setup on kamailio
>> 5.4.0-dev3 (x86_64/linux) d74157-dirty, i had some problems to perform the
>> dlg timeroute behaviour the same as we could on native version.
>> If i used KSR.dialog.var_sets to set $dlg_ctx(timeout_route), I saw that
>> on a dialog timeout, the dlg_ontimeout event route was not triggered, and
>> only the dialog callback was executed with evname dialog:end.
>> (only executing event_route -1 on state 5)
>> So i'm guessing that the kemi dialog var_sets is for $dlg_var only (¿?)
>> Anycase, If i used KSR.pv.sets, i saw the kamailio was crashing
>> .
>> 16(5579) DEBUG: dialog [dlg_hash.c:1013]: dlg_ref_helper(): ref dlg
>> 0x7f9a961f5f90 with 1 -> 3
>> 16(5579) DEBUG: dialog [dlg_handlers.c:1589]: dlg_ontimeout(): executing
>> route -1 on timeout
>> 22(5645) CRITICAL: [core/pass_fd.c:277]: receive_fd(): EOF on 8
>> 22(5645) DEBUG: [core/tcp_main.c:3762]: handle_ser_child(): dead
>> child 16, pid 5579 (shutting down?)
>>
>> Adding some debug, i could see that the call was not attempting the kemi
>> function of line 1598 of dlg_handlers.c, and was trying the code i think
>> was for native on line 1593.
>> We think the issue is that the toroute is defined as unsigned
>> dlg_hash.h: unsigned int toroute; /*!< index of route that is
>> executed on timeout */
>> but after that when setting $dlg_ctx(timeout_route) with pv module, it
>> tries to compare an integer being unsigned, so it's always true and never
>> uses kemi
>> with this change we made it work
>> + if ((int)(dlg->toroute) > 0) {
>> + /*if(dlg->toroute>0) {*/
>> but i don't know maybe there is a better way to do it.
>>
>> best regards
>> david
>>
>> ___
>> Kamailio (SER) - Development Mailing
>> Listsr-dev@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
>> www.linkedin.com/in/miconda
>> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
>> Kamailio World Conference - April 27-29, 2020, in Berlin --
>> www.kamailioworld.com
>>
>>
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] uac_replace_from rare behaviour
Hello all we just noticed an issue using this function when we call it with 2 params (display and uri) and the SIP INVITE comes with a From uri like sip:anonymous@anonymous.invalid; tag=13133439191609, without <> delimiters, then doing the uac replace in the ACK we have 2(14923) DEBUG: uac [replace.c:922]: replace_callback(): DOWNSTREAM direction detected - replacing uri with the new uri 2(14923) DEBUG: uac [replace.c:943]: replace_callback(): Replace [ sip:anonymous@anonymous.invalid] with ["14254350027" sip:14254350027@1.1.18.171] 2(14923) DEBUG: uac [replace.c:980]: replace_callback(): inserting display ["14254350027"] And this is the From header replaced From: sip:14254350027@1.1.18.171"14254350027" <>;tag=13133439191609 But if the call comes with a From header like ; tag=13133439191609 Then this is the From header replaced 2(19741) DEBUG: uac [replace.c:922]: replace_callback(): DOWNSTREAM direction detected - replacing uri with the new uri 2(19741) DEBUG: uac [replace.c:943]: replace_callback(): Replace [ sip:1241342@1.1.18.171:5074] with ["14254350027" sip:14254350027@1.1.18.171] 2(19741) DEBUG: uac [replace.c:980]: replace_callback(): inserting display ["14254350027"] From: "14254350027" ;tag=13133439191609 Were you aware of this kind of behaviour? If possible we will look for a patch for this. thanks a lot and regards david ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] possible bug on kemi dlg_ontimeout
hello Daniel
i have tried it and seems fine.
thanks a lot and regards
david
El jue., 13 feb. 2020 a las 17:13, Daniel-Constantin Mierla (<
mico...@gmail.com>) escribió:
> Hello,
>
> indeed keeping route block index in unsigned it can create problems. I
> pushed a patch for it:
>
> -
> https://github.com/kamailio/kamailio/commit/6c557efc1b9cb8c880a05235c94780bbaf305073
>
> Can you try and see if now works ok? If yes, it will be backported.
>
> Cheers,
> Daniel
>
>
> On 13.02.20 13:27, David Escartin wrote:
>
> Hello all
>
> Testing dialog timeout event callback for kemi lua setup on kamailio
> 5.4.0-dev3 (x86_64/linux) d74157-dirty, i had some problems to perform the
> dlg timeroute behaviour the same as we could on native version.
> If i used KSR.dialog.var_sets to set $dlg_ctx(timeout_route), I saw that
> on a dialog timeout, the dlg_ontimeout event route was not triggered, and
> only the dialog callback was executed with evname dialog:end.
> (only executing event_route -1 on state 5)
> So i'm guessing that the kemi dialog var_sets is for $dlg_var only (¿?)
> Anycase, If i used KSR.pv.sets, i saw the kamailio was crashing
> .
> 16(5579) DEBUG: dialog [dlg_hash.c:1013]: dlg_ref_helper(): ref dlg
> 0x7f9a961f5f90 with 1 -> 3
> 16(5579) DEBUG: dialog [dlg_handlers.c:1589]: dlg_ontimeout(): executing
> route -1 on timeout
> 22(5645) CRITICAL: [core/pass_fd.c:277]: receive_fd(): EOF on 8
> 22(5645) DEBUG: [core/tcp_main.c:3762]: handle_ser_child(): dead
> child 16, pid 5579 (shutting down?)
>
> Adding some debug, i could see that the call was not attempting the kemi
> function of line 1598 of dlg_handlers.c, and was trying the code i think
> was for native on line 1593.
> We think the issue is that the toroute is defined as unsigned
> dlg_hash.h: unsigned int toroute; /*!< index of route that is
> executed on timeout */
> but after that when setting $dlg_ctx(timeout_route) with pv module, it
> tries to compare an integer being unsigned, so it's always true and never
> uses kemi
> with this change we made it work
> + if ((int)(dlg->toroute) > 0) {
> + /*if(dlg->toroute>0) {*/
> but i don't know maybe there is a better way to do it.
>
> best regards
> david
>
> ___
> Kamailio (SER) - Development Mailing
> Listsr-dev@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
> www.linkedin.com/in/miconda
> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
> Kamailio World Conference - April 27-29, 2020, in Berlin --
> www.kamailioworld.com
>
>
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] possible bug on kemi dlg_ontimeout
Hello all
Testing dialog timeout event callback for kemi lua setup on kamailio
5.4.0-dev3 (x86_64/linux) d74157-dirty, i had some problems to perform the
dlg timeroute behaviour the same as we could on native version.
If i used KSR.dialog.var_sets to set $dlg_ctx(timeout_route), I saw that on
a dialog timeout, the dlg_ontimeout event route was not triggered, and only
the dialog callback was executed with evname dialog:end. (only executing
event_route -1 on state 5)
So i'm guessing that the kemi dialog var_sets is for $dlg_var only (¿?)
Anycase, If i used KSR.pv.sets, i saw the kamailio was crashing
.
16(5579) DEBUG: dialog [dlg_hash.c:1013]: dlg_ref_helper(): ref dlg
0x7f9a961f5f90 with 1 -> 3
16(5579) DEBUG: dialog [dlg_handlers.c:1589]: dlg_ontimeout(): executing
route -1 on timeout
22(5645) CRITICAL: [core/pass_fd.c:277]: receive_fd(): EOF on 8
22(5645) DEBUG: [core/tcp_main.c:3762]: handle_ser_child(): dead
child 16, pid 5579 (shutting down?)
Adding some debug, i could see that the call was not attempting the kemi
function of line 1598 of dlg_handlers.c, and was trying the code i think
was for native on line 1593.
We think the issue is that the toroute is defined as unsigned
dlg_hash.h: unsigned int toroute; /*!< index of route that is
executed on timeout */
but after that when setting $dlg_ctx(timeout_route) with pv module, it
tries to compare an integer being unsigned, so it's always true and never
uses kemi
with this change we made it work
+ if ((int)(dlg->toroute) > 0) {
+ /*if(dlg->toroute>0) {*/
but i don't know maybe there is a better way to do it.
best regards
david
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] some missing kemi module functions
Dear Daniel
i have been rewriting all the native configuration we have for a proxy to
kemi lua and i'm (i think) having it working fine, but i'm still missing
some functions to be migrated, some of those are not even working with
KSR.x.modf
Now i'm using version: kamailio 5.4.0-dev2 (x86_64/linux) f268aa
-be able to select facility on KSR.xlog, equivalent to xlog("LOG_LOCAL7",
"L_NOTICE", "$var(x)");
-sipt module functions
-dialog dlg_set_ruri function (maybe some others), this is now even working
with modf (ERROR: app_lua [app_lua_api.c:1633]: sr_kemi_lua_modf():
function 'dlg_set_ruri' is not available)
-tm t_relay_to_tcp
if you have any update about this function exportation, it would be great
best regards
david
El jue., 27 jun. 2019 a las 15:28, David Escartin ()
escribió:
> Hello Daniel
>
> thanks a lot for the feedback, ok i will try the hdr functions, i missed
> them in the documentation.
> About call_obj, yes, the commits were pushed today
>
> if i see something else i will let you know
>
> best regards
> david
>
>
>
> El jue., 27 jun. 2019 a las 14:50, Daniel-Constantin Mierla (<
> mico...@gmail.com>) escribió:
>
>> And the functions for dialog vars are in latest master branch, -dev5 is a
>> bit older, last one has -dev6. Fetch latest master branch and try again.
>>
>> On Thu, Jun 27, 2019 at 2:46 PM Daniel-Constantin Mierla <
>> mico...@gmail.com> wrote:
>>
>>> Hello,
>>> in short, all functions exported to native kamailio.cfg will be exported
>>> to KEMI if they don't have an (native) alternative in those scripting
>>> languages. If some are missing, that's because nobody did it so far for
>>> specific modules and maybe I missed some functions for modules that already
>>> have some exports to KEMI.
>>>
>>> Those from sdpops likely I missed them, I will export them. Then I am
>>> not sure why sipt was skipped, should be exported as well -- if nobody does
>>> it, I will do it sometime soon. For call_obj I already saw commits pushed
>>> to master. Variants of xlog functions could be missing, because was one of
>>> the first modules exported to KEMI, but with the commonly used (at least by
>>> me) functions, needed for testing, then probably I didn't approach again
>>> the module.
>>>
>>> Regarding the header operations, the remove, insert and append are
>>> exported via KSR.hdr submodule, not KSR.textops. It was how Lua had it in
>>> the previous version and when I started with KEMI, I worked on old lua
>>> module code. Maybe confusing a bit, anyhow the docs are at:
>>> *
>>> https://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/core/#ksrhdr-submodule
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On Thu, Jun 27, 2019 at 12:07 PM David Escartin
>>> wrote:
>>>
>>>> hello all
>>>>
>>>> we are trying to rewrite our code to lua kemi, and we have found some
>>>> issues/questions until we would like to share with you.
>>>>
>>>> -module call_obj not exported, we have tested a patch for the module to
>>>> export the functions to kemi, which seems works fine
>>>>
>>>> -KSR.xlog.xinfo seems not able to select a facility as we currently can
>>>> like xlog("LOG_LOCAL7", "L_NOTICE", "$var()");
>>>>
>>>> -module sipt not exported yet, must use ksr.x.modf ? will be exported
>>>> for a future version?
>>>>
>>>> -on 5.3.0-dev5 we don't see the KSR.dialog.var_sets() and
>>>> KSR.dialog.var_get/e/w() functions in the code, so we do use KSR.pv
>>>> functions to set and retrieve those dialog vars. However i see them on
>>>> master branch. Which kamailio release would have them?
>>>>
>>>> -sdpops function sdp_with_codecs_by_name seems to not me exported, is
>>>> it on a todo list?
>>>>
>>>> -textops module, missing remove_hf and append_hf functions exported. We
>>>> already did a patch for the remove_hf, despite we could work with textopsx
>>>> remove_hf_value function to get the almost the same functionality.
>>>> However, with append_hf i'm having some more issues.
>>>> We cannot use modf to exec those funtions, we get something like
>>>> For ---> KSR.x.modf("append_hf", "User-Agent: test", "To");
>>>> I get something like > Jun 27 07:19:16 proxy-1
>>>> /usr/local/kamailio/sbin/kamailio[5525]: ERROR: a
Re: [sr-dev] some missing kemi module functions
Hello Daniel
thanks a lot for the feedback, ok i will try the hdr functions, i missed
them in the documentation.
About call_obj, yes, the commits were pushed today
if i see something else i will let you know
best regards
david
El jue., 27 jun. 2019 a las 14:50, Daniel-Constantin Mierla (<
mico...@gmail.com>) escribió:
> And the functions for dialog vars are in latest master branch, -dev5 is a
> bit older, last one has -dev6. Fetch latest master branch and try again.
>
> On Thu, Jun 27, 2019 at 2:46 PM Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>> in short, all functions exported to native kamailio.cfg will be exported
>> to KEMI if they don't have an (native) alternative in those scripting
>> languages. If some are missing, that's because nobody did it so far for
>> specific modules and maybe I missed some functions for modules that already
>> have some exports to KEMI.
>>
>> Those from sdpops likely I missed them, I will export them. Then I am not
>> sure why sipt was skipped, should be exported as well -- if nobody does it,
>> I will do it sometime soon. For call_obj I already saw commits pushed to
>> master. Variants of xlog functions could be missing, because was one of the
>> first modules exported to KEMI, but with the commonly used (at least by me)
>> functions, needed for testing, then probably I didn't approach again the
>> module.
>>
>> Regarding the header operations, the remove, insert and append are
>> exported via KSR.hdr submodule, not KSR.textops. It was how Lua had it in
>> the previous version and when I started with KEMI, I worked on old lua
>> module code. Maybe confusing a bit, anyhow the docs are at:
>> *
>> https://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/core/#ksrhdr-submodule
>>
>> Cheers,
>> Daniel
>>
>> On Thu, Jun 27, 2019 at 12:07 PM David Escartin
>> wrote:
>>
>>> hello all
>>>
>>> we are trying to rewrite our code to lua kemi, and we have found some
>>> issues/questions until we would like to share with you.
>>>
>>> -module call_obj not exported, we have tested a patch for the module to
>>> export the functions to kemi, which seems works fine
>>>
>>> -KSR.xlog.xinfo seems not able to select a facility as we currently can
>>> like xlog("LOG_LOCAL7", "L_NOTICE", "$var()");
>>>
>>> -module sipt not exported yet, must use ksr.x.modf ? will be exported
>>> for a future version?
>>>
>>> -on 5.3.0-dev5 we don't see the KSR.dialog.var_sets() and
>>> KSR.dialog.var_get/e/w() functions in the code, so we do use KSR.pv
>>> functions to set and retrieve those dialog vars. However i see them on
>>> master branch. Which kamailio release would have them?
>>>
>>> -sdpops function sdp_with_codecs_by_name seems to not me exported, is it
>>> on a todo list?
>>>
>>> -textops module, missing remove_hf and append_hf functions exported. We
>>> already did a patch for the remove_hf, despite we could work with textopsx
>>> remove_hf_value function to get the almost the same functionality.
>>> However, with append_hf i'm having some more issues.
>>> We cannot use modf to exec those funtions, we get something like
>>> For ---> KSR.x.modf("append_hf", "User-Agent: test", "To");
>>> I get something like > Jun 27 07:19:16 proxy-1
>>> /usr/local/kamailio/sbin/kamailio[5525]: ERROR: app_lua [app_lua_sr.c:188]:
>>> lua_sr_modf(): function 'append_hf' has fixup - cannot be used
>>>
>>> I could append a new header and not only at the end of the message by
>>> replacing a header called the same way, by doing something like
>>> KSR.textopsx.insert_hf_value("header", "value");
>>> KSR.textopsx.remove_hf_value("header[-1]");
>>>
>>> but i'm not able to insert a header after another different one like we
>>> can do with append_hf("header:value", "To") for instance.
>>> Is it expected to have it on a next commit those append_hf and remove_hf
>>> exported.
>>>
>>> Would we do a pull request with the ki_remove_hf we already have and the
>>> call_obj functions too? We can check to export append_hf too if it's not
>>> planned to be done
>>>
>>> thanks a lot and regards
>>> david
>>> ___
>>> Kamailio (SER) - Development Mailing List
>>> sr-dev@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> ___
> Kamailio (SER) - Development Mailing List
> sr-dev@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] some missing kemi module functions
hello all
we are trying to rewrite our code to lua kemi, and we have found some
issues/questions until we would like to share with you.
-module call_obj not exported, we have tested a patch for the module to
export the functions to kemi, which seems works fine
-KSR.xlog.xinfo seems not able to select a facility as we currently can
like xlog("LOG_LOCAL7", "L_NOTICE", "$var()");
-module sipt not exported yet, must use ksr.x.modf ? will be exported for a
future version?
-on 5.3.0-dev5 we don't see the KSR.dialog.var_sets() and
KSR.dialog.var_get/e/w() functions in the code, so we do use KSR.pv
functions to set and retrieve those dialog vars. However i see them on
master branch. Which kamailio release would have them?
-sdpops function sdp_with_codecs_by_name seems to not me exported, is it on
a todo list?
-textops module, missing remove_hf and append_hf functions exported. We
already did a patch for the remove_hf, despite we could work with textopsx
remove_hf_value function to get the almost the same functionality.
However, with append_hf i'm having some more issues.
We cannot use modf to exec those funtions, we get something like
For ---> KSR.x.modf("append_hf", "User-Agent: test", "To");
I get something like > Jun 27 07:19:16 proxy-1
/usr/local/kamailio/sbin/kamailio[5525]: ERROR: app_lua [app_lua_sr.c:188]:
lua_sr_modf(): function 'append_hf' has fixup - cannot be used
I could append a new header and not only at the end of the message by
replacing a header called the same way, by doing something like
KSR.textopsx.insert_hf_value("header", "value");
KSR.textopsx.remove_hf_value("header[-1]");
but i'm not able to insert a header after another different one like we can
do with append_hf("header:value", "To") for instance.
Is it expected to have it on a next commit those append_hf and remove_hf
exported.
Would we do a pull request with the ki_remove_hf we already have and the
call_obj functions too? We can check to export append_hf too if it's not
planned to be done
thanks a lot and regards
david
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
