Re: [SR-Users] Missing ACC record in case of canceled call forking

[Daniel-Constantin Mierla]

Hello,

I pushed a patch to print more debug messages when testing if accounting
should be done or not:

  -
https://github.com/kamailio/kamailio/commit/f21554c6befaddbc82016d5d498e11ab3720c404

Can you test with it and send me all debug messages for the respective
transaction in the case that doesn't work?

Cheers,
Daniel


On 04.09.18 14:03, Marco Capetta wrote:
> Hello,
>
> Yes Flag 3 is set at the very beginning when we start handling the
> received INVITE message.
> I checked and it is still active in both the branches of the outgoing
> INVITEs.
>
>
>
> In the 1st case the following ACC is generated:
>     id: 311
>     method: INVITE
>   from_tag:
>     to_tag:
>     callid: 121700311@X.X.X.X
>   sip_code: 487
> sip_reason: Request terminated
>   time: 2018-09-04 11:55:24
> time_hires: 1536054924.342
>
>
>
> I missed to say in my previous email that in kamailio ACC
> configuration we have also:
>   modparam("acc", "acc_prepare_always", 1)
>
>
> Thanks
> Marco
>  
>
>
> On 09/04/2018 11:39 AM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> is flag 3 set for the INVITE transaction?
>>
>> In the 1st case, is the CANCEL accounted or the INVITE transaction or both?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 04.09.18 11:18, Marco Capetta wrote:
>>> HiAll,
>>>
>>> As additional step I tested the scenario with kamailio v5.1.5 but the
>>> problem seems still there.
>>>
>>> Best regards.
>>> Marco
>>>
>>>
>>> On 08/28/2018 03:10 PM, Marco Capetta wrote:
 Hi All,

 I'm facing a strange problem of missing ACC record in case of
 parallel call forking.

 The scenario is the following:
  - A subscriber with 1 device registered
  - B subscriber with 2 device registered (B1 and B2)

 CASE 1:
  - A calls B
  - B1 and B2 start ringing
  - A hangups the call before B1 or B2 answers
 Kamailio generates an ACC record.

 CASE 2:
  - A calls B
  - B1 and B2 start ringing
  - B1 rejects the call sending back a 486
  - B2 is still ringing
  - A hangups the call before B2 answers
 Kamailio DOESN'T generate an ACC record.



 We have Kamailio v5.1.4 with TM module enabled.

 ACC configuration is the following:
   modparam("acc", "early_media", 0)
   modparam("acc", "report_ack", 0)
   modparam("acc", "report_cancels", 1)
   modparam("acc", "detect_direction", 1)
   modparam("acc", "db_flag", 1)
   modparam("acc", "db_missed_flag", 2)
   modparam("acc", "failed_transaction_flag", 3)


 I increased debug level of TM and ACC modules and I added some debug
 lines as well.
 The difference between the two calls is that, after the CANCEL sent
 by A is processed by Kamailio, in CASE 1 I have the following lines:
   Aug 28 14:21:11 spce proxy[13188]: DEBUG: tm [t_hooks.c:258]:
 run_trans_callbacks_internal(): DBG: trans=0x7f5a88049198, callback
 type 512, id 0 entered
   Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_logic.c:670]:
 tmcb_func(): acc callback called for t(0x7f5a88049198) event type
 512, reply code 487
   Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
 free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 0
   Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
 free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 1
   Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
 free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 2
   Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
 free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 3
   Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
 free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 4

 Those debug lines are not printed for CASE 2.



 Is there any configuration I'm missing or is it a bug?



 Thank you very much for your support.
 Marco

>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> -- 
> *Marco Capetta *
> Operations Engineer
>
> Sipwise GmbH  , Campus 21/Europaring F15
> AT-2345 Brunn am Gebirge
>
> Phone:  +43(0)1 301 2044 
> Email:  mcape...@sipwise.com 
> Website:  www.sipwise.com 
>
> Particulars according Austrian Companies Code paragraph 14
> "Sipwise GmbH" - Europaring F15 - 2345 Brunn am Gebirge
> FN:305595f, Commercial Court Vienna, ATU64002206
>

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

[SR-Users] Crashed drouting

[Евгений Голей]

Good evening.

