ailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamaili
tructure.
Cheers,
Daniel
On 26.02.20 10:12, Marco Capetta wrote:
Hi Yuriy,
thanks for the suggestion.
I tried both "event_route[tm:local-request]" and
"event_route[tm:local-response]" but internally generated CANCEL
messages are not captured by those event routes.
are there.
Do you have any other suggestion?
Thanks
Regards
Marco
On 2/25/20 5:50 PM, Yuriy Gorlichenko wrote:
You can try event_route[tm:local-request] for this.
On Tue, 25 Feb 2020, 15:36 Marco Capetta, <mailto:mcape...@sipwise.com>> wrote:
Hi All,
I have a question rega
Hi All,
I have a question regarding call forking and how to access failed
branches: the ones for which kamailio sends out the CANCEL because on
another one a 200OK was received.
This is the scenario:
- A calls B
- 3 devices are registered on B, so a parallel forking is done to B1,
B2 and B3
d.
The idea behind kxlibssl prng is to reuse the function of the default
libssl v1.1.x prng, but guarded by a kamailio specific mutex.
Cheers,
Daniel
--
*Marco Capetta *
VoIP Developer
Sipwise GmbH <http://www.sipwise.com> , Campus 21/Europaring F15
AT-2345 Brunn am Gebirge
P
On 11 Sep 2018 1:39 pm, "Marco Capetta" <mailto:mcape...@sipwise.com>> wrote:
Hi Daniel,
with the latest patch it works fine. The ACC record has code 486
and status Busy.
I'm not sure if in this case it would be better to report
487/Cancel or 486/Bu
09/10/2018 07:48 PM, Daniel-Constantin Mierla wrote:
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 i
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:
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
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 i
Hi Daniel,
did you have some time to have a look at the issue?
Thank you very much
Regards
Marco
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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 befor
Hello,
we have a problem of final reply code in case of 302 and then 486 busy.
This is our scenario:
A, B and C are subscribers.
A --> Kamailio --> B
Kamailio <---302 B
Kamailio ---> C
Kamailio <---486--
ssonrpcc".
Thanks
Marco
On 03/05/2018 11:20 AM, Marco Capetta wrote:
Hi All,
I'm currently in the process of upgrading a kamailio instance from
4.4.6 to 5.1.2.
Since"janssonrpc-c" has been renamed in "jsonrpcc" I have to adapt my
configuration.
In version 4.4.6, t
Hi All,
I'm currently in the process of upgrading a kamailio instance from 4.4.6
to 5.1.2.
Since"janssonrpc-c" has been renamed in "jsonrpcc" I have to adapt my
configuration.
In version 4.4.6, the function "janssonrpc_request" allowed me to setup
a specific timeout for the request.
Is it po
dule parameters "binrpc_max_body_size" and
"binrpc_struct_max_body_size" without success.
Do you have any other suggestion?
Thank you
Regards
Marco
--
*Marco Capetta *
Operations Engineer
Sipwise GmbH <http://www.sipwise.com> , Campus 21/Europaring F15
AT-2345 Brunn a
better fix for the case.
Cheers,
Daniel
On 13.11.17 09:46, Marco Capetta wrote:
Hi Daniel,
we left the test system running the whole weekend and so far we haven't see any
new ACC record for provisional response messages.
I think that the latest patch solved the issue.
Thank you
Cheers
"Kamailio (SER) - Users Mailing List" ,
"Andrew Pogrebennyk"
Sent: Friday, November 10, 2017 9:48:29 AM
Subject: Re: [SR-Users] 183 acc records even if early_media equals to 0
On 10.11.17 09:42, Andrew Pogrebennyk wrote:
> On 11
n your version with the patch.
Cheers,
Daniel
On 09.11.17 18:10, Marco Capetta wrote:
I applied the patch but kamailio crashes with the following error:
(gdb) bt full
#0 0x7f8af1e9b9ae in relay_reply (t=t@entry=0x7f8a29c05868,
p_msg=p_msg@entry=0x, branch=bran
ilio/kamailio/commit/785a3ccc743f429107c3dfae78d43705918aa4e6.diff
It will help to see if what I found was the source for the issue. If
yes, there might be another patch to have a proper handling of the
situation. If not, then I know I have to look somewhere else.
Cheers,
Daniel
On 09.11.17 15:53,
09.11.17 14:32, Marco Capetta wrote:
I have the same issue on 4.4.5 and 4.4.6
Thanks
Marco
On 11/09/2017 02:22 PM, Daniel-Constantin Mierla wrote:
One more thing, have you seen it in latest versions from branch
4.4.x? Or was it on 4.4.1 only? Or from other perspective, on which
versions you
?
Cheers,
Daniel
On 09.11.17 14:02, Marco Capetta wrote:
Thank Daniel.
Cheers
Marco
On 11/09/2017 12:38 PM, Daniel-Constantin Mierla wrote:
Hello,
I expect that the code value is taken from status of the
transaction, which at that time has 200ok ranked with more priority.
I will check the code
with a fix.
Cheers,
Daniel
On 09.11.17 10:42, Marco Capetta wrote:
Hello,
no we didn't try 5.0.X versions yet.
To investigate deeper the issue, I added some additional log lines in
the acc module. In particular, I did the following:
/* is this reply of interest for accounting ? */
s
Hello,
no we didn't try 5.0.X versions yet.
To investigate deeper the issue, I added some additional log lines in
the acc module. In particular, I did the following:
/* is this reply of interest for accounting ? */
static inline int should_acc_reply(struct sip_msg *req, struct sip_msg
*rpl,i
Dear All,
I'm facing a strange problem with the call accounting module: even if in
my configuration I have the parameter:
modparam("acc", "early_media", 0)
I can find some ACC records with sip_code 180 or 183.
I investigated those cases and this issue seems to happen when an
endpoint se
defining other stats via config? Or just use the one defined
internally?
I will dig in more to see if I can spot what can be the reason.
Cheers,
Daniel
On 27.09.17 10:56, Marco Capetta wrote:
Hi Daniel,
I'm Marco a colleague of Andrew.
When we restart kamailio all the counters are correctly s
nt of calls on that system.
Andrew
--
*Marco Capetta *
Operations Engineer
Sipwise GmbH <http://www.sipwise.com> , Campus 21/Europaring F15
AT-2345 Brunn am Gebirge
Phone: +43(0)1 301 2044
Email: mcape...@sipwise.com <mailto:mcape...@sipwise.com>
Website: www.sipwise.com <ht
27 matches
Mail list logo
