Message-ID:
<CABVi_EzZRF8nUqoBGcUtUeAV2pknn5S0urcmJFgHSSz6N1kJ5g(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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 <CALL_ID> for each call.
With Regards.
Mojtaba
On Mon, Sep 10, 2018 at 8:53 PM Жан Базаров <chiefkeeft(a)gmail.com> wrote:
>
> Hello! Filenames have the format <call_ID>-<random>-<SSRC>.<extension>
> How i can change filename in start_recording() ???
Thx you. Can you help me with it task? Show me, please, an example. I want
filename of the following format, for example:
'output-dir/yyyy/mm/dd/fromnumber/callid-tonumber-uniqueid.wav'.
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
Hi I'm trying to manipulate with branches at the $branch variable. 8
actually need to remove unneeded branch if not passed some checks.
For now I Just rewriting uri and dst_uri with some face address but it
looks little bit dirty way.
Is here any an other more clear way to do this?
Hello,
Could somebody help with one issue?
In some cases Kamailio can send messages itself.
For example, when fr_inv_timer is expired Kamailio sends 408 to the INVITE sender and CANCEL to the INVITE receiver.
These two messages (408 and CANCEL) are not printed into the log and I cannot find a way to do that.
There are also other scenarios when some Kamailio modules send SIP messages by its own.
So is there way to print out into log all such messages?
My goal is to get full message flow in the log per certain call-id.
Thank you in advance.
Best regards.
Konstantin
Hello Everyone,
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>
[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)");
}
}
volga629
Hello everyone,
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.
Thanks a lot!
Good evening.
I have errors on the server (kamailio v 5.1.0) "kamailio [30529]: segfault at 0 ip 00007f9c00c29cfb sp 00007fffa9808310 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 00007f32c1c8fcfb sp 00007fff78430d00 error 4 in drouting.so [7f32c1c8c000 + 39000]
in the logs of kamailio
018-09-08T22: 30: 29.0448 "ALERT: <core> [main.c: 746]: handle_sigs (): child process 10556 exited by a signal 11"
2018-09-08T22: 30: 29.0452 "ALERT: <core> [main.c: 749]: handle_sigs (): core was generated"
2018-09-08T22: 30: 29.0456 "INFO: <core> [main.c: 771]: handle_sigs (): terminating due to SIGCHLD"
--
BR Evgeniy
