Hello,
ok, thanks for testing, I will backport to 5.1 ...
Cheers,
Daniel
On 12.09.18 09:50, Marco Capetta wrote:
> Hello,
>
> yes, a "486 Busy Here" message is sent back to the caller as final reply.
>
>
> Thanks
>
> Cheers
> Marco
>
>
> On 09/11/2018 05:20 PM, Daniel-Constantin Mierla wrote:
>
Hello,
yes, a "486 Busy Here" message is sent back to the caller as final reply.
Thanks
Cheers
Marco
On 09/11/2018 05:20 PM, Daniel-Constantin Mierla wrote:
Hello,
Can you look on the wire and see what reply code is sent to caller?
That should be accounted.
Cheers,
Daniel
On 11 Sep 201
Hello,
Can you look on the wire and see what reply code is sent to caller? That
should be accounted.
Cheers,
Daniel
On 11 Sep 2018 1:39 pm, "Marco Capetta" 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
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/Busy in the ACC, but in any case the record has been created.
Thank you very much for your help
Regards
Marco
On 09/10/2
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 w
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 mai
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
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:
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 does
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:
ca
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.
>
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 foll
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
13 matches
Mail list logo