I have errors on the server (kamailio v 5.1.0) "kamailio [30529]: segfault at 0 
ip 7f9c00c29cfb sp 7fffa9808310 error 4 in drouting.so [7f9c00c26000 + 
39000]" which cause the service to stop.  Although the drouting module has been 
used for a long time, this has never happened.  This was done after adding the 
functions of the dispatcher module.  What could be the reason ?

Example error
in system
kamailio [20728]: segfault at 0 ip 7f32c1c8fcfb sp 7fff78430d00 error 4 
in drouting.so [7f32c1c8c000 + 39000]

in the logs of kamailio
018-09-08T22: 30: 29.0448 "ALERT:  [main.c: 746]: handle_sigs (): child 
process 10556 exited by a signal 11"
2018-09-08T22: 30: 29.0452 "ALERT:  [main.c: 749]: handle_sigs (): core 
was generated"
2018-09-08T22: 30: 29.0456 "INFO:  [main.c: 771]: handle_sigs (): 
terminating due to SIGCHLD"


-- 
B.R. Evgeniy
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Missing ACC record in case of canceled call forking

[Marco Capetta]

Hi Daniel,

I applied your patch to our kamailio v5.1.4 because this is the current 
version we are using.



This is the log + debug of the call when the two INVITEs are leaving 
kamailio.

This part is common for both the call cases:

Sep 10 10:33:21 sp1 proxy[7627]: NOTICE: 

Re: [SR-Users] Simultaneous usage of t_on_reply() and t_on_failure()

[Володимир Іванець]

Hello Igor and Henning,

I used t_on_branch_failure() instead of t_on_failure() as Igor suggested
and now I can see that *event_route[tm:branch-failure:FAILURE_SIP_TO_SIP]*
is executed for both Htek 488 and Zoiper 415 responces.

Thanks a lot for your help!

2018-09-08 9:46 GMT+03:00 Igor Olhovskiy :

> I think you need to use
> t_on_branch_failure()
> If I got you correctly
>
> Regards, Igor
> On Sep 6, 2018, 10:06 PM +0300, Henning Westerholt ,
> wrote:
>
> Am Mittwoch, 5. September 2018, 14:03:10 CEST schrieb Володимир Іванець:
>
> I wanted to ask those who know if Kamailio's behavior I'm facing is
> expected or I should make some improvements to the configuration. Kamailio
> version is 5.1.0.
>
> I have a route where RTPEngine parameters are being collected and
> *rtpengine_offer()* is called. After that *t_on_reply("REPLY_SIP_TO_SIP"
> );*
> followed by the *t_on_failure("FAILURE_SIP_TO_SIP");* are used. The idea
> is
> to process all responces except 415 or 488 from UAC as usual in
> *onreply_route[REPLY_SIP_TO_SIP]* and use
> *failure_route[FAILURE_SIP_TO_SIP]* to update SDP with *rtpengine_offer()*
> if necessary.
>
> *onreply_route[REPLY_SIP_TO_SIP]* just goes to *exit;* if *$rs* equals 415
> or 488. This works fine with Htek phone which sends 100, 180 and then 488.
> But I can not see *failure_route[FAILURE_SIP_TO_SIP]* execution for calls
> to Zoiper which replies with 100 and immediately 415.
>
> t_on_failure(failure_route) documentation says: "Sets failure routing
> block, to which control is passed after a transaction completed with a
> negative result but before sending a final reply." and to be honest I don't
> really understand how lacking of responce prevents failure_route from
> executing.
>
>
> Hello,
>
> I did not understand you completely here. Did you receive a 415 and the
> failure route is not entered, or you did not receive a response as stated
> in
> the last sentence?
>
> If the failure_route is entered for the 488, then it should be also entered
> for the 415. I am not aware of a special handling of this code in tm. (Only
> that 415 is one of the replies that get a priority comparing to normal
> 4xx.)
>
> I would suggest to try with debugging enabled and compare the logs for a
> working, and for a non-working call. You could also try to concentrate on
> one
> problem first, like the failure_route topic, and then combining this with
> the
> reply_route.
>
> Best regards,
>
> Henning
>
> --
> Henning Westerholt
> https://skalatan.de/blog/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Crashed drouting

[Daniel-Constantin Mierla]

Hello,

if you are using v5.1.0, then you have upgrade to latest 5.1 branch and
try again, there were some fixes to drouting module that could cause the
issue in your case as well.

Cheers,
Daniel

On 10.09.18 09:22, Евгений Голей wrote:
> Good evening.
>
> I have errors on the server (kamailio v 5.1.0) "kamailio [30529]:
> segfault at 0 ip 7f9c00c29cfb sp 7fffa9808310 error 4 in
> drouting.so [7f9c00c26000 + 39000]" which cause the service to stop.
> Although the drouting module has been used for a long time, this has
> never happened. This was done after adding the functions of the
> dispatcher module. What could be the reason ?
>
> Example error
> in system
> kamailio [20728]: segfault at 0 ip 7f32c1c8fcfb sp
> 7fff78430d00 error 4 in drouting.so [7f32c1c8c000 + 39000]
>
> in the logs of kamailio
> 018-09-08T22: 30: 29.0448 "ALERT:  [main.c: 746]: handle_sigs
> (): child process 10556 exited by a signal 11"
> 2018-09-08T22: 30: 29.0452 "ALERT:  [main.c: 749]: handle_sigs
> (): core was generated"
> 2018-09-08T22: 30: 29.0456 "INFO:  [main.c: 771]: handle_sigs
> (): terminating due to SIGCHLD"
>
>
> -- 
> B.R. Evgeniy
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Missing ACC record in case of canceled call forking

[Daniel-Constantin Mierla]

Hello,

I need **all the logs**, not only those from acc module and script, but
all the modules and core.

Add also:

log_prefix="{$mt $hdr(CSeq) $ci} "

to be able to match log message with the request time.

And again, send the logs only for the case that fails.

Cheers,
Daniel

On 10.09.18 10:57, Marco Capetta wrote:
> Hi Daniel,
>
> I applied your patch to our kamailio v5.1.4 because this is the
> current version we are using.
>
>
> This is the log + debug of the call when the two INVITEs are leaving
> kamailio.
> This part is common for both the call cases:
>
> Sep 10 10:33:21 sp1 proxy[7627]: NOTICE: 

Re: [SR-Users] Crashed drouting

[Евгений Голей]

Many thanks!


>Понедельник, 10 сентября 2018, 13:21 +03:00 от Daniel-Constantin Mierla 
>:
>
>Hello,
>
>if you are using v5.1.0, then you have upgrade to latest 5.1
>  branch and try again, there were some fixes to drouting module
>  that could cause the issue in your case as well.
>
>Cheers,
>Daniel
>
>On 10.09.18 09:22, Евгений Голей wrote:
>>Good evening.
>>
>>I have errors on the server (kamailio v
>>  5.1.0) "kamailio [30529]: segfault at 0 ip 7f9c00c29cfb sp
>>  7fffa9808310 error 4 in drouting.so [7f9c00c26000 +
>>  39000]" which cause the service to stop.  Although the drouting 
>> module has been
>>  used for a long time, this has never happened.  This was done after 
>> adding the functions of the
>>  dispatcher module.  What could be the reason ?
>>
>>Example error
>>in system
>>kamailio [20728]: segfault at
>>  0 ip 7f32c1c8fcfb sp 7fff78430d00 error 4 in
>>  drouting.so [7f32c1c8c000 + 39000]
>>
>>in the logs of kamailio
>>018-09-08T22: 30: 29.0448 "ALERT:
>>   [main.c: 746]: handle_sigs (): child process
>>  10556 exited by a signal 11"
>>2018-09-08T22: 30: 29.0452 "ALERT:
>>   [main.c: 749]: handle_sigs (): core was
>>  generated"
>>2018-09-08T22: 30: 29.0456 "INFO: 
>>  [main.c: 771]: handle_sigs (): terminating due to SIGCHLD"
>>
>>
>>-- 
>>B.R. Evgeniy
>>
>>
>>___
>>Kamailio (SER) - Users Mailing List
>>sr-users@lists.kamailio.org
>>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>-- 
>Daniel-Constantin Mierla -- www.asipto.com
>www.twitter.com/miconda -- www.linkedin.com/in/miconda
>Kamailio World Conference -- www.kamailioworld.com
>Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com


-- 
С уважением,
Евгений Голей
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Logging of messages generated by Kamailio itself

[Konstantin Polyakov]

Hello Henning,

I used your advise and added into my configuration file two routes 
sl:local-response and tm:local-response.
The log became more detailed. 

But when 408 is sent by Kamailio on fr_inv_timer is expired, 
tm/sl:local-response is not called.
This situation can be processed in failure_route using t_branch_timeout() 
function.
However, I believe it is duty of local-response callback function as well.

Something wrong or it is expected behavior?

Best regrads,
Konstantin

>Пятница,  7 сентября 2018, 16:04 +03:00 от Henning Westerholt 
>:
>
>Am Freitag, 7. September 2018, 14:48:01 CEST schrieb Konstantin Polyakov:
>> In my configuration file I print into the log information about each SIP
>> message transferred by Kamailio. For example, xlog("L_NOTICE", "Request:
>> $rm CSeq:$cs CID:$ci from $si:$sp\n");
>> 
>> Request: ACK CSeq:18467 CID:473ae5eb58f9b271 from 192.168.158.139:5060
>> 
>> So when we want to find message flow which belongs to some call, we need
>> just grep by Call-Id.
>> 
>> The problem is that messages generated by Kamailio are not passed
>> through request_route function of configuration script. So script writer
>> cannot log such messages.
>> 
>> My question - is there way to log messages sent by Kamailio itself?
>
>Hello,
>
>have a look to the "failure_route" and "sl/tm:local-reponse" route 
>functionality in the example cfg or in the sl/tm module READMEs. There is some 
>documentation about this missing in tm, I will just add this.
>
>This routes allows you to process failures (including local ones) and also 
>local generated responses.
>
>Best regards,
>
>Henning
>
>-- 
>Henning Westerholt
>https://skalatan.de/blog/


С уважением,
Константин Поляков.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Missing ACC record in case of canceled call forking

[Daniel-Constantin Mierla]

Hello,

can you try with:

https://github.com/kamailio/kamailio/commit/5b223a2e8a92f351b8eab756f5256fda7645ff21

If still a problem, send again all the logs with debug=3.

Cheers,
Daniel


On 10.09.18 13:55, Marco Capetta wrote:
> Hi Daniel,
>
> sorry for the misunderstanding.
> Attached to the mail you can find the full log of the affected call
> with debug level 3 as requested.
>
> Thank you again
>
> Cheers,
> Marco
>
>
> On 09/10/2018 12:29 PM, Daniel-Constantin Mierla wrote:
>>
>> Hello,
>>
>> I need **all the logs**, not only those from acc module and script,
>> but all the modules and core.
>>
>> Add also:
>>
>> log_prefix="{$mt $hdr(CSeq) $ci} "
>>
>> to be able to match log message with the request time.
>>
>> And again, send the logs only for the case that fails.
>>
>> Cheers,
>> Daniel
>>
>> On 10.09.18 10:57, Marco Capetta wrote:
>>> Hi Daniel,
>>>
>>> I applied your patch to our kamailio v5.1.4 because this is the
>>> current version we are using.
>>>
>>>
>>> This is the log + debug of the call when the two INVITEs are leaving
>>> kamailio.
>>> This part is common for both the call cases:
>>>
>>> Sep 10 10:33:21 sp1 proxy[7627]: NOTICE: 

[SR-Users] kamailio + rtpengine + custom filename

[Жан Базаров]

Hello! Filenames have the format --.
 How i can change filename in start_recording() ???
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Missing ACC record in case of canceled call forking

[Daniel-Constantin Mierla]

Hello,

pushed another commit:

  -
https://github.com/kamailio/kamailio/commit/35dec4c20d78f49ba242229c877894d70c94705c

Give it a try and let's see the results.

Cheers,
Daniel


On 10.09.18 16:08, Marco Capetta wrote:
> Hello,
>
> the issue seems still there.
> Please find attached the new log with debug 3.
>
> Thanks
> Marco
>
>
> On 09/10/2018 03:14 PM, Daniel-Constantin Mierla wrote:
>>
>> Hello,
>>
>> can you try with:
>>
>> https://github.com/kamailio/kamailio/commit/5b223a2e8a92f351b8eab756f5256fda7645ff21
>>
>> If still a problem, send again all the logs with debug=3.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 10.09.18 13:55, Marco Capetta wrote:
>>> Hi Daniel,
>>>
>>> sorry for the misunderstanding.
>>> Attached to the mail you can find the full log of the affected call
>>> with debug level 3 as requested.
>>>
>>> Thank you again
>>>
>>> Cheers,
>>> Marco
>>>
>>>
>>> On 09/10/2018 12:29 PM, Daniel-Constantin Mierla wrote:

 Hello,

 I need **all the logs**, not only those from acc module and script,
 but all the modules and core.

 Add also:

 log_prefix="{$mt $hdr(CSeq) $ci} "

 to be able to match log message with the request time.

 And again, send the logs only for the case that fails.

 Cheers,
 Daniel

 On 10.09.18 10:57, Marco Capetta wrote:
> Hi Daniel,
>
> I applied your patch to our kamailio v5.1.4 because this is the
> current version we are using.
>
>
> This is the log + debug of the call when the two INVITEs are
> leaving kamailio.
> This part is common for both the call cases:
>
> Sep 10 10:33:21 sp1 proxy[7627]: NOTICE: 

Re: [SR-Users] Crashed drouting

[Евгений Голей]

I tried the same on versions 5.1.4 and 5.1.5. I just load the module, without 
using its functions in the configuration file.

kamailio[2725]: segfault at 0 ip 7f7a76cc4cfb sp 7fff4c640bb0 error 4 
in drouting.so[7f7a76cc1000+39000]

When a crased kamailio creates a core dump, I can forward it

What could be the reason ?



>Понедельник, 10 сентября 2018, 13:21 +03:00 от Daniel-Constantin Mierla 
>:
>
>Hello,
>
>if you are using v5.1.0, then you have upgrade to latest 5.1
>  branch and try again, there were some fixes to drouting module
>  that could cause the issue in your case as well.
>
>Cheers,
>Daniel
>
>On 10.09.18 09:22, Евгений Голей wrote:
>>Good evening.
>>
>>I have errors on the server (kamailio v
>>  5.1.0) "kamailio [30529]: segfault at 0 ip 7f9c00c29cfb sp
>>  7fffa9808310 error 4 in drouting.so [7f9c00c26000 +
>>  39000]" which cause the service to stop.  Although the drouting 
>> module has been
>>  used for a long time, this has never happened.  This was done after 
>> adding the functions of the
>>  dispatcher module.  What could be the reason ?
>>
>>Example error
>>in system
>>kamailio [20728]: segfault at
>>  0 ip 7f32c1c8fcfb sp 7fff78430d00 error 4 in
>>  drouting.so [7f32c1c8c000 + 39000]
>>
>>in the logs of kamailio
>>018-09-08T22: 30: 29.0448 "ALERT:
>>   [main.c: 746]: handle_sigs (): child process
>>  10556 exited by a signal 11"
>>2018-09-08T22: 30: 29.0452 "ALERT:
>>   [main.c: 749]: handle_sigs (): core was
>>  generated"
>>2018-09-08T22: 30: 29.0456 "INFO: 
>>  [main.c: 771]: handle_sigs (): terminating due to SIGCHLD"
>>
>>
>>-- 
>>B.R. Evgeniy
>>
>>
>>___
>>Kamailio (SER) - Users Mailing List
>>sr-users@lists.kamailio.org
>>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>-- 
>Daniel-Constantin Mierla -- www.asipto.com
>www.twitter.com/miconda -- www.linkedin.com/in/miconda
>Kamailio World Conference -- www.kamailioworld.com
>Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com


-- 
B.R. Evgeniy
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Crashed drouting

[Henning Westerholt]

Am Montag, 10. September 2018, 20:17:27 CEST schrieb Евгений Голей:
> I tried the same on versions 5.1.4 and 5.1.5. I just load the module,
> without using its functions in the configuration file.
> 
> kamailio[2725]: segfault at 0 ip 7f7a76cc4cfb sp 7fff4c640bb0 error
> 4 in drouting.so[7f7a76cc1000+39000]
> 
> When a crased kamailio creates a core dump, I can forward it
> 
> What could be the reason ?

Hello,

this is hard to guess. Could you please open the core dump with gdb and post 
the backtrace (gdb bt) here? 

Best regards,

Henning

-- 
Henning Westerholt
https://skalatan.de/blog/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] limit call per duration

[António Silva]

Hi,

I'm new to kamailio, i want to be able to limit call per duration, how 
can i do it?


i found module call_control, 
http://www.kamailio.org/docs/modules/5.1.x/modules/call_control.html, do 
you recommend it to use?


anyone using it that would like to share the experience, like the values 
for cpu usage, is it realtime, support for multiple calls per account, 
other...


Thanks!!


--
Saludos / Regards / Cumprimentos
António Silva


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Logging of messages generated by Kamailio itself

[Henning Westerholt]

Am Montag, 10. September 2018, 13:58:09 CEST schrieb Konstantin Polyakov:
> I used your advise and added into my configuration file two routes
> sl:local-response and tm:local-response. The log became more detailed.
> 
> But when 408 is sent by Kamailio on fr_inv_timer is expired,
> tm/sl:local-response is not called. This situation can be processed in
> failure_route using t_branch_timeout() function. However, I believe it is
> duty of local-response callback function as well.
> 
> Something wrong or it is expected behavior?

Hello Konstantin,

good that it logs now what you are expected. It seems that the tm module did 
not go into the event route for this certain internal generated response. But 
this should be available in the mentioned (branch-)failure routes. 

It could be extended, with a change in the code though.

Best regards,

Henning

-- 
Henning Westerholt
https://skalatan.de/blog/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Crashed drouting

[Евгений Голей]

Good evening, look, did I do the right thing ?


[user@sip]# gdb /usr/local/kamailio515/sbin/gwkamailio -c 
/usr/local/kamailio515/core.5138
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/kamailio515/sbin/gwkamailio...done.
[New LWP 5138]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/local/kamailio515/sbin/gwkamailio -DD -P 
/var/run/kamailio/gwkamailio515.p'.
Program terminated with signal 11, Segmentation fault.
#0  0x7f8b28c3ccfb in get_prefix (ptree=0x7f8b2ba08728, 
prefix=0x7fffcdf731d0, rgid=1) at prefix_tree.c:126
126 idx = get_node_index(*tmp);
Missing separate debuginfos, use: debuginfo-install 
glibc-2.17-157.el7_3.1.x86_64 hiredis-0.12.1-1.el7.x86_64 
keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-8.el7.x86_64 
libcom_err-1.42.9-9.el7.x86_64 libgcc-4.8.5-16.el7_4.2.x86_64 
libselinux-2.5-6.el7.x86_64 libstdc++-4.8.5-16.el7_4.2.x86_64 
openssl-libs-1.0.2k-8.el7.x86_64 pcre-8.32-17.el7.x86_64 
zlib-1.2.7-17.el7.x86_64
(gdb)


Where should I place this text? 
>Понедельник, 10 сентября 2018, 23:08 +03:00 от Henning Westerholt 
>:
>
>Am Montag, 10. September 2018, 20:17:27 CEST schrieb Евгений Голей:
>> I tried the same on versions 5.1.4 and 5.1.5. I just load the module,
>> without using its functions in the configuration file.
>> 
>> kamailio[2725]: segfault at 0 ip 7f7a76cc4cfb sp 7fff4c640bb0 error
>> 4 in drouting.so[7f7a76cc1000+39000]
>> 
>> When a crased kamailio creates a core dump, I can forward it
>> 
>> What could be the reason ?
>
>Hello,
>
>this is hard to guess. Could you please open the core dump with gdb and post 
>the backtrace (gdb bt) here? 
>
>Best regards,
>
>Henning
>
>-- 
>Henning Westerholt
>https://skalatan.de/blog/


-- 
С уважением,
Евгений Голей
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] tpops module

[volga629]

Hello Henning,
I can reproduce this issues on each BYE.
Not sure if this related.


Sep 10 17:51:40 canlvprx01 /usr/sbin/kamailio[20421]: CRITICAL:  
[core/route.c:1202]: comp_num(): Invalid right operand (1)



volga629

On Mon, Sep 10, 2018 at 3:56 AM, Henning Westerholt  
wrote:
Am Samstag, 8. September 2018, 17:28:33 CEST schrieb 
volga...@networklab.ca:
 I am using tcpops module  for keepalive and on BYE when tcp 
keeplaive

 close is called produce this error in log.

 Sep  8 11:21:26 canlvprx01 /usr/sbin/kamailio[18933]: ERROR: 
 [core/sr_module.c:1781]: get_int_fparam(): Could not convert PV to 
int

 Sep  8 11:21:26 canlvprx01 /usr/sbin/kamailio[18933]: ERROR: tcpops
 [tcpops_mod.c:293]: w_tcp_keepalive_disable1(): invalid parameter 
'con'

 (must be a number)

 kamailio-5.1.3-1.gitf0dce0c99.fc27.x86_64


 if (is_method("BYE|CANCEL")) {
 $avp(bye_conid) = $conid;
 rtpengine_delete();
 t_on_reply("4");
  }

 onreply_route[4] {
 if(is_method("BYE") && t_check_status("200")) {
 tcp_keepalive_disable("$avp(bye_conid)");
 }
 }


Hello,

this error is produced because the $conid PV could not converted to an
integer. Do you see some other error before this one? Is this error 
happens

all the time or just for rare or special cases?

Best regards,

Henning


--
Henning Westerholt
https://skalatan.de/blog/




___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] tpops module

[Mojtaba]

Hi,
In regard of w_tcp_keepalive_disable1() function in tcpops module,
this function called a macro to convert string to integer.
Let show the value of $avp(bye_conid) after set. Be sure the it's
value is string id.
Thanks with regards.
Mojtaba
On Tue, Sep 11, 2018 at 3:21 AM  wrote:
>
> Hello Henning,
> I can reproduce this issues on each BYE.
> Not sure if this related.
>
>
> Sep 10 17:51:40 canlvprx01 /usr/sbin/kamailio[20421]: CRITICAL: 
> [core/route.c:1202]: comp_num(): Invalid right operand (1)
>
>
> volga629
>
> On Mon, Sep 10, 2018 at 3:56 AM, Henning Westerholt 
> wrote:
> > Am Samstag, 8. September 2018, 17:28:33 CEST schrieb
> > volga...@networklab.ca:
> >>  I am using tcpops module  for keepalive and on BYE when tcp
> >> keeplaive
> >>  close is called produce this error in log.
> >>
> >>  Sep  8 11:21:26 canlvprx01 /usr/sbin/kamailio[18933]: ERROR: 
> >>  [core/sr_module.c:1781]: get_int_fparam(): Could not convert PV to
> >> int
> >>  Sep  8 11:21:26 canlvprx01 /usr/sbin/kamailio[18933]: ERROR: tcpops
> >>  [tcpops_mod.c:293]: w_tcp_keepalive_disable1(): invalid parameter
> >> 'con'
> >>  (must be a number)
> >>
> >>  kamailio-5.1.3-1.gitf0dce0c99.fc27.x86_64
> >>
> >>
> >>  if (is_method("BYE|CANCEL")) {
> >>  $avp(bye_conid) = $conid;
> >>  rtpengine_delete();
> >>  t_on_reply("4");
> >>   }
> >>
> >>  onreply_route[4] {
> >>  if(is_method("BYE") && t_check_status("200")) {
> >>  tcp_keepalive_disable("$avp(bye_conid)");
> >>  }
> >>  }
> >
> > Hello,
> >
> > this error is produced because the $conid PV could not converted to an
> > integer. Do you see some other error before this one? Is this error
> > happens
> > all the time or just for rare or special cases?
> >
> > Best regards,
> >
> > Henning
> >
> >
> > --
> > Henning Westerholt
> > https://skalatan.de/blog/
> >
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
--Mojtaba Esfandiari.S

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailio + rtpengine + custom filename

[Mojtaba]

Hello,
You could use metadata to save your favourite filename on it. After
recording is finished, replace it. The metadata file is created based
on  for each call.
With Regards.
Mojtaba
On Mon, Sep 10, 2018 at 8:53 PM Жан Базаров  wrote:
>
> Hello! Filenames have the format --.
>  How i can change filename in start_recording() ???
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
--Mojtaba Esfandiari.S

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users